Debugging of Realtek Ameba chips is possible and was tested with OpenOCD running remotely on a Raspberry Pi.
(the following is applicable to Arduino framework, and was not tested with SDK framework)
LibreTiny has ready-to-use OpenOCD config files:
It should be possible to use PlatformIO's built-in debugging capabilities directly, when plugging an OpenOCD-compatible debugger into your PC. As there are no debugger interfaces built into these IoT boards, you need to specify your interface of choice in
<interface name>is for example
Using a Raspberry Pi is probably the easiest option (and cheapest, as everyone has a spare Pi laying around).
Connect your Realtek board to your Pi, as per Programming Microcontrollers using OpenOCD on a Raspberry Pi.
Check out RPi BCM2711 GPIOs to read more about BCM pin mappings.
TL;DR: Install OpenOCD. Conenct A14 to BCM GPIO#11, A15 to BCM GPIO#25. Remember to join GND together. Refer to boards/ for pinouts.
On Raspberry Pi 4, additional config might be needed:
-f file.cfg. Read more here.
Start OpenOCD like this (you also need your config file in the working directory):
platformio.ini not to start local OpenOCD:
Done, go to PlatformIO in VSCode (or whatever you're using) and click
OpenOCD should show this if everything is connected properly:
alpine:~$ sudo openocd -f interface/raspberrypi2-native.cfg -f amebaz.cfg -c "bindto 0.0.0.0" Open On-Chip Debugger 0.11.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html BCM2835 GPIO nums: swclk = 11, swdio = 25 Warn : Interface already configured, ignoring Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 1001 kHz Info : SWD DPIDR 0x2ba01477 Info : rtl8711b.cpu: hardware has 6 breakpoints, 4 watchpoints Info : starting gdb server for rtl8711b.cpu on 3333 Info : Listening on port 3333 for gdb connections
PlatformIO will reset your board by default when starting debugging. Sometimes this may not be desired. Also the current config is a bit buggy: VSCode thinks the board is halt, but it's actually running so you need to press continue for that first time.
To disable auto reset before and after debugging:
[env:my_board] debug_init_cmds = target extended-remote $DEBUG_PORT ; remove this line if you're debugging locally $INIT_BREAK ; monitor reset halt $LOAD_CMDS monitor init ; monitor reset halt
GDB is first configured with
mem 0x8000000 0x8200000 ro in order to mark flash memory as read-only. This makes GDB use hardware breakpoints, as software BPs don't work on these boards.
More powerful playground
Microsoft Windows [Version 6.1.7601] [email protected] C:\Users\Kuba # telnet 192.168.0.33 4444 Open On-Chip Debugger > mdw 0x8000000 0x08000000: 96969999 > halt target halted due to debug-request, current mode: Thread xPSR: 0x61000000 pc: 0x0000b462 msp: 0x1003ef5c > reg ===== arm v7m registers (0) r0 (/32): 0x035a9584 (1) r1 (/32): 0x00000015 [...] ===== Cortex-M DWT registers > resume >
Useful OpenOCD commands
Run them in your power playground.
Doesn't even disconnect from WiFi (which confuses the code and makes it disconnect anyway).
UART upload mode
(or something that looks like it)