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
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.
Sorry for the missing words. I posted it fastly, not checking the
spelling so thoroughly.
The bootloader is mapped into the addressable memory at
I know of no use for a non-addressable memory, do you mean flash?
Did we cross a magic border? A border which is at
easy to see in the .map file
OK, in other words: this is about the 64k flash memory, also
called CODE range. I know that the bootloader is only mapped at
0xF800, not programmed there in the same memory space.
But, it is pretty obvious that when compiling code which size is
>0xF7FF, the code still starts the bootloader (LCD display goes
- it does not set the BLJB anymore (which we use for a certain
- it does not initialise the UART for immediate communication and
so the possibility to reprogram the chip in ISP is lost atm.
The code to set BLJB and start the bootloader is still the same in
all the versions.
The start code is quite cryptic for me:
*((const void(code*)(void)) 0xF800 )
A very good thought! Looking at the memory model, it says that the
CODE space from 0xF800 is not accessible anymore once the ENBOOT bit
in AUXR is set. This bit is set by our code directly before starting
the bootloader. So it may be fixed by putting the jump code
definitely somewhere below 0xF800, I guess.