Oh noes... I broke my Picos

[marcdraco1-gif]

I've found a probable fix for my latest "whoopsie" - but perhaps someone else has experienced this?

To be clear, the following discussion describes some electronics which are all running at 3v3 (there are 5V parts in there but they are all behind the 3v3 regulator).

I had the Pico configured to receive I2S from an external board which doesn't use any current limit but now (after another day of failures) I've just read that the input current on Pico PIOs is limited. Easy fix, naturally - just a small resistor and better I find this now before I finalise the board! :)

I wonder if any one else has run into this. I'm familiar with not trying to source too much current from a pin but never experienced it pulling too much current. I was assuming I was driving the MOSFET's gate which is essentially a small capacitor, but you know what "assume" did. Looks like I'd better get stuck back into the RP2040 datasheet before I jigger another one.

Something new for the book. Better I make mistakes now than have someone else chase me with a big stick later.

I don't have a differential scope probe to measure the current during high-speed transitions so I'll try put some series resistors in there and see what happens.

This is probably in the datasheet somewhere - maybe someone else knows if there's schematic for the inputs? Man do I feel like a doofus - again.

I guess this the cost of a configurable device where the same "pin" can be an output or an input.

[earlephilhower]

I don't think I've read of such a limit on an input on the RP2040. Input current is going to be on the order of uA by design, if that, in normal operation. The datasheet would be the reference there, section 5.5.3.4.

That said, there are ESD diodes which should never engage in normal operating mode that will have current limits (i.e. if you go over Vcc or below GND on an input) before they die.

[marcdraco1-gif]

Exactly that Earl, yes. My own custom board runs at 3,3v (it can go lower) but the problem is that I've been powering the custom side of things from its own USB and then applying power to the Pico. Even 3,3 is enough to push too much current through them it seems

This is almost certain to have jiggered the ESD diodes because I was assuming (wrongly) that I was driving a MOSFET gate and the effect would be harmlessly charging the gate capacitance.

I'm a little shocked this isn't more widely promoted as a feature (not a bug) in the hardware since it's a bit of a show stopper. I don't know how much current the controller can kick out on its own digital ports, but it's clearly more than enough to do damage.

Had I mounted a Pico (just the MCU) on the same board, it would have time to power up before the other chips went "live" (about 500 mS) but to keep costs reasonable I figured it would be smart to use a Pico module. This means adding some protection resistors as I'm creating what you might call a TAH (a HAT in reverse). The Pico mounts on top of the I2S module for ease of programming via Circuit Python or C++ via USB vs. the SWD port.

I did see a reference (which of course, I can't find just now) that suggested 1 K current limit although, as you said, the actual impedance is so astronomical, a much larger value will still work. I'll try this on some other ports to see if it comes to life - after I've had time to check they are actually dead.

A schematic of the input circuit would have helped here so I knew what I was dealing with rather than just assume it was like all the stuff I fiddled with back in the 1980s (yes, I'm really crawling out of that electronic primordial ooze).

The really weird thing is that both busted Picos (so far as I can tell with minimal testing) both report the same value for the Left and Right inputs - all the time. L stuck at 15 and R was stuck at 384 on both boards. I pulled a third (brand new one) out of box of spares and sure enough - 0:0 for L&R with no signal applied.

The same fault on two Picos can either be a code error, and that's not possible since this is mature code or some external factor and that only leaves an over-current or static discharge.

I'll try this later today and get back to you - it might be an "edge case" for the hardware but it's better that we know about this in advance. If I'd managed to make the full board and HAT - without discovering this I'd be crying into my beer. (Well, my empty glass, because I've ploughed my beer fund into this project sufficient to keep the town drunk for a month.)

And (shocker) swapped to some alternative PIO pins on a "busted" board and what do you know? 0:0 (no signal in, so no data out). I know you know this Earl, but I'm cognisant of other people picking these discussions up, not to mention AI (artificial ignorance) which tends to create as many, if not more, problems than it actually solves. The short-sighted greed of companies like OpenAI ("open"... oh my life), Microsoft and Google is rotting the Internet as we knew it faster than I ever imagined possible.

It's rather strange (and I'm not about to sacrifice even more PIOs to find out at this stage) that the breakage would reflect the same value in both PIOs. You're more familiar with the guts of this thing than I'll ever be so perhaps you have a better guess?

So yeah, looks like not powering the Pico ahead of the controller is enough to make it go "poof".

Well darn - put resistors in the circuit (larger than I figured I'd need) and still nuffin'. I wonder if there's something going on inside the PC? The grounds should be common via the USB shields, etc. but maybe I've missed something else.

For anyone following along: the board has a fixed I2S slave and fixed master, both at 3,3 volts (I'm just tapping off) another slave - and it works without so much as a blip. The 3v3 power is regulated by an LDO to the other devices and it's stable.

Time isn't on my side (never is) so I'm gonna see if I can replicate this issue with an old ESP32 or and I think I even have a black pill lying in a drawer somewhere. I've got an STM32 nucleo but I really don't want to blow that up! I can sacrifice a Pico or two if it means getting to the bottom of this.

[earlephilhower]

I did see a reference (which of course, I can't find just now) that suggested 1 K current limit although, as you said, the actual impedance is so astronomical, a much larger value will still work. I'll try this on some other ports to see if it comes to life - after I've had time to check they are actually dead.

As electricians say, it's the current and not the voltage that kills you. The ESD diodes I'm familiar with are great for high breakdown voltages but little actual current. Assuming the 3.3V source impedence is ~0 for sake of argument, and the Vdiode = 0.5 (probably wrong, but I'm sure it's specified in the datasheet or addendum), then you have a (3.3 - 0.5) / 1K = 2.8mA in that situation. I can't seem to find any specs in the datasheet on that (IIRC other devices have something like 5-10mA limits), but if you post this question on the RPI Pico Other Boards forum I'm sure an engineer from RPi wll have some good input. 😆

But maybe that's a red herring This doesn't make any sense to me from a physical damage perspective:

L stuck at 15 and R was stuck at 384 on both boards.

Are you saying the I2S input PIO is returning constant values, but different per L/R channel? If things were busted I would expect either constant 1 or 0 or random noise. Returning 15 is actually very hard to do, if the input pins are damaged. Not only is it a series of 1s and 0s on the I2SIN pin, but that sequence needs to be perfectly synchronized to another output pin driven by the PIO to make that happen. The PIO FIFO where this data is stored before DMA to RAM is very far from the input pins, and it's driven off of the ISR (input shift register, not interrupt) register.

I'd check the actual I2S bus (they're slow enough a $10 logic analyzer and pulseview can verify them in most cases) at the pins of the RP2040 chip. Maybe there's something fishy with the actual inputs.

You could also do basic sanity tests using digitalWrite and logic probing pins, or digitalRead while driving from the outside...

[Andy2No]

@marcdraco1-gif I'm not sure if I've fully understood what the circuit is and what you've tried so far, but putting resistors on data lines means the rise and fall times of signals is longer, due to input capacitance. In the case of I2S (or SPI, I2C etc) that may mean you have to lower the clock speed or the data transfer / messages will get mangled. If the resistor is too big, you might not be able to get the speed you wanted.

If you're aiming for level conversion, you could consider a resistive divider rather than relying on the protection diodes in the inputs. Since the input current is very low, you can ignore that and just choose resistors to give the right voltage when the divider is unloaded, e.g. if you wanted to drive a signal that shouldn't exceed 3V from a 5V, source, you could use 2k and 3k in series (2k from source, 3k to ground) giving 3/5 = 3 / (3 + 2) of the source voltage at the junction of the two resistors. The actual values you'd want would allow for the output high level of the source and the minimum input high level of the input pin, but that might be close enough.

[marcdraco1-gif]

The whole thing is running at 3,3 Andy. I'm familiar with input capacitance. Using a resistive divider for level translation is ... unreliable shall we say. A proper level translator would be required but I'm not interfacing 5V logic with 3,3 so fortunately we can file that problem as moot. 5 v logic might be running at 5,5 and still be within tolerance but the divider won't know that and there goes the neighbourhood. Level translators have a regulated output (3v3 in this case) and the inputs are 5v5 tolerant or better.

For anyone lurking, let's look at what Earle and I are discussing (I do make a lot of self-deprecating jokes but that's just the way I roll).

Current limiting resistors slow the level translation from high to low and vice versa. The gate capacitor takes longer to charge and when we're talking in terms of nano seconds (while not specified the inputs are supposed to be less than 400 pF) plus a few pico Farads of track capacitance, so the actual rise time can be estimated from that. The base rise time is limited by the current the driving circuit and the switch point is determined by the design of the MOSFET with a high registering at around 2,4 volts (for a 3,3 supply). Without a clear input capacitance measurement which is (at best, tricky) we can only take an educated guess.

Imagine we've got an internal impedance (equivalent to the maximum current the output is capable of driving) of say 50 ohms, the 2,4 v transition from low to high occurs in about 25 nano seconds which isn't hanging around but really quite pedestrian and quite capable of running a device above 12 MHz. (When I run the numbers, it never ceases to amaze me just how fast computers and MOS tech has come since I was a nipper. Bit clock on my board measures at 3,3 MHz with the controller running at 12.288 as you might guess for I2S at a 48K sample rate. I don't need the controller clock. So we can figure out the likely max usable resistance vs. the limit required. I'm not sure based on these "beer mat" calculations that a we could provide sufficient resistance to limit the current for the protection diodes (anyone know what their rated max current is?)

It always makes me chuckle to think that it's not the current that destroys the device, it's the time the current flows for. At T=0 the current is theoretically infinite but that rapidly drops to something more realistic (and we're talking less than pico seconds) because this all happens at almost light speed. The rapid heating cause by too much current for too long (again measured in pico seconds for some devices) destroys the junction. This is how a a little bit of static electricity from a fingertip can generate enough current for a long enough time to blow a hole in the semiconductor material given that it's nano meters in thickness.

I recall the first time I saw a picture of the damage caused to a MOS gate caused by a static discharge blew my mind. You can literally see the hole in the layers and what looks like a molten edge. I can't find the exact picture on the net but I think there's one in AoE 2nd edition (and likely the third, I haven't looked).

The human body model uses a 100 pF cap charged to 2 KV (and more up to 8 KV depending on the rating) and discharged via a 1k5 resistor into the gate. So the max current in in the 2 KV case would be 1.3 amperes dropping quite rapidly but the device is coping with an average around 1 amp for around 300 nS. It's remarkable to thing that just a simple static discharge that won't even register on our nerves can deliver more than an amp! (These are all beer mat calculations but they are accurate enough to demonstrate how incredibly tough these devices are so long as we're careful.)

I've still got some unused ports on the Pico but this is very odd. I'm not sure what's going "pop" right now. I just wish I could slow the transitions down sufficient so I can see them in code more easily (using standard input/output code).

Right now though I'm rummaging around for an ESP32 with usable I2S (some have one, some two) and some demo code that I can see if that works as expected. I'll have to try and power my board from the Pico because it still appeared to blow an input even when the pico was powered up first. This is most irritating and it's not a software issue.

[marcdraco1-gif]

@earlephilhower - yeah I agree - the whole thing is "weird" at best. I can't make any logical sense from this consistency in producing such specific values (384 left, 15 or 0 right).

I agree - it makes ZERO sense that these values would stick there. I've got to go back to my code changes and re-check. I feel like I'm going all "FTL Neutrinos" at this stage. My electronics skills are far superior to my coding ability. Not that's necessarily saying too much. LOL.

I the 50-odd years I've been fooling around with electronics, I've only ever busted a couple of ICs - and in one of those cases it was usually accidentally reversing power by not checking the JST connector factory fitted by some nice Chinese lady the wrong way around. (Can't get the staff... and I know enough to check this stuff beforehand.)

Where I'm a bit stuck (and you're right that someone from Raspberry PI can help here) is what goes on internally when we direct an input to do "A. N. Thing". A basic input is a MOS gate that the system reads for a logic 1 or 0 - but that (presumably) is routed to the PIO state machines by more bus logic. This is where I'm somewhat in the dark - I come from an era where a pin was an input, output or open collector/drain and when 74LS was state of the art. (I grew up with germanium transistors like the OC71.) Having multi-function pins still makes my poor old brain itch but it also makes it much harder to infer what's going "boom". :)

This has to be a case of me not seeing the wood for the trees hence why I'm changing the Pico out as a variable. I'll report back when I have something more concrete. Damnable nuisance as the I2S needs to do some very basic processing to keep the total cost of the board down. It has a two channel input but a mono output (by design). Both channels are required for the full build.

[dhalbert]

If all the levels are 3.3V, then you're not going blow the inputs by applying a 3.3V signal, current-limited or not. A 3.3v input pin attached to a 1mA-capable 3.3V output or a 50 amp 3.3V power supply is not going to be blown out in either case (given no noise or higher-voltage transients) . I think this is software or wiring.

[earlephilhower]

I think his concern was that he was applying 3.3V signals to an unpowered chip. So VCC=GND in this case, and so he'd be feeding in voltages above the chip's unpowered VCC.

That said, I think it's SW or wiring as well. 👍

[marcdraco1-gif]

That was my take too - but it's not obviously wiring - as you can see from the results below, it works just fine with an ESP32 (and an OLD one at that) even switching them on an off at random times to see if a wheel falls off. There was a question of supplying 3,3 to the Pico before it was powered up and possibly blowing a protection diode. Something to do with the way the chip initialises itself - honestly, I'm a very, very slow reader, a disability that didn't affect my ability to write for much of my career. Go figure - I guess face-planting some concrete as a teenager really jumbled the biological computer I exist inside. Anyway, that datasheet is loooooong. I'm not esp. careful when blabbing on the net of course, although I do try to keep it as cogent as possible.

Anyway, even that seemed a stretch but since we don't have the internal schematics of the port to understand how the MUXing works, we're all in the dark.

This is unique (to date) to the Pico although I really do need to try this with an STM32 either a black pill or I can break out the Nucleo and see what that makes of it. On my nasty cheap hand-held scope, the data lines are surprisingly clean even with a rat-tail ground strap to the scope probe and slightly less than optimal routing to allow me to break out some test points. All those horror stories about 90 degree bends causing reflections above 1 MHz (at least with very fast edges) ... lies, lies I tell you. Never hurts to be careful though. Learning how to route high-speed boards works just as well at lower speeds, just makes the PCB look more like a used dartboard.

I'll re-test the pico at some point - but it's weird that the expected result (0,0 before the streams fire up) worked on an unused board and but after wiring it, it just got stuck. Now I'm not the world's greatest programmer, that much should be obvious and the essence of experimentation is repetition. I'm about get some more boards off with better breakouts for the signals (just experimental ones) so can insert a Pico rather than have it beholden to the existing bus controller, but have it operate one port as controller and the other as target. Although an ADAU1701 would do the job (and more easily to some degree) the decent eval boards are quite expensive and they're a bind to program as people need a separate USB to I2C do-hickey and the Chinese copies are horrid.

Plus this is a cost sensitive project for everyday makers, not people pushing the envelope beyond what the human ear can detect.

Software is really Earle's department. His code has been around for a while so it should be pretty well tested. This is going to be a gnarly one.

I wonder if the key lies in the fact that I'm working with the Pico in I2S target (slave) mode whereas most use-cases (like mics) will have the Pico as a bus controller (master). When I had two of them fighting on the same bus the predictable hilarity ensued - and I have to wonder if I blew a gasket inside one of the of the devices that's "following" me around the various port pins. I'm just a little leery of trying anything else until I've at least tried it on one other device - an STM32 or even another ARM M0+ like the Xiao which I think has hardware I2S. I'd have to check. These boards aren't a lot of use as I do need an I2S in AND out so that the MCU can do some of the modest-to-heavy lifting that I'd normally do in the analogue domain.

[marcdraco1-gif]

OK, so I hooked up an ESP32 DoIt Devkit 1 WROOM-32 module (one of any number of similar boards I expect). I had to use AI to fallback and generate some workable code for Arduino (as I've said, I'm not a great programmer) and AI got me in a few minutes a workable sample and here's where it gets interesting. ESP32 would normally be my first choice but the Pico has supplanted that because it's consistent and

While I have no way (currently) to feed the I2S out into another device - way past time I grabbed a cheap DAC as the one I have is requires I2C programming because it's based around the SGTL5000 as Paul S. used on the Teensy. If it's good enough for Paul, it's good enough for me. But to save the faff, I'll grab a cheap board from Amazon so I can listen in. The final design does a few bits of simple math and just feeds it out again. The current test board only has parallel taps for the clocks and data - I really should have used loops so I could get the I2S out and back in again without having break tracks but I added the TPs as a stopgap, it was never really meant for testing as we're discussing.

But here's the weirdness. Darn thing worked the very first time I tried it. The code is far too crude to see some data and what is there is largely just random noise from the ADC's lowest few bits.

Here's the ESP32 setup code (likely nicked from someone else, doncha just love the way AI steals everything?).

#include "driver/i2s_std.h"
#include "driver/i2s_common.h"

const gpio_num_t I2S_SCK = GPIO_NUM_25;   // BCLK
const gpio_num_t I2S_WS  = GPIO_NUM_26;   // WS
const gpio_num_t I2S_DIN = GPIO_NUM_5;    // DIN

i2s_chan_handle_t rx_handle = NULL;

void setup() {
  Serial.begin(115200);
  delay(1000);
  
  // Step 1: Create I2S channel configuration
  i2s_chan_config_t chan_cfg = I2S_CHANNEL_DEFAULT_CONFIG(I2S_NUM_0, I2S_ROLE_SLAVE);
  chan_cfg.dma_frame_num = 240;
  
  // Step 2: Allocate I2S channel (RX only for slave mode)
  i2s_new_channel(&chan_cfg, NULL, &rx_handle);
  
  // Step 3: Configure standard mode clock
  i2s_std_clk_config_t clk_cfg = I2S_STD_CLK_DEFAULT_CONFIG(48000);
  
  // Step 4: Configure standard mode slot
  i2s_std_slot_config_t slot_cfg = I2S_STD_PHILIPS_SLOT_DEFAULT_CONFIG(
      I2S_DATA_BIT_WIDTH_32BIT,
      I2S_SLOT_MODE_STEREO
  );
  
  // Step 5: Configure GPIO pins
  i2s_std_gpio_config_t gpio_cfg = {
      .mclk = GPIO_NUM_NC,  // No MCLK for slave
      .bclk = I2S_SCK,
      .ws   = I2S_WS,
      .dout = GPIO_NUM_NC,
      .din  = I2S_DIN,
  };
  
  // Step 6: Combine all configurations
  i2s_std_config_t std_cfg = {
      .clk_cfg  = clk_cfg,
      .slot_cfg = slot_cfg,
      .gpio_cfg = gpio_cfg,
  };
  
  // Step 7: Initialize I2S standard mode
  i2s_channel_init_std_mode(rx_handle, &std_cfg);
  
  // Step 8: Enable the channel
  i2s_channel_enable(rx_handle);
  
  Serial.println("I2S Slave Mode Initialized");
}

And here's a buffer dump (there's no input audio) just some loose noise. Also, the controller is expecting 16 bits and

Hex Dump (32-bit words):

Hex Dump (32-bit words):

0000: 49D70000 64D20000 4B430000 33130000 48940000 22530000 46680000 14050000 
0020: 19000000 38660000 30850000 07540000 52470000 F8B5FFFF 172C0000 3CF10000 
0040: 35AD0000 22600000 ED41FFFF FAD2FFFF 19820000 04BE0000 0D440000 00BF0000 
0060: 3ED30000 10120000 F61DFFFF 192E0000 10110000 0DCD0000 28EC0000 F117FFFF 
0080: D6FCFFFF 1B560000 120E0000 0FA70000 F40BFFFF 01370000 00330000 FD05FFFF 
00A0: F31FFFFF 23920000 DA16FFFF 035A0000 E9D6FFFF 14040000 23340000 217D0000 
00C0: 14C90000 F0DFFFFF 1EE50000 F8ACFFFF EFECFFFF 020C0000 181E0000 34520000 
00E0: 00580000 2C450000 07F80000 45FD0000 1BC70000 11170000 22370000 D95BFFFF 
0100: E0FEFFFF FBCBFFFF F74AFFFF F004FFFF E6DBFFFF 06FA0000 1B5C0000 06C80000 
0120: 14C20000 32DF0000 4F170000 35E30000 2BF30000 FC62FFFF 3E9C0000 32DC0000 
0140: 0C7B0000 15DE0000 14B50000 FED3FFFF 2AD90000 01790000 FE267FFF FFFF0838 
0160: DFFFFC57 FFFFFFC6 C000FB6B BFFF0046 6000F9AE 0000FE92 E00000A6 3FFF02B0 
0180: 6000FF51 1FFF055B E00000CE 80000538 9FFFFB80 DFFF0224 0000FFBB 9FFF0309 
01A0: BFFF0016 3FFFFEFA BFFFFCBA 7FFFFC0A 0000CB32 17DC0000 D5B3FFFF CC10FFFF 
01C0: CE5BFFFF BE25FFFF EDBAFFFF DFFFFDB0 FFFE55AF FFFEF54F FFFDDE9F 00027480 
01E0: FFFD506F 00012AB0 FFFC2B9F FFFBEC4F FFFCB5EF FFFD460F FFFF04BF FFFF7D6F 

While I speak hex, I don't speak I2S hex, I used to speak octal too but hex is so much clearer, n'est pas? :)

Anyway, no point having a DAC and making silly noises yourself, right? :)

Apologies for the levity, I find if I take myself too seriously I fall into a pretty dark place, pretty fast and pretty hard.

TL;DR

But the whole point of this exercise was to see if my board was faulty or something is up with the Pico. Given the code is highly mature, that leaves me wondering what's going on with the hardware. This particular ESP32 is one of the first that Espressif did following the ... previous one the number of which escapes me.

Earl, you've got way more experience in this area than I have so perhaps you can offer some more suggestions? Maybe I didn't jigger the Pico? I'm not holding out much hope the way it powers up, etc. but this is lashed up to the ESP32 identical to Pico, the only variable I changed was using an ESP32 with some appropriate demo code. In fact, my soldering is quite spotty since I was really just hooking it up for a single, simple test, fully expecting it to fail.

The recorded audio (recorded over USB at 16-bit) is very good indeed and a testament to the quality of contemporary hardware - even stuff that costs less than a buck a chip!

[earlephilhower]

Note that for some reason you're using 32b, 48khz I2S in the ESP32 example. On the Pico you said you were running 16b (no idea what frequency).

If you're running an I2S mike, then some of them are picky about both the frequencies they support and the bit depth they require. We can run 32b 48khz on the Pico, but it's kind of wasteful WRT memory and doubles the I2S BCLK unnecessarily if you only need 16b.

Again, I suggest first checking the I2S pins you've got laid out on the Pico's PCB with a logic analyzer to verify things are actually live.

Once that's done you can run the I2SInput example, adjusting the pins/etc. as needed. You can use the built-in Arduino Serial Plotter to see the output in a poor-man's o-scope.

[marcdraco1-gif]

Hi Earle (sincerely, apologies if I keep spelling your name incorrectly).

Just to clarify the board this is designed to be a part of is something I've designed from the ground up. I'm doing the full "final" layout this week so at least I can Open Source the blasted thing since I'm trying to break some new ground for us Makers using commodity silicon and some tricky code.

I'm using an existing chip to translate the I2S to a USB audio signal but it caps out at 48KHz, 16 bit. The other part of my board goes a good deal higher but is limited by the USB controller side of things. So the 32bps side is required by the other chips.

In essence what I'm trying to do with one Pico (I'd originally planned to have 2x RP2040 MCUs and cut out all the faffing around with Picos, but let's put a pin in that one for a moment, except to say that as a cost-vs-performance this seems more effective than using more powerful MCUs that the one Paul Stoffregen used on the Teensy 4. I wanted to use one of the Picos to do the "translation" from TDM/I2S and send that over USB while another handles video. (Back in the mists of time I'd tinkered with the STM32F7 but I got beaten by my lack of programming skills and almost total void when it comes to the USB).

While USB isn't absolutely a deal-breaker, it's a very useful addition, for recording the results.

Although this can do audio one of the jobs it's intended for is something called a Scope Octopus. An incredibly useful piece of tech that pre-dates even my ancient self but something we don't see much these days. They're awkward to set up for modern tech without a lot of fooling around because we use such low voltages now.

As of this writing, I've not actually seen one that's both fast and portable. The normal operation is to fit up a mains transformer (whelp!) to derive a 50/60Hz sine wave and put that through a component under test. The octopus (so called because there are wires everywhere) plots the current vs. voltage in two parts of a circuit.

On the face of it this sounds about as helpful as a modern politician, but it's actually incredibly handy for things like shorts, opens in boards where a meter might struggle. A short gives a horizontal line, an open vertical, whereas a capacitor and a inductor both produce ellipses. Diodes and semiconductor junctions produce the tell-tale graph graph of a curve tracer and so on. Resistances produce slanted lines.

With a 50/60Hz input we're a bit limited to the size of an inductor/capacitor as the effect relies on the reactance of the part so a modern device can provide a sine wave of adjustable frequency AND voltage. Hence we can test for shorts in very delicate junctions by not sticking too much voltage across the pins. Similarly, a we can show where a Zener of unknown value enters avalanche and more beside. As a curve tracer (the second channel comes into play here) we can test even more devices like JFETs, biploars and more. JFETs are a PITA when it comes to their manufacturing spread so this can find the Vp (pinch off) from a bunch of "identical" parts to help with matching.

Back to the Picos/RP2040s:

So what's happening is this: there's a controller (master) chip proving a set of I2S 48K for 16 bit audio (I don't have any control over this as the chip is designed for that purpose) and I'm using those signals to I/F with my own stuff which spits out 32bit at 48K. This level of accuracy should rival the best curve tracers and allow even smaller signals to test things like germanium diodes and more exotic semiconductors without dropping more than a few 100 mV across them with current in the micro-amps. All adjustable naturally (either by analogue parts or a DAC) with a sine wave generated by DDS. No fooling around with mains voltages, so no danger of anyone getting a shocking surprise. (Although it should go without saying you can't poke this thing into something with live signals, it's not much of an oscilloscope as it caps out at something less than 25K.

So the 32bit side is the input I2S and that is processed on the Pico (or some other MCU, but the Pico is preferable as I've said) and gets spit back out to the USB translator as a 16 bit, 48K signal after some limited of processing. A second Pico can sit on the same bus and do its own thing. I would imagine if one can do the 32-to-16 bit translations, the second Pico can handle the graphics on a 320x240 LCD. Refresh rate isn't that critical and it only has to plot a few hundred points per pass. Even VGA is possible - though I expect that's about it. I/Fing to HDMI is something best left to bigger chips like the ARM ones on RPis.

This is where a DSP like an ADAU1701 enters the fray. I designed a simpler version of the 1701 eval board to more suit this project but when everything is totted up, it's far and away easier to program a consumer MCU than it is fiddling around with a DSP. I can "program" (that's to say upload code) to a Pico over SWD and not have to faff around with I2C and a specialised application for DSPs. Cost is an option too - I have the tools like the USBi but most makers won't, so again we're back to MCUs that can be programmed easily either over USB or SWD or even UART.

I guess we could think of the Pico/RP2040 as being something of a "piggy in the middle" - talking to both chips at the same time but since they don't need to be in sync (at least not down to the sample) one I2S monitors the 32bit I2S from one side and (after some processing) shoves it back to the 16-bit controller chip. This sounds a little batty and the current board only had a patch out, not a patch through so the experimental Pico/ESP32 just hangs on the Bit, Data and Word clocks (the other chips can access a controller at 12,288 MHz but that's not really that useful for the Pico. (Neat that you got it to generate that so accurately though!)

I've tried all of this (because someone is bound to ask) with the on-chip ADCs but they are either too slow or insufficiently accurate to record the measurements I need, especially when we get into the weeds of devices like Schottkys with their 0.2 V Vf - a voltage that changes with current - (and that's something else that could be SW controlled).

I hope that explains the reasoning for 32/16 bit translation, it's not an option although 32-bit over USB would be "nice" that's beyond my skills: much like a Saturn 5 rocket is superior to a child's kite, or Pico to an Abacus. You get the idea, I'm sure.

I noted your point about I2S mics being a bit "picky" about starting up, but I can assure you this thing comes up first time, every time as I've demonstrated using an ESP32. That worked out of the gate without any issues and while the ESP32 is a common and popular maker module, it has issues such as lack of standard pinouts (everyone and their dogs are making them) and the modules are quite chunky. Again though, this is also constrained about what I can source from JLCPCB, PCBWay etc. I have the hot air guns and decades of experience soldering small parts (even 0402 SMDs under a microscope - and by that I mean a biological dissection scope, not a digital one!) but I want this to be accessible to anyone. Also I got a bit sick of burning the turret on my scope, poor thing looks like it's been in a war.

That's what's niggling me. When I get the new master layouts out the door (today hopefully) I can have a little more time to spend ripping what's left of my hair out with the Picos.

[earlephilhower]

Thanks for the explanation. Doing 32b transfers isn't an issue, we handle 16, 24, or 32 just fine. It's just bits on the wire to us...

Just to make sure there was no bitrot in the I2S code, I hooked up the AIY MEMS stereo mikes on a Google AIY board using the I2SInput example. LGTM.

So at this point, the (pretty old and stable) library code seems fine and there's not much anyone outside of your workbench can do.

I suggest the same things as before: break down the subsystems and see where it's failing. If you have test points on the I2S input pins on the RP2040 board, sample those and verify you're getting live data and not those 2 constants. If not, then it's obviously something upstream (wiring, timing, etc.). If the testpoint data looks good, then run a simple test like the I2SInput script using your pinout and see what happens.

While doing the above you can do sanity checks on the BCLK, too. There's no APLL on the Pico, so the BCLK will be derived from SYSCLK with a potentially fractional divider leading to small clock jitter. The I2S API here has a call to adjust SYSCLK (i.e. the whole Pico) to give an integer divisor and have no jitter. I2S::setSysClk().

[marcdraco1-gif]

There are 11 types of people in the world, those who understand programmer humour, those who don't and those who think that a "Problem behind the keyboard" isn't them. ;)

Will-do Earl. It'll be a couple of days as I need to get the new boards routed-and-tooted (?) tomorrow. Was planning on doing it today but there's no rest for the wicked and my ex. wife (bless) needed me to read some jumped up little jobsworth tyrant the legal riot act and it's blown my entire day and a good part of the evening. She fed me as thank you and given the way I cook (slightly less well than I program) that's a decent exchange of skills. Man, she's a good cook! :)