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.
using a pi 400 to debug a pico
Started by ●January 15, 2024
Reply by ●January 16, 20242024-01-16
Reply by ●January 16, 20242024-01-16
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 >MichaelThe 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.
Reply by ●January 16, 20242024-01-16
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
Reply by ●January 16, 20242024-01-16
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 diodesBut 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?
Reply by ●January 16, 20242024-01-16
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
Reply by ●January 17, 20242024-01-17
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.
Reply by ●January 17, 20242024-01-17
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.
Reply by ●January 17, 20242024-01-17
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
Reply by ●January 17, 20242024-01-17
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.
Reply by ●January 18, 20242024-01-18
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.
