-
... openOCD and SWD it has become quite clear that the Espruino command debugger; may (most likely) not work for the nRF52840 DONGLE as that board is not an Original Espruino.
debugger;is javascript source debugger and should work on any board including nRF52840 DONGLE , only nrf51 microbit has it disabled to save binary size.
This debugger is unrelated to openocd and SWD. Also not sure you it can help you with '"D13" is not defined'create a new definition for say LED13 that actually toggles an external pin, that could be monitored with a VOM or scope, while simultaneously single stepping through using SWD with either the Segger tool or openOCD, or a combination of both. The single command digitalWrite() would be issued using the WebIDE, then take a peek at registers using the above described tool(s). Conceptually, is this the correct approach?
monitoring via checking the pin is easier but yes you can read (and write) memory in openocd without even stopping the code so before and after
digitalWriteyou can read GPIO registers to see what happened. no need to single step.as for "single stepping through using SWD" this is tricky on nrf52 devices when bluetooth is on. It doesn't work due to Bluetooth timing - you cannot stop/interrupt it, SoftDevice will notice this and reboot. However you can do it when turning bluetooth off. It works for me with 52840,52832 when I switch console to UART and then run
NRF.sleep(). After this I can break/single step/continue and it does not reboot.NRF.wake()enables bluetooth again.as for " single stepping through using SWD with either the Segger tool or openOCD, or a combination of both" - to single step C code you also need gdb. openocd alone does not provide direct commands to debug, it provides GDB server for gdb command to attach to. Segger tools also provides gdb server. So you attach opeocd, flash hex file and then start gdb with the elf file e.g.
arm-none-eabi-gdb espruino_2v10.158_xenon.elf -ex "target remote :3333"openocd listens on port 4444 for openocd command console and also starts gdb server on port 3333 . you can use both at the same time.
You are reading a single comment by @Robin and its replies.
Click here to read the full conversation.
fanoush
@Robin
Sun 2021.10.31
Following 'Gotchas' at:
While I read over the docs for the above advanced debugger, Segger, Python, WSL, Make, openOCD and SWD it has become quite clear that the Espruino command
debugger;may (most likely) not work for the nRF52840 DONGLE as that board is not an Original Espruino.I've made attempts at modifying the .py file pin definitions and have created a successful build. However, after flashing to the device, I continually receive 'not defined reference errors', despite the pin label is in fact there and mirrors the one in the nRF840DK board file.
I'm not able to get this to work, although it might be related to this post that will need a response first.
I also note that jspininfo.c is not updating correctly.
So, in order to create a simple task for a learning experience, I need to be able to issue a .js digitalWrite() command and then use for instance, openOCD to peek at the registers, and compare that detail with the chip .pdf doc.
My initial debug test case would be to create a new definition for say LED13 that actually toggles an external pin, that could be monitored with a VOM or scope, while simultaneously single stepping through using SWD with either the Segger tool or openOCD, or a combination of both. The single command digitalWrite() would be issued using the WebIDE, then take a peek at registers using the above described tool(s).
Conceptually, is this the correct approach?
Should it be necessary to run through pinutils.py or related files, is this done by using Python at the command line, similarly to how one would browser debug a .js or .php file?