The following applies to ADuC7xxx ARM 7 based parts. After a reset the kernel firmware runs to configure and calibrate the part and the kernel exits by branching to 0x00000000. At 0x00000000 there is normaly a branch to an address just above 0x00080000. At reset the flash which is phisically at 0x00080000 is mirrored at 0x00000000 so the above scheme works and you can compile your code to start at either 0x00000000 or at 0x00080000.
Regarding flashing, this is done via a flash interface which is only 16 bit so the 8 in the physical address is not relevant. In the downloader firmware therefore the 8 was not taken into consideration and you need to also leave it out in the download commands. Unfortunately this is not specified clearly in the documentation. In some of the more recent parts it will work with or without the 8 present.
Thanks for you response. Just to clarify:
1. It is fine to load my code at 0x00000000. I assume that this means that mirroring does not involve any copying of potential overwriting of data.
2. Even though a as 32-bit address is required to be provided to load code during serial download mode, only the least significant 16 bits are used. This would mean that 02 and 04 records of an intel hex file can be ignored. Should I be writing my serial download tool to ignore these lines for ADuC7xxx devices?
This all seems to mean that even if you compile your code to start at 0x00080000 it would be loaded to 0x0000 in 16-bit space and I assume that 0x0000 refers to the beginning of the FLash/EE space.
Thanks for your help.
Your assumptions are correct BUT …
There are other devices with greater than 64K which implement the serial downloader also, and that document also applies to them.
Considering 16 bit addresses might be valid here, but incorrect in the more general sense.
Consider the “address” as “offset into flash space” and your implementation will be valid for all kernel revisions and for other parts with greater than 64K flash.