The quick question: When you say it passes self-check, is that also checking the bug-specific test, by switching to DIO mode, enabling power, and running bug e9, or only the self-test by running ~?
The “~” selftest passes, and bug e9 says
Summary: E9 was not found
Hmm. One of the lines is different from the others:
GPIO.IE = false…
But my other BP6 (the replacement) says the same thing, .
In current sources, the GPIO.IE = false... line is printed unconditionally when running bug e9.
Also, should probably run bug e9 -a to get the fuller test of that errata. The output should be identical between the boards?
If not, can you post the lines that differ?
Aha! the -a option made a difference.
Test IO1:
Disabling Bus Pirate pull-ups
Making IO0 buffer and GPIO input
Making IO0 buffer an output
GPIO pin should be 0: 0
Making IO0 buffer and GPIO input
Enabling Bus Pirate pull-ups
Making IO0 buffer an output
Disabling Bus Pirate pull-ups
GPIO pin should be 0: 1
Warning: GPIO is 1, E9 found
3 Likes
BTW, I’m pushing a fix so that bug e9 -a will indicate which IO is actually being tested (vs. always saying IO0 as noted above).
I didn’t notice that. Good catch! Is that why “bug e9” passed?
I’m not positive … however, IIRC, bug e9 only tests IO0. Since your board had an issue with IO1, it likely wouldn’t have caught it.
I also considered changing the bug e9 logic to use the exact same code as bug e9 -a, but only going through the loop of IO pins once (for IO0). However, the actual testing for bug e9 and bug e9 -a seem to test slightly different things? @ian – can you comment on this?
The good news is that one of the tests could identify the problem, so it might be as simple as applying a heatgun for a short time to the board’s resistor packs. Good luck!
2 Likes
Thank you so much for the logic analyzer views, I’m glad you both were able to work out the cause.
E9 happens when the pin is an input and exposed to a high level, it latches up and won’t come down until a hard ground is applied. This only happens on open drain bus like I2C because of how we use the buffer chips.
The self test doesn’t detect it because it doesn’t have that specific set of pin conditions in that specific order. Perhaps it would be good to test for e9 as part of the self test, though a lot more silently than the bug -e9 test. I will look at adding this.
bug -e9 -a
The -a just loops the test over all pins. Perhaps that should be the default behavior. I was frantically debugging and didn’t give much thought to bug -e9 other than as a convenience for myself 
Looked at the bug command. It does do some additional testing on pin 0 if no pin is selected, but that was really only for my own diagnostic and to fully demo the bug.
- Updated bug test function to be verbose or not
- Added quiet E9 bug detection to 5XL and 6 self test
1 Like
This could only be performed on the RP2350 chips, I suppose. Is there value for the RP2040 chips?
There is no known value to running this test on an RP2040 chip.
The built-in self-test now checks for errata e9, but only for the RP2350 chips. So, I think this matches your expectation?
2 Likes
Yes, only on the right chip.