The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
connect it to the 40-pin header on the back of the Pi400, to use the
400 as the dev/debug platform for some RP2040-based boxes.

Has anyone done this? What Pi400 pins connect to the SWD port?

Googling doesn't help. I have the RP400 Beginners Guide book and it
doesn't mention doing this.

Anybody have links about doing this?

mandag den 15. januar 2024 kl. 22.05.18 UTC+1 skrev john larkin:
> The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
> connect it to the 40-pin header on the back of the Pi400, to use the
> 400 as the dev/debug platform for some RP2040-based boxes.
>
> Has anyone done this? What Pi400 pins connect to the SWD port?
>
> Googling doesn't help. I have the RP400 Beginners Guide book and it
> doesn't mention doing this.
>
> Anybody have links about doing this?

https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/

On Mon, 15 Jan 2024 13:21:14 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

>mandag den 15. januar 2024 kl. 22.05.18 UTC+1 skrev john larkin:
>> The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
>> connect it to the 40-pin header on the back of the Pi400, to use the
>> 400 as the dev/debug platform for some RP2040-based boxes.
>>
>> Has anyone done this? What Pi400 pins connect to the SWD port?
>>
>> Googling doesn't help. I have the RP400 Beginners Guide book and it
>> doesn't mention doing this.
>>
>> Anybody have links about doing this?
>
>https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/

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.

tirsdag den 16. januar 2024 kl. 00.13.38 UTC+1 skrev john larkin:
> On Mon, 15 Jan 2024 13:21:14 -0800 (PST), Lasse Langwadt Christensen
> <lang...@fonz.dk> wrote:
>
> >mandag den 15. januar 2024 kl. 22.05.18 UTC+1 skrev john larkin:
> >> The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
> >> connect it to the 40-pin header on the back of the Pi400, to use the
> >> 400 as the dev/debug platform for some RP2040-based boxes.
> >>
> >> Has anyone done this? What Pi400 pins connect to the SWD port?
> >>
> >> Googling doesn't help. I have the RP400 Beginners Guide book and it
> >> doesn't mention doing this.
> >>
> >> Anybody have links about doing this?
> >
> >https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/
> 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.

afaik the 40 pin header on all Pi's are compatible, except for maybe some of the alternate functions
and on the Pi5 the GPIOs are one the new RP1 chip via pci-e so probably adds a us of latency

On Mon, 15 Jan 2024 16:34:31 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

>tirsdag den 16. januar 2024 kl. 00.13.38 UTC+1 skrev john larkin:
>> On Mon, 15 Jan 2024 13:21:14 -0800 (PST), Lasse Langwadt Christensen
>> <lang...@fonz.dk> wrote:
>>
>> >mandag den 15. januar 2024 kl. 22.05.18 UTC+1 skrev john larkin:
>> >> The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
>> >> connect it to the 40-pin header on the back of the Pi400, to use the
>> >> 400 as the dev/debug platform for some RP2040-based boxes.
>> >>
>> >> Has anyone done this? What Pi400 pins connect to the SWD port?
>> >>
>> >> Googling doesn't help. I have the RP400 Beginners Guide book and it
>> >> doesn't mention doing this.
>> >>
>> >> Anybody have links about doing this?
>> >
>> >https://www.electronicshub.org/programming-raspberry-pi-pico-with-swd/
>> 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.
>
>afaik the 40 pin header on all Pi's are compatible, except for maybe some of the alternate functions
>and on the Pi5 the GPIOs are one the new RP1 chip via pci-e so probably adds a us of latency

I probably don't care about the latency of the port pins from the 40
pin header, from the Pi400. It will be controlling multiplexers and
such. We'll use port pins from the RP2040 chip on the DUT to time
software, but those are real port pins.

On 2024-01-15, john larkin <jl@650pot.com> wrote:
> The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
> connect it to the 40-pin header on the back of the Pi400, to use the
> 400 as the dev/debug platform for some RP2040-based boxes.

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:

https://github.com/mschwingen/hardware/tree/master/JTAG_hat

I think this should also work an a pi400.

cu
Michael
--
Some people have no respect of age unless it is bottled.

On 16 Jan 2024 13:58:13 GMT, Michael Schwingen
<news-1513678000@discworld.dascon.de> wrote:

>On 2024-01-15, john larkin <jl@650pot.com> wrote:
>> The Raspberry Pi pico has its 3-pin SWD debug port. I'd like to
>> connect it to the 40-pin header on the back of the Pi400, to use the
>> 400 as the dev/debug platform for some RP2040-based boxes.
>
>What debug software are you planning to use? OpenOCD?

Whatever the pi400 uses. I'll let a programmer deal with that.

>
>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:
>
>https://github.com/mschwingen/hardware/tree/master/JTAG_hat
>
>I think this should also work an a pi400.

Is there a schematic somewhere?

I plan to make my own board, as described. I'm especially interested
in scoping realtime performance.

>
>cu
>Michael

On 2024-01-16, John Larkin <jl@997PotHill.com> wrote:
>>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:
>>
>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat
>>
>>I think this should also work an a pi400.
>
> Is there a schematic somewhere?

It is linked in the description:

https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc

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
--
Some people have no respect of age unless it is bottled.

On 16 Jan 2024 15:57:32 GMT, Michael Schwingen
<news-1513678000@discworld.dascon.de> wrote:

>On 2024-01-16, John Larkin <jl@997PotHill.com> wrote:
>>>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:
>>>
>>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat
>>>
>>>I think this should also work an a pi400.
>>
>> Is there a schematic somewhere?
>
>It is linked in the description:
>
>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
>
>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

Do you think it's worth buffering the SW Debug pins? I was thinking I
might buffer the clock, since it's unidirectional and maybe
edge/impedance sensitive. I have no idea what the timing from the
Pi400 will be like, but people seem to use breadboards and dangling
wires and get away with it.

If the rate is reasonably low, the SWDIO data line won't matter much.

On 16 Jan 2024 15:57:32 GMT, Michael Schwingen
<news-1513678000@discworld.dascon.de> wrote:

>On 2024-01-16, John Larkin <jl@997PotHill.com> wrote:
>>>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:
>>>
>>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat
>>>
>>>I think this should also work an a pi400.
>>
>> Is there a schematic somewhere?
>
>It is linked in the description:
>
>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
>
>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.

https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1

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.

On 2024-01-16, John Larkin <jl@997PotHill.com> wrote:
>>
>>It is linked in the description:
>>
>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
>>
>>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.
>
> Do you think it's worth buffering the SW Debug pins?

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.

> I was thinking I
> might buffer the clock, since it's unidirectional and maybe
> edge/impedance sensitive.

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.

> I have no idea what the timing from the
> Pi400 will be like, but people seem to use breadboards and dangling
> wires and get away with it.

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
--
Some people have no respect of age unless it is bottled.

On 16 Jan 2024 19:04:14 GMT, Michael Schwingen
<news-1513678000@discworld.dascon.de> wrote:

>On 2024-01-16, John Larkin <jl@997PotHill.com> wrote:
>>>
>>>It is linked in the description:
>>>
>>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
>>>
>>>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.
>>
>> Do you think it's worth buffering the SW Debug pins?
>
>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.
>
>> I was thinking I
>> might buffer the clock, since it's unidirectional and maybe
>> edge/impedance sensitive.
>
>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.
>
>> I have no idea what the timing from the
>> Pi400 will be like, but people seem to use breadboards and dangling
>> wires and get away with it.
>
>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.

tirsdag den 16. januar 2024 kl. 22.16.13 UTC+1 skrev john larkin:
> On 16 Jan 2024 19:04:14 GMT, Michael Schwingen
> <news-15...@discworld.dascon.de> wrote:
>
> >On 2024-01-16, John Larkin <j...@997PotHill.com> wrote:
> >>>
> >>>It is linked in the description:
> >>>
> >>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
> >>>
> >>>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.
> >>
> >> Do you think it's worth buffering the SW Debug pins?
> >
> >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.
> >
> >> I was thinking I
> >> might buffer the clock, since it's unidirectional and maybe
> >> edge/impedance sensitive.
> >
> >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.
> >
> >> I have no idea what the timing from the
> >> Pi400 will be like, but people seem to use breadboards and dangling
> >> wires and get away with it.
> >
> >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.

it is there to stop back feeding the chip thought the ADC pin when the 3.3V is off.
The ADC capable pins have diodes to VCC, it is only the FT pins that doesn't have diodes

On Tue, 16 Jan 2024 13:41:07 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

>tirsdag den 16. januar 2024 kl. 22.16.13 UTC+1 skrev john larkin:
>> On 16 Jan 2024 19:04:14 GMT, Michael Schwingen
>> <news-15...@discworld.dascon.de> wrote:
>>
>> >On 2024-01-16, John Larkin <j...@997PotHill.com> wrote:
>> >>>
>> >>>It is linked in the description:
>> >>>
>> >>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
>> >>>
>> >>>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.
>> >>
>> >> Do you think it's worth buffering the SW Debug pins?
>> >
>> >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.
>> >
>> >> I was thinking I
>> >> might buffer the clock, since it's unidirectional and maybe
>> >> edge/impedance sensitive.
>> >
>> >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.
>> >
>> >> I have no idea what the timing from the
>> >> Pi400 will be like, but people seem to use breadboards and dangling
>> >> wires and get away with it.
>> >
>> >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.
>
>it is there to stop back feeding the chip thought the ADC pin when the 3.3V is off.
>The ADC capable pins have diodes to VCC, it is only the FT pins that doesn't have diodes

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?

tirsdag den 16. januar 2024 kl. 23.45.08 UTC+1 skrev john larkin:
> On Tue, 16 Jan 2024 13:41:07 -0800 (PST), Lasse Langwadt Christensen
> <lang...@fonz.dk> wrote:
>
> >tirsdag den 16. januar 2024 kl. 22.16.13 UTC+1 skrev john larkin:
> >> On 16 Jan 2024 19:04:14 GMT, Michael Schwingen
> >> <news-15...@discworld.dascon.de> wrote:
> >>
> >> >On 2024-01-16, John Larkin <j...@997PotHill.com> wrote:
> >> >>>
> >> >>>It is linked in the description:
> >> >>>
> >> >>>https://github.com/mschwingen/hardware/tree/master/JTAG_hat/pcb_ms_v3/Doc
> >> >>>
> >> >>>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.
> >> >>
> >> >> Do you think it's worth buffering the SW Debug pins?
> >> >
> >> >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.
> >> >
> >> >> I was thinking I
> >> >> might buffer the clock, since it's unidirectional and maybe
> >> >> edge/impedance sensitive.
> >> >
> >> >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.
> >> >
> >> >> I have no idea what the timing from the
> >> >> Pi400 will be like, but people seem to use breadboards and dangling
> >> >> wires and get away with it.
> >> >
> >> >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.
> >
> >it is there to stop back feeding the chip thought the ADC pin when the 3.3V is off.
> >The ADC capable pins have diodes to VCC, it is only the FT pins that doesn't have diodes
> 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?

maybe it is for running on a battery, afaict the quiescent current on the switcher when disabled is only 1uA
but then they have a 100k pull up on enable ...

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

the datasheet doesn't mention any allowable current, only max voltage

On 2024-01-16, john larkin <jl@650pot.com> wrote:
> This is a first pass at the dev board.
>
> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>
> It would be used in development and production test. Every
> RP2040-based board would have the small-pitch 20 pin ribbon cable
> header.

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.

> The pushbuttons look primitive but will probably work.

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
--
Some people have no respect of age unless it is bottled.

On Tuesday, January 16, 2024 at 11:02:40 AM UTC-8, john larkin wrote:

> This is a first pass at the dev board.
>
> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>
> It would be used in development and production test. Every
> RP2040-based board would have the small-pitch 20 pin ribbon cable
> header.

Why bother with pins, and ribbon connector insertion force? Just print
test point pads, a few alignment holes, and make a plug of
spring pins. It's not like you need this access while the unit is
bolted into its box and racked into a larger system.

Do it with two different diameter alignment pins, so it doesn't get
reversed. A captive nut to retain it would be useful, too.

On 17 Jan 2024 17:59:55 GMT, Michael Schwingen
<news-1513678000@discworld.dascon.de> wrote:

>On 2024-01-16, john larkin <jl@650pot.com> wrote:
>> This is a first pass at the dev board.
>>
>> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>>
>> It would be used in development and production test. Every
>> RP2040-based board would have the small-pitch 20 pin ribbon cable
>> header.
>
>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.

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.

https://www.amazon.com/Signals-Systems-Dummies-Mark-Wickert/dp/111847581X

>
>> The pushbuttons look primitive but will probably work.
>
>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.

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.

>
>cu
>Michael

On Wed, 17 Jan 2024 12:16:29 -0800 (PST), whit3rd <whit3rd@gmail.com>
wrote:

>On Tuesday, January 16, 2024 at 11:02:40?AM UTC-8, john larkin wrote:
>
>> This is a first pass at the dev board.
>>
>> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>>
>> It would be used in development and production test. Every
>> RP2040-based board would have the small-pitch 20 pin ribbon cable
>> header.
>
>Why bother with pins, and ribbon connector insertion force? Just print
>test point pads, a few alignment holes, and make a plug of
>spring pins. It's not like you need this access while the unit is
>bolted into its box and racked into a larger system.
>
>Do it with two different diameter alignment pins, so it doesn't get
>reversed. A captive nut to retain it would be useful, too.

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

On 2024-01-18, john larkin <jl@650pot.com> wrote:
>>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.
>
> 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.

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

>>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.
>
> Pushing the buttons can set the 2040 into USB memory-stick mode, to
> access the flash. That could be handy.

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.

> I think I'll do both, allow the buttons and a couple of Pi400 port
> pins to ground RUN and BOOT.

That sounds good.

> 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.

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
--
Some people have no respect of age unless it is bottled.

On 2024-01-17, whit3rd <whit3rd@gmail.com> wrote:
> Why bother with pins, and ribbon connector insertion force? Just print
> test point pads, a few alignment holes, and make a plug of
> spring pins. It's not like you need this access while the unit is
> bolted into its box and racked into a larger system.

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.

> Do it with two different diameter alignment pins, so it doesn't get
> reversed. A captive nut to retain it would be useful, too.

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
--
Some people have no respect of age unless it is bottled.

On 2024-01-18, john larkin <jl@650pot.com> wrote:
> On Wed, 17 Jan 2024 12:16:29 -0800 (PST), whit3rd <whit3rd@gmail.com>
> wrote:
>
>>On Tuesday, January 16, 2024 at 11:02:40?AM UTC-8, john larkin wrote:
>>
>>> This is a first pass at the dev board.
>>>
>>> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>>>
>>> It would be used in development and production test. Every
>>> RP2040-based board would have the small-pitch 20 pin ribbon cable
>>> header.
>>
>>Why bother with pins, and ribbon connector insertion force? Just print
>>test point pads, a few alignment holes, and make a plug of
>>spring pins. It's not like you need this access while the unit is
>>bolted into its box and racked into a larger system.
>>
>>Do it with two different diameter alignment pins, so it doesn't get
>>reversed. A captive nut to retain it would be useful, too.
>
> Too much work! We can buy the ribbon cables and connectors from
> stock.

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.

--
Jasen.
🇺🇦 Слава Україні

On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts
<usenet@revmaps.no-ip.org> wrote:

>On 2024-01-18, john larkin <jl@650pot.com> wrote:
>> On Wed, 17 Jan 2024 12:16:29 -0800 (PST), whit3rd <whit3rd@gmail.com>
>> wrote:
>>
>>>On Tuesday, January 16, 2024 at 11:02:40?AM UTC-8, john larkin wrote:
>>>
>>>> This is a first pass at the dev board.
>>>>
>>>> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>>>>
>>>> It would be used in development and production test. Every
>>>> RP2040-based board would have the small-pitch 20 pin ribbon cable
>>>> header.
>>>
>>>Why bother with pins, and ribbon connector insertion force? Just print
>>>test point pads, a few alignment holes, and make a plug of
>>>spring pins. It's not like you need this access while the unit is
>>>bolted into its box and racked into a larger system.
>>>
>>>Do it with two different diameter alignment pins, so it doesn't get
>>>reversed. A captive nut to retain it would be useful, too.
>>
>> Too much work! We can buy the ribbon cables and connectors from
>> stock.
>
>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.

A 20 pin half-pitch ribbon cable would take, if anything, less board
area, and be less wobbly. And has 20 connections! I could use a 16 pin
ribbon connector, but I have plans for all 20. I want to do more than
just JTAG a CPU.

On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts
<usenet@revmaps.no-ip.org> wrote:

>On 2024-01-18, john larkin <jl@650pot.com> wrote:
>> On Wed, 17 Jan 2024 12:16:29 -0800 (PST), whit3rd <whit3rd@gmail.com>
>> wrote:
>>
>>>On Tuesday, January 16, 2024 at 11:02:40?AM UTC-8, john larkin wrote:
>>>
>>>> This is a first pass at the dev board.
>>>>
>>>> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>>>>
>>>> It would be used in development and production test. Every
>>>> RP2040-based board would have the small-pitch 20 pin ribbon cable
>>>> header.
>>>
>>>Why bother with pins, and ribbon connector insertion force? Just print
>>>test point pads, a few alignment holes, and make a plug of
>>>spring pins. It's not like you need this access while the unit is
>>>bolted into its box and racked into a larger system.
>>>
>>>Do it with two different diameter alignment pins, so it doesn't get
>>>reversed. A captive nut to retain it would be useful, too.
>>
>> Too much work! We can buy the ribbon cables and connectors from
>> stock.
>
>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.

Why do many of the target PCBs have four additional giant holes?

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTlRvjZHFFNSi9PpkrUiXktuw0dU9DN3lM_ww&usqp=CAU

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTNgPz2NFWTfZgl-GSKQ6u6jeSGHt--yJQqjQ&usqp=CAU

On 2024-03-09, John Larkin <jl@997PotHill.com> wrote:
> On Sat, 9 Mar 2024 01:26:48 -0000 (UTC), Jasen Betts
><usenet@revmaps.no-ip.org> wrote:
>
>>On 2024-01-18, john larkin <jl@650pot.com> wrote:
>>> On Wed, 17 Jan 2024 12:16:29 -0800 (PST), whit3rd <whit3rd@gmail.com>
>>> wrote:
>>>
>>>>On Tuesday, January 16, 2024 at 11:02:40?AM UTC-8, john larkin wrote:
>>>>
>>>>> This is a first pass at the dev board.
>>>>>
>>>>> https://www.dropbox.com/scl/fi/709v4pqjhe91jnwqh4wvg/Z566_Sch_2.jpg?rlkey=fjq3a9re53cv5l0zn9ya00akk&raw=1
>>>>>
>>>>> It would be used in development and production test. Every
>>>>> RP2040-based board would have the small-pitch 20 pin ribbon cable
>>>>> header.
>>>>
>>>>Why bother with pins, and ribbon connector insertion force? Just print
>>>>test point pads, a few alignment holes, and make a plug of
>>>>spring pins. It's not like you need this access while the unit is
>>>>bolted into its box and racked into a larger system.
>>>>
>>>>Do it with two different diameter alignment pins, so it doesn't get
>>>>reversed. A captive nut to retain it would be useful, too.
>>>
>>> Too much work! We can buy the ribbon cables and connectors from
>>> stock.
>>
>>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.
>
> Why do many of the target PCBs have four additional giant holes?

For the retaining hooks, AKA "legs", these are optional.

--
Jasen.
🇺🇦 Слава Україні