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.
OK, sorry. It's the Device tab.
And no, I DIDN'T DO IT BEFORE you claimed it wasn't possible.
"Finding out myself can take a lot of time and we don't want to invent the wheel again. Programming is only a side job for me, I simply don't get the time from my boss to learn all the stuff about Keil's tools"
Note that lots of people on this forum "simply don't get the time from their boss to help others avoid inventing the wheel".
Getting help may be very important to the one who wants/needs help. But what incentive is there to give that help? Using what resources? What boss wants people to spend time helping? Especially if there is a commercial advantage of being alone having the knowledge about the wheel?
@Dominic: Doh, I could have found out myself this time. You're right. Problem now is, I can only select the LX51 linker if I have selected a device and in UV4, the Atmel AT89C51CC03 is not listed anymore. None of 89ers is listed. I can also not select a different CPU database. But in File->Database it lists a much bigger database with that Atmel MCU included. Even I go to Project->New project, it only shows me the short list with only Atmel SAM devices. In UV4 I can right-click the target and select target options, where I can not switch the target device. So I exported the UV4 project to a UV3 project and opened it in UV3. There I can select the AT98C51CC03 from the generic CPU database AND activate the LX51.
OK, next step: compiling. Using the BL51, all works fine (without the new linker command). Using LX51 with the linker command, I get warnings (L48), but these can be ignored. The post-processor from Hitex obviously denies the output from the LX51, so we could not debug the code. But at least I got a hex file and, looking at the map file, see the bootloader jump code at 0x2000.
I tested the code - works. It now sets BLJB and jumps to bootloader (instantly accessible with FLIP).
Many thanks for all your help!
I have selected a device and in UV4, the Atmel AT89C51CC03 is not listed anymore. None of 89ers is listed. I can also not select a different CPU database.
That's actually incorrect. uVision 4 in general supports that CPU just fine. Your particular installation doesn't. Well, that's what you get for trying to re-purpose a special edition of the Keil toolchain beyond its stated limitations.
It's crucial details that fail to be mentioned, like this, that very often make it impossible to help meaningfully.
Saw who posted that and just ended up rolling about the floor laughing.