Conceptual comments needed on simple firmware debug example - will this work?

[espruino-discuss]

Posted at 2021-10-31 by Robin

Sun 2021.10.31

Following 'Gotchas' at:

https://www.espruino.com/AdvancedDebug

https://www.espruino.com/Debugger
'it is available for all official Espruino boards.'

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.

Uncaught ReferenceError: "D13" is not defined
 at line 1 col 15
digitalWrite( D13, 1 )

I'm not able to get this to work, although it might be related to this post that will need a response first.

Where should constant PROJ_NAME be changed

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.

the instructions at https://www.espruino.com/AdvancedDebug require a bit of implied knowledge awareness

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?

[espruino-discuss]

Posted at 2021-11-01 by @allObjects

@robin, for me, there are really two types of debugging:

• The high level debugging that Espruino provides - using the Espruino IDE built-in debugger which knows all about Espruino, it's genuine Espruino boards, their setup, etc. This debugger is a peer to the Espruino interpreter on the board.
• The low level debugging thru the SWDIO - using what ever tool supports that with the knowledge of the hardware in it basic / native form, which knows zip about Espruino.

In order to make the first one work for other - non-Espruino boards - I assume it has to be modified to do what is required for those boards.. For me, changing the board descriptor seems not to be enough. There are other things that require modification (or would need generalization with configuration, which would bloat not only Espruino, but also the busy-work for @gorden (and as you know, busy work provides not only no gain - and is also not (enough) a catalytic... it just cuts into the actual gain to the point where all becomes a loss...).

PS: @robin, I guess I'm not providing any new insight to you in this post... :\ ...

---

Posted at 2021-11-01 by @fanoush

... 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 digitalWrite you 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.

---

Posted at 2021-11-01 by @allObjects

@fanoush, Ic. Concluding from your statement

should work on any board

I gave the debugger a bit too much Espruino credit... ;_)

---

Posted at 2021-11-02 by Robin

Mon 2021.11.01

PS: Robin, I guess I'm not providing any new insight to you in this post... :\ ...

Your responses are always welcome @allObjects as others that read over these words of wisdom will gain additional insight as you pointed out in the other thread.

@fanoush thank you. I'll respond later this week, out of time this evening. . . .