I’ll finally get my framework 16 laptop soon, so I’m thinking about some useful extensions for it. I do a lot of embedded programming and for my personal projects I mostly use the Raspberry Pi Pico. I have one laying around which I use specifically as a debugger, also sometimes for other platforms.
So for my framework laptop, I was thinking about integrating this in an expansion card. Of course it would be extra cool to be able to use this card as an SWD debugger for external boards as well an internal dev board . And even cooler, to be able to easily debug the internal dev board, too!
Basic Requirements
Easy to use without requiring changes to my existing tooling and workflow
Fast changes between use as a dev board and debug probe possible
Functionality of the dev board should be similar to raspberry pi pico (all interface types should be usable, but one of each type is enough, onboard LED visible from the outside, same flash size and crystal frequency, boot select button)
General Idea
Use two RP2040 chips, one running picoprobe, the other as a general purpose dev board. I should be able to use most of the electronics (e.g. power, crystal) for both chips.
Open Questions
Of course the main one: Is it possible to fit this into a regular-sized expansion card? This comes down to two things, I guess, IO and required board space.
Regarding IO: From my aforementioned requirements I derive a need for 8–10 GPIO pins, 1 LED, 1 push button, and a miniature switch. This will be tight, but probably doable.
Regarding board space: If I use the smallest available components and PCBA, this is probably also possible. The feasibility may depend on what additional components the dual-RP2040 design will require:
Do I need an additional flash chip for the second RP2040? Or is it maybe possible to boot both of them from different sections of one (larger) QSPI flash chip?
What is required to switch from internal dev board to external debugging? This requires some way to block the debug chip from talking to the GPIO pins when not in external debug mode, as well as block or maybe even power down the dev chip when in debug mode.
How to handle the USB communication? The simplest option would be to have only the debug chip connected to the data lanes. But I’d like to also be able to install firmware images on the dev board via USB. This would require either to switch the data lanes over to the dev chip or a simple USB hub, so both chips are connected via USB.
I’m really curious what you think of this idea. Do you believe this is possible? Can you think of a simpler solution for my requirements?
I obviously still have to do a lot of research regarding the open question, but maybe someone here knows the answers already and can speed this up, that would be highly appreciated!
I highly doubt that’s easily possible, the rp2040 does change settings on the flash during runtime which would cause the 2 to trample over each other. You could potentially share the oscilaor though if you use an oscilator instead of just a crystal.
You could just put a simple 2p2t switch on the 2 debug lines and have them either connected to the internal board or external pins.
Only having one on usb would certainly be the easiest way. Even a simple usb2 only hub is going to take up a signifficant bit of you quite limited board space. Which you probably can’t aford given your other requirements.
The simplest option may be just barely possible without going oversized imo but it’s gonna be tight.
I took a look into the datasheet regarding this, which gives a few options:
Use the internal ring oscillator (default)
Use an external crystal
Use an external clock source
I couldn’t find anything in the picoprobe code base suggesting they configure it to use the external crystal, but the datasheet basically says a crystal is required to achieve the timing accuracy required for USB, so I might just not have found it.
One option might be to modify the picoprobe firmware to output an additional reference clock signal to the dev chip. Though for this it seems to be necessary to deactivate the oscillator circuit on the dev chip which means I would need to adapt any code I would want to run on this dev board vs a regular raspberry pi pico.
Maybe using two crystals is the simplest option after all, if I can get them onto the board.
As the connector is the biggest part of the project, I’d like to keep it as small as possible. So it would be best not to need any additional debug pins, though this requires not only switching the debug lines over but also isolating the dev chip from the pins when the card is in external debug mode.
I think the best solution for this might be to power down the dev chip. Because it’s fairly simple to implement without a lot of additional parts, while at the same time reducing unnecessary power draw when the dev chip isn’t needed.
I agree. The dev chip would only need USB connectivity for the USB boot mode, which would also require a boot select button and either an additional reset button or other circuitry to reboot the device if I wouldn’t want to unplug the module each time I want to USB boot. Which would all take up a fair amount of precious board space.
I also barely ever use this feature, mostly wanted to add it in case other people want to use my design and require this. So I’ll strip it at least for now.
The rp2040 needs an external oscillator or crystal, I’d recommend you get an oscillator, it’s a bit more expensive but same footprint and doesn’t need matched ballast caps and you can share it between your 2 micros.
It just straight up worn’t run without the clock.
No need you can share the oscillator.
You would also need to prevent it from messing with the pins wile off (like pulling in one direction), or powering on from them. Would need to test that first.
You could just not usb boot the second one and only flash/reset it via the debug port.
Like this one for example?
Do I understand it correctly, that pin 1 of the linked oscillator acts basically as an enable pin?
Can’t find it right now, but I’m pretty sure I read somewhere that the GPIO pins go into high impedance mode when the chip is powered down. The analog pins can cause issues, but they will never be connected to the debug lanes anyway.
Yes, that’s exactly what I meant, sorry if I expressed that too complicated .
Any suggestions for a 10 pin, 2 row, 2.54mm, edge-mounted connector? I tried to find something via google and digikey, but no luck so far.
A smd mounted horizontal one might also work, but I couldn’t find that either.
The leads of the tht connectors unfortunately make the connector really big.
Edit: I was able to find that, but I’ll have to see if it’s going to work with the housing dimensions.
Mounting a vertical tht connector on the edge might work, too. Though that’s a bit less elegant.
Err, yes, they will go into a high impedance mode, but if you have something driving those pins high then you are likely to phantom power the chip through the ESD protection diodes.
So whatever could be driving those pins also needs to be in a high impedance state.
I did a first layout attempt. I think it will work, but it’s really tight .
The connector definitely needs to be edge mounted, otherwise it’s way too tall for the housing. The switch maybe, too, I haven’t found any small and flat enough to fit on the pcb and in the housing.
That is one reason this really needs to be tested before it is relied on. Luckily the rp2040 is a relatively power-hungry beast so it takes quite a bit of power to start it.
I could have told you that before you started XD, I’m honestly kinda surprised how not cramped it is, you could probably single side it.
Part searching hell let’s goooo
You aren’t sharing the 1.1V rail between the picos right?
Yes, I also thought it might be worse than it is. I expected worse for the main circuit, though I underestimated how tight the connector and especially the switch would be. This is certainly the tightest project I ever worked on.
Not sure about single side though. Especially with the connector edge-mounted so I can put nothing on the opposite side of the pcb. The connector leads will then also take away some more board space compared to the current design. But it might work if I put most to all of the traces on the back and inner layers.
The current design uses 2 inner layers for the power delivery (3.3 V and the switched 3.3 V for the dev chip, so I can turn it off), but I hid them for the screenshot. I also run the two ADC signal traces on one of those layers because they run kind of perpendicular to everything else.
No, I think this would create a lot more problems than it might solve . The 1.1 V section is pretty well self-contained, mostly below the chip.
You could just hold it in reset to turn it off, probably also better for potential phantom power issues.
It would not solve any problems you just should not do it, I was just asking cause it is a mistake that could relatively easily happen to me when doing the schematic.
That’s a great idea! Less possible issues and less parts.
Theoretically it should be possible as the datasheet describes using an external power source for the 1.1 V supply.
But yes, this is definitely an easy to make mistake … especially as I noticed at some point that KiCad put them on the same net from the schematic . Maybe I should use local labels instead of the (now obviously global) power labels to prevent this issue.
Edit: Btw. I have to say, the RP2040 documentation is amazing! I don’t think I have ever seen such a nice hardware documentation.
You can change the voltage level for that rail in software for overclocking/underclocking so if you just tied them together they’d be fighting each other. But if you did use an external regulator you could bypass that.
Now that I think about it this may be the reason phantom power isn’t an issue cause the leakage through the esd diodes would not power the core.
This approach has one downside, though, regarding power consumption.
I couldn’t find anything about the power draw in reset in the RP2040 datasheet. So I did some measurements myself. My raspberry pi pico, running the picoprobe firmware, draws ~22.7 mA when fully powered on, ~1.2–1.3 mA in reset and only 339 µA when the 3.3 V rail is disabled.
I can’t say how noticeable this difference would be in practice, though.
But yeah being held in reset will cause it to consume a little more power than completely disconnected from power. A whole ma seems like a bit much though but there is a lot going on on the pico.
On the raspberry pi pico there is a bit of circuitry before the voltage regulator. So the resistors and maybe even the regulator chip itself will still draw a little bit of power when the regulator is in the disabled state.
There is even an application note from the pi foundation on switching power to the rp2040 chip for low standby current applications.
Still draws ~1.1 mA in reset mode when powered directly by 3.3 V. So no big difference there.
I’m wondering how much battery life this would cost me if the module is plugged in e.g. for a day. If it’s just a few minutes, I wouldn’t mind. But I don’t know enough about the battery side of things here to calculate that myself, or even just make a rough estimate.
Edit: Alright, according to DigiKey it’s just a simple division – leaving 5491 hours of runtime on the framework 16 from just this load. Meaning this will use about 0.4% of the battery life during one day.
For an estimated 5 h of battery life under medium use, this means about one minute less battery life. Which should be fine, I guess.
Assuming that my very crude calculations are correct .
. And even cooler, to be able to easily debug the internal dev board, too!
.
