The RP2350 has a few advantages over its predecessor, one of which is the ability to load firmware remotely via UART, as [Thomas Pfister] has documented on his blog and in the video below.
[Thomas] had a project that needed more PWM than the RP2350 could provide, and hit upon the idea of using a second RP2350 as a port expander. Now, one could hard-code this, but dealing with two sets of firmware on one board can be annoying. That’s where the UART bootloader comes in: it will allow [Thomas] to program the port-expander RP2350 using the main microcontroller. Thus he only has to worry about one firmware, speeding up development.
There are limits to this technique: for one, your code must fit into the RP2350’s RAM– but the chip has 512 kB. While 640 kB should be enough for anyone, 512 kB is plenty for the port-expander [Thomas] is working on. The second drawback is that your device now has a boot time of a second or so, since the UART connection is not exactly high-bandwidth. Third, using UART on the same pins as the bootloader within the program is a bit tricky, though [Thomas] found a solution that may soon be in the SDK.
[Thomas] also wanted to be able to perform this trick remotely, which isn’t exactly UART’s forte. RS-485 comes to the rescue, via TI’s THVD1450. That worked reliably at the 10m cable length used for the test. [Thomas] sees no reason it could not work over much longer distances. ([Thomas] suggests up to 100 m, but the baud rate is fairly low, so we wouldn’t be surprised if you could push it quite a bit further than that. The standard is good out to a kilometer, after all.) For all the wrinkles and links to tips and solutions, plus of course [Thomas]’s code, check out the blog. If you want to listen to the information, you can check out the video below.
We’re grateful to [Thomas] for letting us know about his project via the tip line, like we are to everyone who drops us a tip. Hint, hint.
Given that it is the new chip on the block, we haven’t seen too many hacks with the RP2350 yet, but they’re starting to trickle in. While a UART bootloader is a nice feature to have, it can also introduce a security risk, which is always something to keep in mind.
It might be interesting for a cubesat.
Hah, nice reference.
I wonder if that reference will survive billg’s departure from this world. It might…
“[Thomas] had a project that needed more PWM than the RP2350 could provide, and hit upon the idea of using a second RP2350 as a port expander” Why? there are plenty of dedicated IC’s that support multiple PWM channels vis SPI or I2C.
TL;DR: Sometimes the microcontroller picks you…
I built a project not that long ago involving 2 controllers like this out of necessity. One was built into an e-ink display to drive that and was intended to be the brains of the operation, but it wasn’t capable enough to also trigger 8 separate motor relays (I was one free pin short 😭). I couldn’t exactly replace that controller since it was built-in. So, I offloaded relay control and timing logic to a Pico over I²C. Now, any time I need to alter the firmware, I usually have to flash two devices, which is a pain since they are linked and talking to each other…I always have to make sure OTA code loads before anything touches I²C in case I changed something with the format, else risk one or both MCUs hanging shortly after boot, having to open the unit and manually flash both over USB to get back to a working state.
That project would have been a great use case for UART bootloading and I’ll definitely be keeping this in mind for the future!
I/O expanders usually cost more than the RP2350 (the A version is around a buck). There are a number of designs using an RP2040 or RP2350 as an I/O expander.
If there was a way (iirc some discussions on this point) to be able to program the FW into Flash then it would be even better.
Yeah, but I’ll need multiple boards, and the cable might get a bit longer, so I’ll dasy-chain them via RS-485 and they’ll just grab their commands from the line. That’s why. :)
haha i definitely agree but
the reason specifically that i love my rp2040 pico boards is that they’re “so cheap you can use them as an I/O relay.” they’re exactly at that point where, realistically at my production volumes and lead times (i.e., fooling around), i can’t imagine a cheaper product. if i don’t happen to have one sitting around then in practice even a 74138 ($0.69 digikey) or whatever is simply not cost-competitive with a $4 board that i already have a pile of.
the fact that they’re so powerful is nice but what really drew them to me is that they’re as expendable as a pic12 was 15 years ago
Interestingly, if you look at the initial commit of the bootrom repository you’ll find design documents that talk about a I2C bootloader option as well. Not sure why they ultimately dropped that feature, but the QSPI pins still have the I2C interfaces multiplexed to them.
‘Noymt having to deal with second firmware’ is balloney though. You just fkash it drom uart instead of eeprim now …
Oth very nice!
Could this use the debug port instead? The advantage being that the target chip has all its normal pins fully available. The PicoProbe is already a RP2 chip and programs another RP2 chip. Leaving the debug interface open would leave your code open, but if you’re making an open source project then why not do it?