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.

[BMW]

ble_bin.hexble_hex.hexI believe I've done the UICR correctly I got these files. It seems that line 34 is not matching when diffed.

[Daniel Veilleux]

Yes, that bin file is missing the UICR values that enable the GPIO pin reset.

[BMW]

Ah ok. Do you know how I would fix this? Was it a problem with the creation of the bin file or flashing maybe? 

[BMW]

I just did this again and the files look the same. I must've forgotten to run the recover when I flashed the other file

[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.