nrfjprog --program <> --verify fails at certain conditions. nrfjprog --recover only helps

[Valerii_Ie]

Hi sometimes it happen with my nrf52832 based device. 
The common way I am programming firmware during development is next: 

nrfjprog --program fw.hex --sectorerase --verify --reset --log

At some condition happen i no longer can program firmware this way untll i perform full chip erase by 

nrfjprog --recover

Log:

0486.log.log

Please support

[Jared]

Hi,

Have you tried something simple as changing the USB cable? We often see that this is a common culprit. Also, are you using a custom board or a development kit. If it's former, could you upload the schematics? I can make the case private first if you prefer it.

regards

Jared  

[Valerii_Ie]

Hi Jared,
It is custom board and unfortunately, I can't share the schematic. I don't have it.
I have tried many times with different j-link adapters, powercycled, restarted PC, changed cables, reconnected USB hub etc. I know usually it helps.  

But in this case it doesn't help. After unsuccessful verification i have dumped the flash and realized that only first about 20kB were programmed. That's why verification fails. I also checked BPROT to exclude some protection reason. 
What is actually helped: 

nrfjprog --readcode dump.hex
nrfjprog -e
nrfjprog --program dump.hex --verify --reset

after -eraseall now i can write the same firmwase 10+ times and all attempts are successful. 

My understanding is that --eraseall lead to clear of some peripheral in NRF52  that prevents chip from successful write. 

Any ideas?

[Jared]

Hi,

Most of the peripherals will be cleared i.e. set back to its reset state after you have executed a Power-On-Reset. A power cycle would thus set most peripherals back to their default state. An immediate reason I can think of is that an erase all will erase everything in addition to the UICR register. Are you using some of the registers in the UICR in your application? 

Valerii_Ie said:

It is custom board and unfortunately, I can't share the schematic. I don't have it.

 Ok. But are you able to reproduce the issue on a development kit? If you are, then we could at least exclude the HW of being source of the issue. 

Also, how many samples are you observing this issue on? 

best regards

Jared 

[Valerii_Ie]

Hi, I happens with different devices but not frequent. Sometimes I can reproduce it several times in sequence, sometimes it does not happen for months. I would suggest it somehow related to device power or jlink programmer state. Next time when it happen i will check UICR but we don't use it for storing any "user" information (only bootloader address, MBR data address and reset pin)

[Jared]

Hi,

Valerii_Ie said:

I happens with different devices but not frequent.

 Is Nordic development kits included in this?

Valerii_Ie said:

I would suggest it somehow related to device power or jlink programmer state.

What debugger are you using and how is the board supply? 

regards

Jared