nRF52840dongle new strange probelm

[njeester]

Upto a week I had *no* problem in programming a nRF52840 dongle with an app I am porting from the nRF52840dk.

All of a sudden I can't get the app running, the dongle appears dead.

I've reisntalled all software and notice the following behaviour.

From scratch (after reinstall of software for example) I can program the dongle with an app I developed with the nRF5SDK using segger - no problem.

Then I can program the dongle with an example program, in this case the periperal lbs example with segger and nRF Connect SDK - no problem.

If I use VSCode and program the dongle with the periperal lbs example the dongle does not work. (Even though the dongle is reported as successfully programmed (and verified if I use that option).

To get the board working again I have to reprogramme with the app from the nRF5SDK! After programming with the VScode the dongle can't be repgrammed from segger and nRF Connect SDK.

Would appreciate any suggestions to fix the problem!

[Einar Thorsrud]

Hi,

I am struggling a bit to get a full understanding of this. Is it so that in all cases you are programming using a debugger (so not USB DFU via nRF Connect Programmer), and that programming etc. always works? The "only" issue is that your application from a point in time stopped working, and you only see example applications working? If so, what change did you do around the time when your application stopped working? What have you found from debugging?

Without knowing more, and with the understanding I currently have, I wonder if it could be that you need a higher VDD than 1.8V and the changes you did a week ago cause da change in the VDD voltage (which is output of REG0)? If so, that could match with that it works after you program a example firmware, which will set REG0 output voltage to 3.0 V in UICR. As long as you don't do a full chip erase that is kept. But if you do a full chip erase UICR is also erased, and in that case your new application must also set it to 3.0 V. (This may not be the issue though, both because I don't know if this is actually what is happening, of if 1.8 V is a problem for your application).

[njeester]

Thanks for the reply.

I've managed to narrow down the problem. It appears  erase&flash in VSCode causes the problem. I can succesfuly program with the command line command nrfjprog.

So to be clear I'm using the nRF52840dongle attached to a nRF52840-dk to program the dongle via a TC2050 lead.

I can generate a hex file in Segger IDE or VSCode and program with nrfjprog.

I can program the dongle from inside the Segger IDE as normal.

It seems just the erase&flash in VSCode causes a problem and stops the dongle being programmed until I program with an nRF5SDK based app. (Even though erase&flash reports success!).

I haven't yet had time to go any further, but I need to understand why does the reprogramming with an nRF5SDK app 'reset' the dongle, and why is the erase&flash causing a problem.

If you have any thought on that I'd be insterested but otherwise I'll keep plugging away.

(As used: nrfjprog -f nrf52 --program  /opt/nordic/ncs/v1.9.1/nrf/samples/bluetooth/peripheral_lbs/build_nrf52840dongle_nrf52840/zephyr/zephyr.hex --sectorerase --verify -reset)

[njeester]

Link to files www.dropbox.com/.../Archive.zip

[njeester]

The above were from VSCode deblocked dongle showing flash vs erase&flash.

Here

https://www.dropbox.com/s/ftiooy94mfu38y7/sectoreraseVSchiperase.zip?dl=0

is a comparison between the dumps with --sectorerase and --chiperase from the nrfjprog command.

[njeester]

Also please note the same thing happens with the elf file produced in segger of the same app. Unblock and program with --sectorease ok, program with --chiperase option app doesn't work.

Also tried an another dongle. Same thing.

[Einar Thorsrud]

Hi Nigel,

Referring to sectoreraseVSchiperase, the normal flash content seems to be completely different between flash_dump_chiperase.txt and flash_dump_sectorerase.txt. Is that expected, or is that for instance caused by a mistake when programming before dumping the flash content?

For uicr_dump_chiperase.txt and uicr_dump_sectorerase.txt however I see an interesting difference. In uicr_dump_sectorerase.txt pin reset is enabled by PSELRESET[0] and PSELRESET[1] both being set to 0x12 (18). Could that be relevant here? That you rely on the reset pin?

[njeester]

I have found the problem. In Actions->Kconfig BOARD_HAS_NRF5_BOOTLOADER was getting reset to y on a pristine build because I only did a save not a save to file. Everything seems to be working ok now.

Thanks for your help.