using a pi 400 to debug a pico

It doesn't say so, but when he says "raspberry pi" I think he means a Pi3. I'll be using a Pi4, inside the Pi400 unit, but I expect the pins are the same on its 40-pin header.

Oh, I found a reference in the book "Programming the Raspberry Pi Pico/w in C". Looks like the same pins, GPIO24(18) and GPIO25(22).

Thanks

I'm designing a PCB that will have a 40 pin ribbon cable connector to the Pi400 and a 20-pin ribbon to the various RP2040 target boards. It will do the debug connection and have a bunch of scope mux's and DVM mux's and stuff, to make it easy to time code execution and check the power supplies and such.

Looks like I can power my board from the 40 pin header too.

What debug software are you planning to use? OpenOCD?

The pinout seems to be quite flexible - look at interface/raspberrypi-gpio-connector.cfg in the OpenOCD sources / distribution.

If you want something nice with level translation that handles power sequencing between Pi and Target board, the JTAG Hat should do what you want:

I think this should also work an a pi400.

cu Michael

It is linked in the description:

It's basically a bunch of 74LVC2T45 (which handle the "one side powered down" as well as the level-shifting), plus open-drain drivers for the reset signals. Note that you need to switch direction for the SWDIO signal, the rest is unidirectional.

cu Michael

This is a first pass at the dev board.

It would be used in development and production test. Every RP2040-based board would have the small-pitch 20 pin ribbon cable header.

The pushbuttons look primitive but will probably work.

Definitely. Otherwise, when powering down one side of the link (eg. the RP2040 target), current from any data line being "H" will flow through the target's protection diodes into its VCC.

This leads to all kinds of problems (like the device not properly starting when powered up again). It will probably survive, but it's unspecified behaviour and may cause hours of debugging trouble.

The cheap solution is series resistors that limit the current to non-fatal levels, but then you may have to lower the speed and may still experience strange behaviour.

IMHO, at the price of a few LVC buffers, it is not worth leaving them out. And with the buffers, you can handle targets running at voltages other than

3.3V.

You definitely need series resistors in the clock line to reduce reflections

- I had to add them on some other debug probe (BusBlaster, old revision) where they were missing, causing errors at ~15cm cable length.

It's the edge rate that matters, and the SWCLK input on the RP2040 will be quite fast. Again, it's not worth saving some cents and have unreliable operation afterwards.

cu Michael

The Pico schematic is instructive. It claims that the RP2040 chip has no diodes to its Vcc, and the pico has no added resistors that might limit current in logic signals. There is one fet in the VSYS adc path that I don't understand.

But the possible current is from its own VSYS through a 200K resistor.

Even before the 3.3 volt switcher starts up, that's under 25 uA. Is that some sort of hazard?

How about any external analog inputs? Do they have to be limited to microamps?

Those are huge. For SWD, I really like the 10-pin Cortex-Debug connectors (1.27mm pitch). Or a minimal 2*3 pin 2.54mm header.

What are these for? I would wire a BSS138 to a free GPIO to automate that. However, when using SWD, you should not really need them.

cu Michael

The half-pitch 20 wire ribbon cable is just 0.5" wide. The box connector on the target board is just a bit wider. That's not bad.

I plan to use all 20 wires, so I can do the CPU debug and check power supplies and clocks and stuff, and snoop code execution times.

I figure that a furious bare-metal loop on the second CPU core might often replace an FPGA. But I want to really time some code on an oscilloscope.

I saw somewhere that the RP2040 has some fast bit counting calls. So maybe an SPI interface and those calls might decode a delta-sigma ADC at some usable rate.

Pushing the buttons can set the 2040 into USB memory-stick mode, to access the flash. That could be handy.

I think I'll do both, allow the buttons and a couple of Pi400 port pins to ground RUN and BOOT. The boot pin is overloaded, actually the flash memory chip select!

Do you know if there is a way for running software to essentialy reset itself and enter the USB flash-stick mode? That could be handy for field code upgrades.

Too much work! We can buy the ribbon cables and connectors from stock.

Ah, OK - I had assumed this was the standard ARM 20-pin 2.54mm connector.

Hm. I would assume you use SWD if you have it available - that should be better for scripted/automatic flashing since it dows not need to wait for a simulated USB stick to appear and be mounted.

That sounds good.

Sorry, no - I have some here, but beyond doing some simple tests, I have not looked into the details. I would guess yes - entering the bootloader for upgrades is possible on almost any microcontroller I have used in the past.

However, for field upgrades, you should ask yourself if the stock bootloader is the right thing to use if the upgrade is done by the end user - I would recommend to use some kind of bootloader that is specific to your product and makes sure that only correct files that are intended for this exact board can be uploaded. On our devices, the firmware file has a header with the device name in it, and the bootloader checks that (plus checksums and a signature) before allowing an upgrade.

If the field upgrade is performed by trained technicians, the stock bootloader may be OK - but keep in mind that flashing the wrong file may damage the hardware (for example by setting pins to output mode that should be inputs), unless you plan ahead for this scenario and design the hardware so that it is robust against this kind of abuse.

cu Michael

It depends. You may need it inside the system for development/test - in that case, the ribbon connector is robust and works fine. Saving the cost of the connector makes sense in higher production volumes.

Sound like the Tag-Connect stuff - but these only come in 6-14 pin versions IIRC. I have not used them myself, but they look useful, and use little PCB space.

cu Michael

True, you'd have to order from digikey and wait a day to get such a connector (tag connect)

we use the Tag Connect TC2030IDC connector intended for PIC programming to program our ESP32 boards one end plugs right into the ESP-prog, no modification is needed.

The price seems to have dropped recently, perhaps a patent has expired, also I'm seeing Chinese clones now.