Failed to download firmware in Segger Embedded Studio

[kokheng]

Hi,

I have an error to download firmware in nRF52840-DK, from output console show it failed at verification on address 0x00000000. 

I try to compile the light switch example from "\examples\light_switch\client\" folder into two nRF52840-DK boards but somehow only one board success, Can you help me to figure out what happens?

Thanks 

Output Console

Preparing target for download
Executing script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading ‘s140_nrf52_6.1.0_softdevice.hex’ to J-Link
Programming 2.5 KB of addresses 00000000 — 00000a17
Programming 147.6 KB of addresses 00001000 — 00025e7b
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (155648 bytes)
J-Link: Flash download: Total time needed: 2.345s (Prepare: 0.048s, Compare: 0.018s, Erase: 0.000s, Program: 2.267s, Verify: 0.003s, Restore: 0.008s)
Verification failed @ address 0x00000000

[kokheng]

when I use the nRF Connect v2.6.1  - Programmer app, it will always be hanged when I flash the s140_nrf52_6.1.0_softdevice.hex.

Is this indicate that the board flash got a problem?

 

[Bjørn Kvaale]

Can you please try to download the light switch example via Segger Embedded Studios? First erase the board (either via nRF Programmer app) or via nrfjprog. Then, compile the example in SES. Next, press Target -> Connect J-Link. Then, press Target -> Download <project name>, where project name could be ble_app_blinky_pca10040_s132 or light switch_pca10040... for example. Does that work?

[kokheng]

Hi Bjorn 

I just have another round of testing,

• use Mesh SDK 3.0 +  light_switch_client_nrf52840_xxAA_s140_6_1_0.emProject
• use ID SES v4.12 to build the project and download two nRF52840-DK and the result show that
  • one nRF52840-DK (1) success download the firmware
  • one nRF52840-DK (2) failed to download the firmware, return flash verification error
• Verify the hex file with nRF52840-DK (2) flash memory, found the hex value is not exactly the same

Thus, can you make a comment on this issue? I would like to ask Element14 to return a new nRF52840-DK if you think this is a hardware flash failure. 

Thanks   

[Bjørn Kvaale]

It may be a HW issue, but before we assume that, one more test. Could you please download nrfjprog, then erase the first board via: nrfjprog --eraseall. Then, upload the softdevice via nrfjprog --program path_to_hex_file. The softdevice hex file can be found here: $(SDK_ROOT:../../../../nRF5_SDK_15.2.0_9412b96)/components/softdevice/s132/hex/s132_nrf52_6.1.0_softdevice.hex.

Lastly, use the same command to program the application, which can be found in the build folder. Then, do nrfjprog -r to do a soft reset of the board.

Also, could you please try to do nrfjprog -i. You should receive a number back for both boards.

[kokheng]

Thanks, Bjorn.

please see the result on below two pictures. 

1) number for bad Board - 683620689

2) number for good board - 683607274

[Bjørn Kvaale]

Interesting. It seems like it worked to program both boards via nrfjprog, which is a good thing. Could you please check to make sure all of the switches on the 52840 DKs are in the same positions when you compare the board that works & the one that does not work?

Also, have you by any chance cut the solder bridge to measure current via the PPK by any chance?

Could you please try an nrfjprog --eraseall on both boards & try to program via Segger Embedded Studio one more time. Also check that the usb is plugged in correctly on the DK when programming.

[kokheng]

1) The switches in both good and bad board have the same position. 

 2) I do not have Power profile kit in my hand, and if I cut the solder bridge on the board, which meant that need to damage the board. I'm not sure element14 still accept my board or not, can we have another method?  

3) I tried to erase the board either using nrfjprog or Segger Embedded Studio (connect to Jlink). The result still same as above. 

4) I use the same USB cable connects to both boards, and make sure the USB fully plugged into computer USB. The result still seeing the bad board return flash problem. 

[Bjørn Kvaale]

2) I did not mean that you should cut the solder bridge. I was just wondering if you did or not. If you did, you would have needed to attach a jumper to P22.

What you can do is try to flash the interface mcu to the nRF52 DK one more time. Turn off the DK & turn it back on while pressing the IF BOOT/RESET button. You should then see the DK appear as a BOOTLOADER drive. Drag & drop the downloaded Interface MCU FW to the malfunctioning DK. Power cycle the board one more time & try to program by via Segger again.

[kokheng]

1) manage to place the bin file (i.e. J-Link OB-SAM3U128-V2-NordicSemi 170724.bin) to the DK. 

2) Power cycle the board again

3) Program the DK via Segger, but it requires firmware Update 

      

4) After I press No button, it failed to connect J link.

5) Thus, I repeat the step from 1 to 3, and then press Yes button to run the J-Link V6.40 Firmware update

6) After executing the firmware update, it will go to flash the example code into flash and then same flash error come again.

Please let me know if my step is not correct or bin file download is not the latest version. Thanks

[Bjørn Kvaale]

You chose the correct interface MCU FW. It was also correct to update the J-Link FW. Could you try an nrfjprog --recover command on the faulty board & then try to program the board again via SES? Does this work?

P.S. If you add the nrfjprog command to the system path (i.e. Environment variables), you won't need to be in the nrfjprog folder to execute the command.

& just so I understand correctly. Programming the softdevice & the light switch example worked via nrfjprog on both boards, correct? Seems like it from the command line log you provided.

[kokheng]

1) using nrfjprog --recover then program again via SES ---> this method doesn't work. 

2) and yes, both boards are able to program using nrfjprog command but the faulty board didnt pass the flash verification. 

Can I make the conclusion that the faulty board unable to recover by Nordic tools and require to send for hardware inspection by element14?

When compare flash memory found some hex value is not the same.  

[Bjørn Kvaale]

Yes, I believe we can conclude that this could be a faulty board. Ask element14 to check the HW.