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)

[Einar Thorsrud]

Hi,

Ah, it is interesting that the issue here is only flashing from VS Code, and that it works if you flash the same hex file yourself using nrfjprog. VS Code also use nrfjprog (via west), but apparently there is an issue here. Can you copy-paste the log you get in the terminal in VS code when you program from there?

I notice that you use --sectorerase when you program with nrfjprog. Is there anything else that should be kept from before, or would it work just as good if you did a full chip erase and then programmed? Also, how does that work if you do it from VS Code (first erase the chip, then program it)?

Which version of VS Code and the nRF Connect for VS Code plugin do you have?

[njeester]

Hi, tried the above:

Programming nRF52840-dongle, via nRF52840dk with dongle powered of dk
board and connected via TC2050

From the tests below.
a) --chiperase works ok with nRF5SDK app.
b) --chiperase and --eraseall blocks the nRFConnectSDK app from running
though programming appears successful
c) In VSCode erase works on a 'non-blocked'  board (i.e reset as
shown below).
d) In VSCode erase&flash fails to let the app run though appears
succesfully programmed. 'Board blocked'
e) (Re)Programming with nRF5SDK app 'unblocks' the board.


Versions
========
VSCode Version: 1.66.2
nRF connect for VS Code v2022.3.104
nrfjprog version: 10.15.4 external
JLinkARM.dll version: 7.58b
Toolchain Manager 0.10.3 (Terminal opened from Toolchain menu for command line tests)

Tests
=====

1) 1. The nRF5SDK app ‘resets’ the board (note using —chiperase option).

****RESET DONGLE WITH PRGRAMMING THIS APP****
nrfjprog -f nrf52 --program
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFProjects/Feeder2021ClassicV11-
InstalledHighTorquecopy/pca10059/s140/ses/Output/Release/Exe/feeder.hex
--chiperase --verify --reset --snr 683934038
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.
*****App working******

2)The zephyr app can then be programmed (using —erasesector option).

nrfjprog -f nrf52 --program
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
/zephyr/zephyr.hex --sectorerase --verify --reset --snr 683934038
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.

***app working*****

3) First doing an eraseall before a programming action - app does not
work.
nrfjprog -f nrf52  --eraseall  --snr 683934038
Erasing user available code and UICR flash areas.
Applying system reset.

nrfjprog -f nrf52 --program
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
/zephyr/zephyr.hex --sectorerase --verify --reset --snr 683934038
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.

***APP NOT WORKING****

4)Reset app and succesfully programme zephyr app with --sectorerase, but
fails with --chiperase.
****RESET DONGLE WITH PROGRAMMING THIS APP****
nrfjprog -f nrf52 --program
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFProjects/Feeder2021ClassicV11-
InstalledHighTorquecopy/pca10059/s140/ses/Output/Release/Exe/feeder.hex
--chiperase --verify --reset --snr 683934038
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.
****app working****


nrfjprog -f nrf52 --program
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
/zephyr/zephyr.hex --sectorerase --verify --reset --snr 683934038
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.

*****app working******

nrfjprog -f nrf52 --program
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
/zephyr/zephyr.hex --chiperase --verify --reset --snr 683934038
Parsing image file.
Verifying programming.
Verified OK.
Applying system reset.
Run.

*** APP NOT WORKING ******

5) VSCode erase and flash on 'non-blocked' board -
Flashing build to undefined
west flash -d
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
--skip-rebuild -r nrfjprog --snr 683934038

-- west flash: using runner nrfjprog
WARNING: runners: Argument --snr is deprecated, use -i/--dev-id instead.
-- runners.nrfjprog: Flashing file:
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
/zephyr/zephyr.hex
Parsing image file.
WARNING: A programming operation has been performed without --verify.
WARNING: Programming can fail without error.
Enabling pin reset.
Applying pin reset.
-- runners.nrfjprog: Board with serial number 683934038 flashed
successfully.

Terminal will be reused by tasks, press any key to close it.

*****app working******

> Executing task: nRF Connect: Flash peripheral_lbsx/build (active) <

Flashing build to undefined
west flash -d
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
--skip-rebuild -r nrfjprog --snr 683934038 --erase

-- west flash: using runner nrfjprog
WARNING: runners: Argument --snr is deprecated, use -i/--dev-id instead.
-- runners.nrfjprog: mass erase requested
-- runners.nrfjprog: Flashing file:
/Users/▦▦▦▦▦▦▦▦▦/Development/nRFConnectSDKProjects/peripheral_lbsx/build
/zephyr/zephyr.hex
Parsing image file.
WARNING: A programming operation has been performed without --verify.
WARNING: Programming can fail without error.
Enabling pin reset.
Applying pin reset.
-- runners.nrfjprog: Board with serial number 683934038 flashed
successfully.

Terminal will be reused by tasks, press any key to close it.
*** APP NOT WORKING ******

[njeester]

Correction:

c) In VSCode flash works on a 'non-blocked'  board (i.e reset as
shown below).

[Einar Thorsrud]

I am not able to explain this. Are you able to debug in the case when the app is not working? What do you find by debugging? Also, what if you dump the flash content and UICR and compare between working and non-working case. What is the difference?

A simple way to dump flash in an easily readable way is like this:

nrfjprog.exe --memrd 0 --n 0x100000 > flash_dump.txt
nrfjprog.exe --memrd 0x10001000 --n 0x1000 > uicr_dump.txt

[njeester]

I cannot debug with a non-working app "Disassembly not available".

Here are the dumps appropiately labelled.

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