1

I am working on a secondary bootloader for a Renesas microcontroller.
Following are two consecutive records of the 11000+ records in the HEX file.

:04D1D000000000005B
:10D1DC0001030600001000000080000000000100A8

Decoding this the simpler :LLAAAATT way:

:04D1D000000000005B means:

  • Length of data: 0x04 bytes
  • Address to put data at: 0xD1D0 + Base address set previously, in this case it was 0xA0000
  • Record type: 00 Meaning, its a Data record.
  • Data: 00000000 which is 0x00, 0x00, 0x00 and 0x00 when represented as bytes.
  • Checksum of the record: 0x5B

:10D1DC0001030600001000000080000000000100A8 means:

  • Length of data: 0x10 bytes
  • Address to put data at: 0xD1DC + Base address set previously, in this case it was 0xA0000
  • Record type: 00 Meaning, its a Data record.
  • Data: 01030600001000000080000000000100 which is data that should be programmed from location 0xAD1DC
  • Checksum of the record: 0xA8

If we look at the addresses, we know what data is to be programmed from 0xAD1D0 to 0xAD1D3 which is 4 bytes. And we know, what data is to be programmed from 0xAD1DC to 0xAD1EC which is 16 bytes.

What should the memory between 0xAD1D4 to 0xAD1DB (both inclusive) which is 8 bytes be filled with? Is it 0xFF or 0x00?

I checked that these locations have no special significance and are not reserved locations as such.

WedaPashi
  • 1,670
  • 17
  • 29
  • 3
    I've typically seen unprogrammed bytes as 0xff, though this depends on how much of the chip is erased when doing programming. – uglyoldbob Jun 23 '20 at 14:12
  • @uglyoldbob, hex file is different. It's a string collection. Binary data is represented by ASCII text. – Sadat Rafi Jun 23 '20 at 14:21
  • To build a tool of general utility you should not touch the existing contents of the gaps unless separately instructed to do a bulk erase. Part of the advantage of an addressable format over a flat one is that (to the degree the recipient device supports it) you can "come back later" with another set of records from another source and fill in information originally excluded, for example device serialization records and instance unique keys. – Chris Stratton Jun 23 '20 at 14:27
  • 2
    THat data is left blank. If it was FF before, it will still be FF. If it was 00 before, it will still be 00. If it was C3 before ... you get the picture. Traditional EPROMs and many newer parts are FF. –  Jun 23 '20 at 14:30

2 Answers2

3

Intel Hex specifies the bytes to be programmed and their new values. All other bytes are keep their previous state. If you are programming a blank part, that previous state is its unprogrammed value.

Intel Hex is targeted at programmable (non-volatile) memories. Nearly all programmable memories used over the last decades are EPROM variants, such as Flash. Their unprogrammed value is almost always 0xFF. Note that the datasheet must always be used to obtain the actual unprogrammed value for your part. As with any characteristic, it should not be assumed.

TonyM
  • 21,742
  • 4
  • 39
  • 62
  • 1
    +1, Thanks. Checked the flash contents when not programmed (factory default) and when erased. They were 0xFF. – WedaPashi Jun 24 '20 at 07:37
  • 1
    Looks for example at the STM32 family, the traditional parts erase to 0xFF but the L series to 0x00. Ex-Atmel ARM has many that go to zero as well. MCU's are among the most common current targets of hex files. – Chris Stratton Jun 24 '20 at 11:32
  • 2
    @ChrisStratton are you sure about that claim about STM32L? The L451 reference manual talks about 0xFF FFFF FFFF FFFF FFFF being "virgin data" and "If the user needs to program only one word, double word must be completed with the erase value 0xFFFF FFFF to launch automatically the programming." Which very much sounds like the value after an erase is 0xFF - which is my experience with that part. But there are other L series around, so not sure which one you had in mind. – Arsenal Jun 24 '20 at 22:15
  • 1
    @Arsenal see https://electronics.stackexchange.com/questions/80412/how-to-overwrite-flash-memory-on-stm32l-series and yes, I've personally confirmed this on the hardware, especially STM32L073 which is extremely popular processor for modern low power sensor designs. – Chris Stratton Jun 25 '20 at 00:29
  • 1
    @ChrisStratton interesting seems like they have a very different interface and implementation of the flash in the L0 compared to the L4. – Arsenal Jun 25 '20 at 07:54
3

The hole is a hole, do not make any assumption about the data which is there. Depending on the device it might be 0xFF or 0x00 after an erase cycle, but it could be anything if the device supports writing single bytes and doesn't need a page erase (or something similar).

If you have an algorithm which relies on a specific data being there (like a checksum algorithm) fill the holes with a known value which you define. There are tools around which support filling holes over a specified range with a specified value. Then the hex file will contain that data as well.

The benefit of having a format like this is that it is easy to have a single hex file for a device which doesn't have a continuous address space. Or intentionally leaving space for other information which is not the same for all programmed chips - like calibration data.

Arsenal
  • 17,464
  • 1
  • 32
  • 59
  • Or a device where you want to leave some bits unprogrammed. I've worked on a number of projects where we reserve one or more sectors in flash (or EEPROM) for data or for boot code. Hex files make that easy. – TimWescott Jun 23 '20 at 16:59
  • @TimWescott good point, I did too. – Arsenal Jun 23 '20 at 18:52