Loading ...
Sorry, an error occurred while loading the content.

Re: ADuC7020 program space 0x00080000 is invalid?!?

Expand Messages
  • certaintangle@rocketmail.com
    Harry, An intel hex does not need to start with an 04 record, it depends entirely upon what address you complie the code to start from. The Wikipedia page is
    Message 1 of 5 , May 28, 2011
    • 0 Attachment
      Harry,

      An intel hex does not need to start with an 04 record, it depends entirely upon what address you complie the code to start from. The Wikipedia page is not complete, the standard is a much better source.

      My hex files are fine, as I said I can load them with other serial downloaders, but not ARMWSD because it is windows only, so it's not good to me.

      My problem has been that despite the ADuC7020 data sheet saying that Flash starts at 0x00080000, I cant load data there. I can load data to other places, and I can load data to 0x00080000 with other serial downloaders. Like you I also found that ignoring extending address records meant I could load file that were compiled to start from 0x00080000 it would load.

      It is starting to look like that despite the ADuC70xx devices requiring you to provide a 32-bit address in the data packet that in fact they only use the least significant 16-bits and therefore 02 and 04 intel hex records should be ignored. I'm still confirming this.

      Thanks
      Lee.



      --- In ADuC_ARM@yahoogroups.com, harry olar <harry_olar@...> wrote:
      >
      > According to this http://en.wikipedia.org/wiki/Intel_HEX the first line
      > in the hex file
      > looks something like this
      >
      > :020000040008F2
      >
      > : -Start code
      > 02 -Byte count
      > 0000 -Address
      > 04 -Record type -Extended Linear Address Record
      > 0008 -Data
      > F2 -Checksum
      >
      > This line is taken from a workable hex file
      >
      >
      > Use this http://www.analog.com/static/imported-files/eval_boards/ARMWSD.zip
      > to make sure that the file is valid first or use a file that comes from some
      > example that is provided by Analog.
      >
      > Make sure that the offset of the code is correct.(you could change it from 0x0
      > to a higher value as I did ;i change it to 0x4000 so it will load after
      > bootloader)
      > I created a custom bootloader that loads the hex file line by line but I ignore
      > EXTENDED_LINEAR_ADDRESS_RECORD type lines.
      >
      > Make sure that the offset is 0x00080000 and not 0x0008000;
      >
      > What is your first line from hex file?
      >
      >
      > Hope I helped you .
      > Harry
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > ________________________________
      > From: "certaintangle@..." <developer@...>
      > To: ADuC_ARM@yahoogroups.com
      > Sent: Wed, May 25, 2011 8:04:01 PM
      > Subject: [ADuC_ARM] ADuC7020 program space 0x00080000 is invalid?!?
      >
      >
      > Hello,
      >
      > I'm writing a serial downloader for the ADuC702x series. I can send send a mass
      > erase packet and have it acknowledged (and perform the erase). However, if I
      > try to write into the Flash/EE space beginning at 0x00080000 I get a negative
      > acknowledge.
      >
      > I've checked, checked and checked again the checksums and that does not appear
      > to be the problem, suggesting that the negative ACK is due to an invalid
      > address.
      >
      > The ihex file generated by the GNUARM tool chain starts with an 02 record, that
      > is an address offset of 0x0008000, which essentially puts the program into
      > Flash/EE, which all makes sense because the data sheets say this is where it
      > should go. Flash/EE then gets mirrored to 0x00000000 on reset.
      >
      > I cannot write to 0x00080000! Strangely if I delete the opening 02 record from
      > the ihex file (i.e. write the program at 0x00000000) then my serial downloader
      > loads the program and it runs fine. However I do not think that I should be
      > programming into the 0x00000000 memory space.
      >
      > Note that the original unaltered hex file loads correctly with another serial
      > downloader.
      >
      > Does anyone have experience with something similar? Have I missed something
      > important about writing to the Flash/EE space in serial download mode?
      >
      > Thanks for any help
      > Lee.
      >
    • certaintangle@rocketmail.com
      Hi all, See this discussion over at ADI s Engineer Zone: http://ez.analog.com/message/25925. In general it s fine to load at 0x00000000 because in serial
      Message 2 of 5 , May 28, 2011
      • 0 Attachment
        Hi all,

        See this discussion over at ADI's Engineer Zone: http://ez.analog.com/message/25925.

        In general it's fine to load at 0x00000000 because in serial download mode that address refers to the start of the flash. Thus you should ignore any opening 02 or 04 hex record that offsets the address of the first line of the code, or make sure that you compile your code to start at 0x00000000 rather than 0x00080000. The latter is the best solution because any subsequent offset records will be needed if the flash in your device exceeds 64k.

        Lee.




        --- In ADuC_ARM@yahoogroups.com, "certaintangle@..." <developer@...> wrote:
        >
        > Harry,
        >
        > An intel hex does not need to start with an 04 record, it depends entirely upon what address you complie the code to start from. The Wikipedia page is not complete, the standard is a much better source.
        >
        > My hex files are fine, as I said I can load them with other serial downloaders, but not ARMWSD because it is windows only, so it's not good to me.
        >
        > My problem has been that despite the ADuC7020 data sheet saying that Flash starts at 0x00080000, I cant load data there. I can load data to other places, and I can load data to 0x00080000 with other serial downloaders. Like you I also found that ignoring extending address records meant I could load file that were compiled to start from 0x00080000 it would load.
        >
        > It is starting to look like that despite the ADuC70xx devices requiring you to provide a 32-bit address in the data packet that in fact they only use the least significant 16-bits and therefore 02 and 04 intel hex records should be ignored. I'm still confirming this.
        >
        > Thanks
        > Lee.
        >
        >
        >
        > --- In ADuC_ARM@yahoogroups.com, harry olar <harry_olar@> wrote:
        > >
        > > According to this http://en.wikipedia.org/wiki/Intel_HEX the first line
        > > in the hex file
        > > looks something like this
        > >
        > > :020000040008F2
        > >
        > > : -Start code
        > > 02 -Byte count
        > > 0000 -Address
        > > 04 -Record type -Extended Linear Address Record
        > > 0008 -Data
        > > F2 -Checksum
        > >
        > > This line is taken from a workable hex file
        > >
        > >
        > > Use this http://www.analog.com/static/imported-files/eval_boards/ARMWSD.zip
        > > to make sure that the file is valid first or use a file that comes from some
        > > example that is provided by Analog.
        > >
        > > Make sure that the offset of the code is correct.(you could change it from 0x0
        > > to a higher value as I did ;i change it to 0x4000 so it will load after
        > > bootloader)
        > > I created a custom bootloader that loads the hex file line by line but I ignore
        > > EXTENDED_LINEAR_ADDRESS_RECORD type lines.
        > >
        > > Make sure that the offset is 0x00080000 and not 0x0008000;
        > >
        > > What is your first line from hex file?
        > >
        > >
        > > Hope I helped you .
        > > Harry
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        > > ________________________________
        > > From: "certaintangle@" <developer@>
        > > To: ADuC_ARM@yahoogroups.com
        > > Sent: Wed, May 25, 2011 8:04:01 PM
        > > Subject: [ADuC_ARM] ADuC7020 program space 0x00080000 is invalid?!?
        > >
        > >
        > > Hello,
        > >
        > > I'm writing a serial downloader for the ADuC702x series. I can send send a mass
        > > erase packet and have it acknowledged (and perform the erase). However, if I
        > > try to write into the Flash/EE space beginning at 0x00080000 I get a negative
        > > acknowledge.
        > >
        > > I've checked, checked and checked again the checksums and that does not appear
        > > to be the problem, suggesting that the negative ACK is due to an invalid
        > > address.
        > >
        > > The ihex file generated by the GNUARM tool chain starts with an 02 record, that
        > > is an address offset of 0x0008000, which essentially puts the program into
        > > Flash/EE, which all makes sense because the data sheets say this is where it
        > > should go. Flash/EE then gets mirrored to 0x00000000 on reset.
        > >
        > > I cannot write to 0x00080000! Strangely if I delete the opening 02 record from
        > > the ihex file (i.e. write the program at 0x00000000) then my serial downloader
        > > loads the program and it runs fine. However I do not think that I should be
        > > programming into the 0x00000000 memory space.
        > >
        > > Note that the original unaltered hex file loads correctly with another serial
        > > downloader.
        > >
        > > Does anyone have experience with something similar? Have I missed something
        > > important about writing to the Flash/EE space in serial download mode?
        > >
        > > Thanks for any help
        > > Lee.
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.