BaSzErr - blog:2024:11:24

2024-11-24_-_remote_flashing_embedded_device

anonymous@undisclosed.example.com (Anonymous) — Sun, 24 Nov 2024 20:19:35 +0000

2024-11-24 - remote flashing embedded device

recently, when working on YALS pet-project, i had a need to flash the board via attached programmer… but in such a way that would not back-feed 12V to my PC, in case i mess sth up in wiring / design. the answer was simple – just use SBC with WiFi, that can be considered disposable, in case of a hard-failure.

my weapon of choice was raspberry pi zero W, as it's:

small
cheap
WiFi-enabled
can natively support SWD for RP2040 flashing

i must say – it worked like a charm! :) at the end of the day i managed to not release any magic smoke from either of the boards. yet stil knowing that i have a proper, physical isolation between my PC and test circuitry kept my mind calm and allowed me to focus on the real deal.

2024-11-24_-_unbricking_rp2040_from_watchdog_reset_loop

anonymous@undisclosed.example.com (Anonymous) — Sun, 24 Nov 2024 20:58:35 +0000

2024-11-24 - unbricking rp2040 from watchdog reset loop

recently, when working on YALS (more info on the project here), i found myself in an odd situation. on the last day of coding SW for it, as the very last feature, i've added watchdog support. device has a real-time processing cycle of 4ms, so i decided that watchdog should fire if we miss it 10x, as this should be fast enough prevent any observable effects, yet long enough to make sure a micro glitch would throw thing of the course.

after writing a small HAL, i wrote a manual test application, just to see if it worked. so the app just printed how long it will sleep before resetting watchdog… and finally, when it reached 40ms, watchdog kicked in, and application started all over again. brain-dead simple… and a bit of a trap! now it reset all the time. w/o a way to stop it… and i was not able to flash it again, since OpenOCD flashing required more time to start the process, than i had available between watchdog resets.

but wait – you may know that RP2040 is unbricable by design, right? you can always press the boot button and upload a different *.uf2 file to unbrick it. easy as that… except that YALS, due to space constraints, does not have USB. whoopsee… so the fun begun!

take 1: bruteforce

the first attempt was simple – just run:

while ! rp2040_openocd -c "program hello_world.elf verify reset exit"
do
  date
done

…and pray. while it was running i started to read and think about a different take on my problem.

turned out that i was fortunate enough to setup watchdog just long enough, that i finally managed to grab a window of opportunity and flash a small program. it took a while, but proved it's possible. that kept my mind at peace. through the journey to find a better way out.

btw: i'm using rp2040 SDK project for all the steps here.

take 2: gdb

while it turned out to be exceptionally difficult to do bruteforce-flashing hack, it turned out that it's ok to connect openocd to a running system, and not lost it when watchdog resets CPU. that was a big foot in the doors. next good news is that stopping CPU by attaching to a process also stopped watchdog timer. the bad news was that this mode also prevented flashing…

so the next life hack was to start gdb, then load new program into the RAM (note that flash is still unchanged). the bad news is that it still kept watchdog running…

that's where rp2040 HAL sources came in handy! watchdog lives in a register that's mapped to RAM address 0x40058000, at bit 30. so the way to top watchdog (during this run) is to one a terminal and run openocd:

rp2040_openocd

and then in another one launch gdb and type in the following commands:

target remote localhost:3333
p (*(unsigned*)0x40058000)=0
load "hello_world.elf"
continue &

what it does is:

connect to remote target (rp2040)
clear watchdog-enabled bit (wrote to whole 32-bit word, but who cares?)
load some non-watchdog-enabled program
continue it in a background (so that gdb can be stopped)

now i was able to disconnect and use regular rp2040_flash to write new program (w/o watchdog reset loop) into flash.

for a brief moment i though this is going to be my safe-house, and wrote a helper rp2040_load that automate all of this in a single, simple script, that's just parametrized with a new *.elf file to flash.

take 3: make it right with openocd

so i had a working solution, that was fast and reliable… yet it still smell like a big hack from a mile. can i make it less of a hack? what if openocd would help sth that could help with that… turned out that it has! there's a command that can write to arbitrary RAM location… so we can now do watchdog turn-off faster, with a simple:

rp2040_openocd \
  -c "init" \
  -c "rp2040.core0 mww 0x40058000 0 ; exit"

for convenience rp2040_disable_watchdog was added to SDK, too. now it's also a default part of rp2040_flash to make sure watchdog never bothers developer again.

2024-11-24_-_yet_another_linear_servo

anonymous@undisclosed.example.com (Anonymous) — Sun, 24 Nov 2024 20:59:07 +0000

2024-11-24 - Yet Another Linear Servo

recently had some time off and decided to push forward one of my pet-projects: YALS. TL;DR recently i needed a good linear servo for another project. some key aspects were:

non-backdriveable (so that it does not consume current when not moving)
digital controlled with feedback (controllable from host, with telemetry, etc.)
big throw (here: 100mm)
ease of adding magnetic coupling (if needed)

this was an interesting experience as it was the 1st time i've designed RP2040-based HW platform and wrote a bigger piece of code for it (~5KLOC). on top of that it also used a cheap SBC for programming remotely (over WiFi), to make sure that high-current 12V power supply won't by accident backfire over 5V TTL logic wires to a PC. it was also an interesting experience to unbrick CPU from watchdog reset loop.

after ~week of full-throttle fun, the project has now reached v0.3 with all key elements working and tested! :D

the only exception atm is EEPROM, that for some magic reason seems to get stuck when writing (failed batch?). that will require some more investigations, but fortunately it's not crucial for functioning of the servo.