PIO-based modes not working on BP6/5XL

[ian]

While building out the logic analyzer I noticed that none of the PIO-based modes work on the RP2350-based hardware. This effects: 1-Wire, I2C, HDUART, 2WIRE, LED, INFRARED.

First things first, we know the PIO works. The LEDs work and the logic analyzer works.

The rp2350 has additional pins, so there are some new funky limitations about what pins the PIO can address. There is a function to make that easier:

pio_claim_free_sm_and_add_program_for_gpio_range

The firmware has been updated to use this function instead of hand-assigned PIO/SMs.

I found that silicon bug (E9) where pull-downs act as a bus hold. I disabled pull-downs in all our PIO programs.

I’ll clean up the firmware and push, but I’m pretty stumped at the moment.

[ian]

Ok, did a huge cleanup of pio stuff. Pushed to sdk2_pio_cleanup for testing.

I accidentally pushed to main too, sorry about that.

[ian]

I’m going to go ahead and pin this topic. I’m super sorry Bus Pirate 6 is arriving with this issue, I know it has to be a bummer. It’s a bummer for us as well. My sole focus is getting this worked out.

[ian]

I am not enjoying the current state of everything.

Applied this fix to banish the PICO extension.

            "overrideLaunchCommands": [
                "monitor reset init",
                "load \"C:/buspirate5-firmware/build/bus_pirate6.elf\""
            ],

Then had to manually enter the debug target file name because (I assume) the PICO extension doesn’t escape the \ symbol in windows paths.

I did manage to trace the bug in the logic analyzer that is presently causing freezing. The PIO isn’t yet assigned when we link it to the DMA.

[justacec]

Thanks for all of your efforts. I am looking forward to it being figured out.

[ian]

    #define LA_BASE_PIN 0 //LA_BPIO0 //0
    if (trigger_ok) {
        if (trigger_direction & 1u << trigger_pin) // high level trigger program
        {

One cool thing we can do is assign the logic analyzer to the internal signals. GPIO0…7 control the IO buffer direction, 8-15 control the buffer output.

In I2C (and all open drain bus types) we manipulate the buffer direction.

• Set the logic analyzer base pin to GPIO0
• Set a trigger for high level on SCL pin (buffer becomes an output)
• Nada, nothing

You can see where a 2 makes IO2 an output, triggering the logic analyzer. So, it works. Not one single PIO mode program produces any kind of output on GPIO0…7 (1-wire, 2wire, I2C, etc).

Next I’ll look at gpio8…15 and see what they’re doing.

Additional bug: when trying to assign more than 2 statemachines in a PIO, the Bus Pirate crashes. This could be an issue in the logic analyzer (which causes the freezing in modes that use two sm: HDUART, INFRARED). or it could be an issue with pio_claim_free_sm_and_add_program_for_gpio_range because everything worked fine with we were assigning PIOs and SM manually.

Good to see a fix for another bug I noticed: linker using 100% of ram.

[ian]

IO8…15 also no output in eg LED mode.

The hard fault when trying to load a 3rd SM is occurring in the USB stack (???). It does NOT happen if the logic analyzer is already configured for capture (armed) before entering a 2 sm mode:

• Bus Pirate in HiZ mode
• Set trigger and start capture in sigrok
• m 10 to enter infrared mode. It works.
• Cancel and restart capture, it works.
• Cancel any capture
• m 10 to enter infrared mode again
• Start capture in sigrok (freeze, panic from USB stack)

So, maybe an interrupt isn’t being set correctly?

irq_set_enabled(PIO0_IRQ_0 + (PIO_NUM(pio_config.pio)*2), true);

I had to fiddle with the LA interrupts because there’s no way to get the IRQ number dynamically when using pio_claim_free_sm_and_add_program_for_gpio_range.

Next, I’m going to try a dead simple PWM on the buffer direction pins. Since NOTHING works, I’m still hopeful this is a simple missing configuration step. However, no such changes were needed for the LEDs or logic analyzer. I’m also going to assign the PIO manually again and force the PIO onto io 0…31 in case the SDK is being weird.

[ian]

LED PIO output on the intended pin. Next to try it on pin0 again.

At least one major source of bug is the logic analyzer PIO program is making all the pins inputs using the state machine instead of the normal functions. This seems to override other PIO programs, but not hardware modules like SPI and UART. We may be close to a partial solution.

[ian]

I2C is showing promise.

The logic analyzer samples seem to be backwards, they weren’t before. Hum.

[ian]

Ok, can see the buffer direction pins are moving. The problem is that the data pin is latching up and so we never see a low. This seems to happen during/after the PIO setup.

gpio_disable_pulls(pin_scl);

Simply disabling pulls doesn’t seem to fix it. I’ll test some of the solutions in the datasheet.

It seems like that chip bug is worse than listed in the datasheet. Someone mentioned pimorani had some more documented causes, I probably need to look at that now. The latch up is in fact what is causing the present issue.

[ian]

I added a new command to the Bus Pirate firmware, “bug” that replicates the E9 errata. Next I’ll probe that a bit with the suggested solutions from the datasheet.

[grymoire]

We’re cheering you on, Ian.

[pfeerick]

Now just waiting for the “E9 found, deploying bug thwacker” message

[ian]

Now just waiting for the “E9 found, deploying bug thwacker” message

I was feeling a bit salty about the whole situation and expressed my frustration in command line format

[pfeerick]

I can appreciate it… it seems like the RP2350 was a bit half baked this time around…

Maybe I’ve been watching to much NHRL … https://www.youtube.com/shorts/ab4vLy-H48U

[ian]

I’ve gone through 1-Wire and I2C PIO modes using the board with 4.7K pull-downs. Neither are working. This could be some debug cruft that has accumulated over the past days of hacking. Maybe, but disappointing it isn’t an instant fix.

Based on some strange things that happened this week I have a creeping dread that there’s at minimum an SDK bug or maybe a silicon bug in the PIO too. No specific reproduction yet, but this code is butter smooth on RP2040 and buggy and weird on RP2350.

[ian]

1-Wire has no output and the pin is output low for some reason (should be input/floating high with the pull-ups).

HDUART is working.

I2C is kind of working, but with this weird trail of ticks on data??? Need to verify this against rp2040.

2WIRE crashes the Bus Pirate during setup_exc. Hum.

LED mode is twitching, but not in a good way. The output isn’t right. It should be a start frame (32 bits of 0), my data, and a stop frame (32 bits of 1). This is kind of almost that, but not really.

I did a big update to use the new SDK 2.0 PIO assignment function. Based on some crashes I’ve experienced I suspect that function isn’t working quite right. First I want to check all of these with the latest firmware on RP2040 to rule out recent bugs on all platforms.

[ian]

On RP2040/latest firmware:

1-Wire makes a signal, but doesn’t detect the attached sensor. This could be a bug I introduced earlier, could be easy fix.

I2C is messed up. Not in the same way as RP2350, but that defo isn’t 0xff

WOW! look at that. ~38khz clock signals coming out of the data pin in 2WIRE mode. Similar to I2C on RP2350. I’m pretty sure I didn’t cause that.

LED mode similarly messed up to RP2350.

Hum…

We can probably conclude that there is a bug in at least the SDK effecting both rp2040 and rp2350, along with some rp2350 specific bugs as well. Strongly feel is it related to the new PIO assignment function not placing code correctly/blowing out PIO code. It could also be something stupid I did while moving everything to that new function and a standardized pio_config struct for settings.

Next step is to disable everything that uses PIO, and manually assign resources one at a time. Also wonder if this might be useful.

Bus Pirate 5

Strongly recommend the last pre-SDK 2.0 firmware build for Bus Pirate 5.

I plan to spend a couple more days messing with SDK 2.0, but next week I’ll have to roll back to SDK 1.5 so we can keep pushing forward on the firmware for 5.

[phdussud]

About the commit in the SDK 2.0 you pointed out: The code is only relevant for RP2350 because it is #if for PICO_PIO_VERSION 1. The RP2040 has version 0
By the way, I don’t see this function being called anywhere in the BP code base. Maybe I am missing something.