blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.27k stars 774 forks source link

Firmware upload on Arduino Nano 33 BLE fails every other time #573

Closed manuelbl closed 2 years ago

manuelbl commented 4 years ago

I'm using the BMP with PlatformIO and an Arduino Nano 33 BLE (nRF52840). Debugging works but firmware upload reliably fails every other time. In particular, it fails after resetting the Arduino (by power cycling or pressing the button on the board).

The executed command is:

arm-none-eabi-gdb -nx --batch -ex "target extended-remote /dev/cu.usbmodemC1CA9EF71" -ex "monitor swdp_scan" -ex "attach 1" -ex load -ex compare-sections -ex kill firmware.elf

And the output is:

Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      Nordic nRF52 M3/M4
 2      Nordic nRF52 Access Port 
hal_sleep () at ./mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/sleep.c:87
87    ./mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/sleep.c: No such file or directory.
Error erasing flash with vFlashErase packet

The error message on the last line is from the load command.

With a debug version of BMP I have narrowed down the problem to this line:

https://github.com/blacksphere/blackmagic/blob/master/src/target/nrf51.c#L165

Further investigations showed that the error will always occur on the first target_mem_... call. In fact, it looks like it's already pending before the function is called. It goes away with a call to target_check_error() before line 160.

I'll will further investigate it and come up with a PR. So stay tuned.

manuelbl commented 4 years ago

It looks as if I found the root cause. On the Arduino Nano 33 BLE, the reset signal takes a long time to return to the high state:

Arduino Nano 33 BLE

For comparison, a Nordic nRF52840-DK:

Nordic nRF52840-DK

As a result, all memory read and write operations in cortexm_reset() fail as the MCU is still stopped. Furthermore, a fault condition is still pending.

I'll prepare a PR that waits for an additional 1ms after toggling the SRST.

esden commented 2 years ago

Considering that @manuelbl closed #576 without a merged solution I assume this is still a problem? Do we have an alternate solution? Does it still need to be implemented?

perigoso commented 2 years ago

@esden / @dragonmux it seems to have been handled by Uwe in effd43ce38a3d9d4d3339ff4e0f416bccd2f997a and I believe can be closed

dragonmux commented 2 years ago

Hi Perigoso, thanks for finding that. Closing.