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.
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
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?
You don't have to be rude. Thanks for your help.
I think I need to elaborate why I have gotten rude:
Besides: the uVision F1 help is a CHM (uv4.chm) file that is called from the help menu.
Since it is quite big, it's not to easy to find the right page.
I think it is not difficult to find the right page. Because I read
the entire thing before I ever got the idea to waste other people's
time on my problems. I haven't read everything in detail (i.e. I
skimmed a lot of parts), but still I looked over everything and have
a firm idea of what I can find in there.
This is the standard I ask anyone else to meet. Otherwise you are
just a parasite. People invested a lot of time into creating that
documentation and you're spitting into their faces.
When someone posts something that can be found in the manual in
reply to a question I asked, I'm deeply insulted. Because it means
people think I am that kind of person.
Now would be a good idea to calm down a bit.
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!
Well, the solution was here, on Keil's website, not in the
documents that come with UV.
The BL51 solution still does not work, but is given by Keil for UV4
and BL51. So I'm in doubt whether I was wrong or them.
See, Dominic, as I said above: you can read as much as you want
and they could have spent a lot of time writing such documents - all
doesn't matter if the information is wrong.
My job is to write technical documentation for the power supplies
we produce. People often phone us about things that is all written in
the documents, but they don't read. Sometimes I want to shout Please read the manual!
But we don't do, of course. Being lazy is in the nature of man.
Asking people who know is easier than learning all yourself. Else we
all would be highly trained specialists and that wouldn't work
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
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
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