4 Replies Latest reply: May 28, 2011 4:12 AM by Tangle RSS

    ADuC7020: Can't write to 0x00080000 Flash/EE




      Another problem with serial downloading.


      I've written a serial downloader, using this software I can connect to an ADuC7020 and erase it's memory space.  However when I send 'write' packets in the format outlined by AN-724, I get a negative acknowledge (BEL) returned.  The AN says this is due to an incorrect checksum or an invalid address.  I've checked, checked and checked again the checksums and they seem to be fine, suggesting that the address is invalid.


      Using the GNUARM compiler the first line in the ihex file is an 02 record, which sets an address offset of 0x00080000, effectively loading the program into the Flash/EE space.  This all makes sense because the ADuC702x data sheet says this is where the program should go, and that it then gets mirrored to 0x00000000 on a device reset.


      If I delete the 02 record on the first line of the hex file (i.e. program into 0x00000000) the program loads and then runs.  However, I do not think that I should be loading the program at 0x00000000.


      The hex file load and runs using other serial download software tools regardless of whether the initial line directs it to program at 0x00080000 or 0x00000000.


      Has anyone had a similar experience?  Is there something I am missing about the address space?  Does the ADuC automatically offset the memory space during serial download?


      Thanks for you help


        • 1. Re: ADuC7020: Can't write to 0x00080000 Flash/EE

          Hi Tangle


          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.




          • 2. Re: ADuC7020: Can't write to 0x00080000 Flash/EE



            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.


            • 3. Re: ADuC7020: Can't write to 0x00080000 Flash/EE

              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.

              • 4. Re: ADuC7020: Can't write to 0x00080000 Flash/EE

                Thanks for you help guys.