Breakpoint not working on nRF52

[gsmcmullin]

BMP is able to scan, attach, and load to flash, but hardware breakpoint in flash is apparently never hit.

Target: nRF52832 DK (PCA10040)
Reported by @MrZeroo00 on Gitter

dbg_out_backtrace.txt

Confirmed:

• Addresses are in the flash memory region
• GDB is correctly sending the request for the hardware breakpoint
• Backtrace after interrupting with ctrl-c indicates a call from main, so target did start up correctly

Apart from the strangeness in that the breakpoint is never hit, the register read after reset (vRun) returns all zeros. I suspected that the PC is being set to zero, and that the target would go directly to the fault handler when execution is resumed, but this appears to not be the case, given the backtrace.

[badrbouslikhin]

Binaries attached here nRF52_BMP.zip
Corresponding repo in examples/peripheral/blinky/pca10040/blank/armgcc/
Commit 306b165d097be964894eae001f591fe08fe0b1aa

Thanks!

[badrbouslikhin]

As suggested @gsmcmullin on Gitter, adding >target_options |= CORTEXM_TOPT_INHIBIT_SRST; to nrf51_probe() did the trick.
It also seems to be flashing more consistently. I was getting very frequently a time out error when trying to load the binary

[gsmcmullin]

From Gitter:

• Gareth McMullin @gsmcmullin 13:00
  @MrZeroo00 It's a total guess, but my suspicion is that there is some timing issue with the target coming out of reset. I suggest try adding t->target_options |= CORTEXM_TOPT_INHIBIT_SRST; to nrf51_probe(). If that still doesn't work, try adding a delay here: https://github.com/blacksphere/blackmagic/blob/master/src/target/cortexm.c#L452
  This may also be the cause of Sometimes Programming hangs on Nrf51 #191 that I can't reproduce.

• Badr Bouslikhin @MrZeroo00 13:28
  @gsmcmullin the first suggestion worked!!
  It also seems to be flashing more consistently. I was getting very frequently a time out when trying to load the binary

• Gareth McMullin @gsmcmullin 13:29
  @MrZeroo00 Great!
  That might be the Sometimes Programming hangs on Nrf51 #191 mentioned above.

• Badr Bouslikhin @MrZeroo00 13:31
  Exactly, looks related to Sometimes Programming hangs on Nrf51 #191

[dpiegdon]

On nRF52840 PDK (see pull request #271) I am unable to reproduce this issue. (program was in flash)

[joric]

I can't even flash nRF52840.

I'm using

set file=%~dp0ergo42_ble_master_default.hex
set bmp_opt=-ex load -ex kill
set port=COM8
mode %port% | find "RTS" > nul
if errorlevel 1 echo Port %port% not found && exit
arm-none-eabi-gdb.exe --quiet --batch -ex "target extended-remote \\.\%port%" -ex "mon swdp_scan" ^
-ex "file %file:\=/%" -ex "att 1" %bmp_opt%

It says:

Available Targets:                            
No. Att Driver                                
 1      ARM Cortex-M                          
 2      Nordic nRF52 Access Port              
 3      ARM Cortex-M                          
Attaching to Remote target failed             
Loading section .sec1, size 0xa000 lma 0x26000
Load failed                                   
The program is not being run.

It works with nrf51822 and programs built for nrf51822 but doesn't work with 52840 and programs built for 52840. Maybe it's a known issue?

[UweBonnes]

You should tell what verion of BMP you use!

[joric]

arm-none-eabi-gdb.exe --batch -ex "target extended-remote \\.\%port%" -ex "mon version"

Black Magic Probe (Firmware v1.6.1-205-gc5c0783) (Hardware Version 0)        
Copyright (C) 2015  Black Sphere Technologies Ltd.                           
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

Hardware is Bluepill board from Aliexpress, see https://github.com/joric/bluetosis/wiki/Uploading
Target hardware is 73-2G4M08S1C (nRF52840)-based from here https://github.com/joric/nrfmicro

Upd. upgraded to:

Black Magic Probe (Firmware v1.6.1-267-g302ff20) (Hardware Version 0) 

Used make clean && make PROBE_HOST=stlink as aways, uploaded with Demonstrator GUI.
Shows less duplicate devices this time but still doesn't work:

Target voltage: unknown
Available Targets:
No. Att Driver                                
 1      ARM Cortex-M                          
 2      Nordic nRF52 Access Port              
Attaching to Remote target failed             
Loading section .sec1, size 0xa000 lma 0x26000
Load failed                                   
The program is not being run.                 

When I try Att 2 (Nordic nRF52 Access Port), it says:

Target voltage: unknown
Available Targets:
No. Att Driver
 1      ARM Cortex-M              
 2      Nordic nRF52 Access Port  
warning: while parsing target description: no element found                               
warning: Could not load XML target description; ignoring                                  
PC register is not available                                                              
warning: while parsing target memory map (at line 1): Required element <memory> is missing
Loading section .sec1, size 0xa000 lma 0x26000                                            
Load failed                                                                               

I don't know should I write some kind of XML and would it work with it? I only have .hex file built with GCC, from nrf52 QMK branch (https://github.com/sekigon-gonnoc/qmk_firmware/tree/nrf52) built with

export NRFSDK15_ROOT=/mnt/c/SDK/nRF5_SDK_15.0.0_a53641a
make ergo42_ble/master

Hardware (E73-2G4M08S1C) appears to be working, I tried two modules and solder to SWD pins directly, it's all the same.

Upd.
OpenOCD with ST-Link V2 also detects the chip but fails with timed out while waiting for target halted. Please help.

Just checked, can't flash E73 nRF52832 either (tried .hex bootloader from here), same issue (Attaching to Remote target failed, Load failed). Maybe I'm doing it wrong? Should I press reset or something? nRF51 did not need reset or anything.

I was able to use SEGGER J-Link to write firmware:

nrfjprog -f nrf52

ERROR: The operation attempted is unavailable due to readback protection in      
ERROR: your device. Please use --recover to unlock the device.                   

nrfjprog -f nrf52 --recover                                                                                 
Recovering device. This operation might take 30s.                                
Erasing user code and UICR flash areas.                                          

AFTER THAT I was able to write firmware the standard way using BlackMagic. Is there a recover command or it's required to have J-Link to unlock the device?

[UweBonnes]

Probably your Programm uses Long time Deep Sleep and it is hard to attach to such a device. If you only want to reprogramm, attach to the Access port, understand the available programs with "mon help" and erase the device. But as full erase will set the Input/Output voltage to 1.8 Volt, reattach after full erase will only work with an Adapter that allows Level translation to 1.8 Volt. Attaching to the firts port with under reset may also work. If you want to debug a program in Deep sleep, Things are harder.

[joric]

@UweBonnes the matter was write protection. After "nrfjprog --recover" everything worked like a charm. Is there a command similar to recover or it's required to have J-Link for that? Looks like I can't run "mon erase" or "mon erase_mass" without attaching first (reset does not help, and can't attach to Access port either). I have J-Link and a lot of modules to test, just wondering if it's possible with BMP.
This https://github.com/AndruPol/nrf52832-recover also doesn't work (module I try is the very same E73-2G4M04S1B mentioned in the article):

arm-none-eabi-gdb.exe --quiet --batch -ex "target extended-remote \\.\%port%" ^
-ex "set non-stop on" -ex "mon swdp_scan" -ex "att 2" -ex "mon erase_mass"
Target voltage: unknown                    
Available Targets:                         
No. Att Driver                             
 1      Nordic nRF52                       
 2      Nordic nRF52 Access Port           
Attaching to Remote target failed with: T05

[UweBonnes]

Attaching to the second port and mass erasing via the Access port is what to do in that situation.