nrfjprog.exe with bin files

[BMW]

Hi, I'm trying to program my nrf52811 by using nrfjprog.exe with a bin file. It seems to work with a .hex but when I run the .hex through srecord to create a .bin and using nrfjprog.exe with .bin file, the device gets flashed but doesn't actually function as it does with .hex. What could be the issue?

NRF5 SDK

[Amanda Hsieh]

Hi, 

nrfjprog.exe only support hex file. See nrfjprog commands. 

Regards,
Amanda H.

[BMW]

That may be true for an older version but my version is showing that it accepts multiple filetypes including bin files.

[Daniel Veilleux]

If you forgot to recover between steps then that could potentially make the two dumps look equal when they really aren't. Now that you know what you're looking for though I'd just recover the chip, flash the bin, and then read that UICR setting with "nrfjprog --memrd 0x10001200" (the result shouldn't be 0xffffffff). If you think it's an nrfjprog issue then you can recover and then use JLink.exe to program the bin and see if that makes a difference.

[BMW]

Both methods of flashing seem to still give 0xFFFFFFFF on memrd. 

I am using Srecord to convert the .hex to a .bin in case that info helps. The command I use is:

srec_cat.exe ble-v2-5.hex -Intel -o ble-v2-5.bin -binary

[Daniel Veilleux]

Did you do a sanity check by programming the original hex and then reading the mem? I'm not familiar with Srecord but I could probably show you how to do it with python. We usually work with hex files with the nRF52 series due to the offset of the UICR.

[BMW]

Yes just did it again and line 34 definitely has the 0x1500000015000000. Using srecord to convert my hex to bin then back and using the new hex seems to fail. Readuicr returns ffff even though compare the 2 hexfiles the new one is just adding lines with 0 for data to fill in the addresses with no data. If you already have a script I could run it on my hex and compare the bins, or maybe I need an extra parameter when running srecord to have it create to correct bin file? What do you mean by the offset of the UICR? My hexfile has both the softdevice and our application so it should be writing from 0.

[Daniel Veilleux]

Bin files don't contain any addresses like hex files do. So your SoftDevice and application start from 0x00 and contain data up to somewhere like 0x2d000. But the UICR starts at 0x10001000. So if you have UICR settings then now you get a bunch of padding between the end of your real data and the UICR. A quick test here spits out a 256MB bin file when I take one of your UICR dumps and add data at address 0x00. If you want to use bins though you could have two files: one for the SD + app and another for the UICR.

[BMW]

I'm a bit confused now. My hexfile that works only has data that writes up to what you were saying 0002d740, so how is it that it has data that is writing to 10001000? Also I don't think we have data writing to UICR for this.

[Daniel Veilleux]

That setting that enables the reset pin lives in the UICR, starting at 0x10001200.

[BMW]

But looking through my hexfile I don't have anything being written to that address. The second to last line of my file has address value d640, and the extended address is 0002, so my confusion is about how it could be writing to UICR when the file ends within flash