Hello!
I seek to find help here, because we across a problem we don't seem to be able to solve. But perhaps has an idea...
Following: for a power supply we sell we use AT89C51CC03 as main controller. It has 64k flash. The bootloader is mapped into the addressable memory at 0xF800. In order to be able to update the microcontroller firmware (i.e. ISP), we used to send a command from outside, which let our code jump to the bootloader by API calls. With the time, the code grew. Some versions earlier, jumping into bootloader worked fine. It means, we just sent the command, the controller jumped into bootloader, initialised the UART (which is connect to USB, making a VCOM port on the PC side) and we could then instantly access the Atmel chip via FLIP. In some newer versions, the code grew bigger and now has 63.2k, making its end address being around 0xFD30. We didn't realize so far, because we usually only test the code itself, but not if the update still works. And now, neither jumping to bootloader nor setting the BLJB via API calls works anymore.
Did we cross a magic border? A border which is at 0xF7FF?
I read the UART bootloader documentation and the AT89C51CC03 manual, I found no hint about that using up all of the 64k flash memory could result in such a problem. But it seems, it's exactly caused by now having code with end address >0xF7FF.
Question now is: how to access the bootloader and how to update the firmware without forcing the chip to bootloader with PSEN?
Thanks for any advice.
So what I posted didn't work?
Because that's all from the documentation that came with µV and I tested it.
"parasite", "idiot", what's happening here recently...?
For the OP the problem is (one of) his biggets issue(s). For a responder it is taking time away from his day job.
An OP wants his problem solved NOW!! regardless of his description being incomplete e.g. 90% of the posters with code snippets do not follow instructions and do not consider it their fault. Also, quite a few posts are of the nature "it is faster to ask here than to read the documentation".
A responder may take time away from his paid job to reply and does thus have no desire to try to help OPs that e.g. are too lazy to read the documentation.
so the responder posts "Please read the manual" and the OP goes ballistic.
The responder does not appreciate being called whatever the OPs chosen expletive is and, Tamit, that is what is "happening here recently".
Erik