Programming nRF9E5 through AT25320B

[Cy]

Hello,

I understand the nRF9E5 is programmed through the externally attached AT25320B, ok. I understand three bytes are appended to the .hex file for the 8051. Since I am programming the AT25320B from the hex file do I need to decipher the .hex file and send only the pertinent bits? Example, :060000000B0309020928B0, therefore the B, 3, and 9 are the actual first three bytes into the EEprom? And that B means that the ee prom communicates at greater than 1MHz, and the clock speed of the system is 16MHz?

Thank you for considering my problem.

[ovrebekk]

Hi

Have you read chapter 21.2 in the nRF9E5 Product Specification?

Table 60 shows how the first three bytes should be coded. The first byte is used for the Version, Speed and XO_FREQ fields. The second byte is the code start offset, and the third byte is the number of 256 byte blocks used by the program.

In other words you shouldn't split up the fields like you did in your example.

Best regards
Torbjørn

[Cy]

Thank you for your response, much appreciated! I have looked at table 60, but I am not able to see another way to interpret it. The starting line of the hex file, an example range demo :060000000B0309020928B0 The hex interpretation is 6 bytes on the line, start programming at address 0x0000, with the (0x00) data: 0x0B,0x03,0x09,0x02,0x09,0x28. The first three bytes into the AT25320B are 0x0B, 0x03, and 0x09 0x0B: Speed = 1MHz (eeprom) XO_FREQ = 16MHz 0x03: Offset to start User program - byte 3. 0x09: number of 256 byte blocks in the user program.

In this interprectation I am interpreting the hex file and only programming the pertinent bits into the EEprom.

If I am wrong in my interpretation of Table 60, please help me understand, thank you!

[ovrebekk]

Hi

You are correct of course. I misunderstood your question.

0x0B means the version and reserved fields are 0, while the SPEED field is 1 and the XO_FREQ field is 3, which you have correctly decoded to mean an SPI speed of 1MHz max and a crystal frequency of 16MHz.

The final 3 bytes before the checksum are the first 3 bytes of the program, executing a jump to address 0x0928 (if my rusty 8051 assembler knowledge serves me right...)

Sorry for the confusion, and best regards ;)

[ovrebekk]

By the way, I assume you are aware there is a utility called EEPREP, which adds the header bytes for you?