SDK 2.0 pio is buggy on all hardware, but even worse on rp2350. I should know more tomorrow. Just looking for anything that might help.
2 Likes
I am not too surprised, based on my experience with the first days of the RP2040.
2 Likes
I donāt know if this is old news, but someone on the RPi forum has has errata corrections on the pull-up/up-down issues . https://forums.raspberrypi.com/viewtopic.php?p=2249027#p2249018
2 Likes
AgustĆn Gimenez Bernad (gusmanb) is developing a Pico-based logic analyzer, and has stopped the port to the Pico 2 until the chip is fixed. Itās that bad, he says.
If it canāt be fixed, we will just have to wait for the BP6. Itās okay, Ian. Donāt stress yourself.
4 Likes
Iām in that thread 
Thank you for the GusmanB link, interesting that heās throwing in the towel. We are preparing our public statement as well.
5 Likes
Woohoo! It appears to be an issue with the PIO assignment function pio_claim_free_sm_and_add_program_for_gpio_range.
Manually setting PIO and SM for LEDs and I2C eliminates the weirdness.
Iāll check the rest of the modes and then file a bug report at github. THEN we can do some heavy duty scoping to see if the 4.7K pull-downs are a reliable work-around for the wider extent of E9.
5 Likes
Actually, based on some weird bugs, I think it is actually pio_remove_program_and_unclaim_sm that is causing the over write of program instructions by not tidying up properly. Bug report filed.
Todo:
- Change all pio_remove_program_and_unclaim_sm to pio_remove_program
- LED mode (2 wire leds) actually seems to be buggy even in last sdk1.5 firmware, so need to diagnose that
- 1-Wire has a bit of regression, debug that
4 Likes
Iām going to push an update. Unless you can replace the pull-downs on 5XL and 6 with 4.7K, this wonāt really help you much except with the crashes. However, I think most of the PIO oddness is fixed so this should help 5 (rp2040) users get the latest from main.
Known issues:
- 1-Wire is messed up
- LED (2 wire LED) mode is messed up
- Some places to still update how PIO assignment is handled
3 Likes
Reverted 1-wire to early pre-rp2350 state. This is the latest auto build running the 1-wire scan command on Bus Pirate 5 (rp2040) with a ds18b20 temperature sensor attached. Seems we are doing ok with SDK 2.0 now.
Same firmware on RP2350. OWD pin is just stuck low.
Just for giggles, moved OWD to IO0, also at 0.
The thing is, this actually makes sense from the PIO program I think. So maybe it was actually a RP2040 shortcoming that needs a work around? Will try to make the PIO program do the āright thingā and leave the pin HiZ.
Bus Pirate 5 REV10 using SDK2.0. 18b20 detected.
uint div;
pio_sm_config c = onewire_program_get_default_config(offset);
sm_config_set_out_pins(&c, dir, 1);
sm_config_set_set_pins(&c, dir, 1);
sm_config_set_in_pins(&c, pin);
sm_config_set_sideset_pins(&c, dir);
div = clock_get_hz(clk_sys)/1000000 * 3;
sm_config_set_clkdiv_int_frac(&c, div, 0);
sm_config_set_out_shift(&c, true, true, 8);
sm_config_set_in_shift(&c, true, true, 8);
pio_sm_set_pindirs_with_mask(pio, sm, 1<<dir, (1<<dir) | (1<<pin)); //dir to output, pin to input
pio_sm_set_pins_with_mask(pio, sm, 0, 1<<dir); //dir to low (input to rp2350)
pio_gpio_init(pio, dir);
pio_sm_set_pins_with_mask(pio, sm, 1<<dir, 1<<dir); //dir to high (output to 1-wire) WHY?????
pio_sm_init(pio, sm, offset + onewire_offset_start, &c);
I simplified the 1-Wire PIO program to remove the stuff thatās not really needed. This works on RP2040.
pio_sm_set_pins_with_mask(pio, sm, 1<<dir, 1<<dir); //dir to high (output to 1-wire) WHY?????
This line confuses me. It makes the buffer pin (direction control) high just at the end of config. That makes the IO pin an output/low. We want an input/pulled high. If I remove this line rp2040 doesnāt work either (no output).
public start:
get_bit:
;mov pins, y side 0 [2] ; set pinctlz from y-register. This is
nop side 0 [2]
However at the PIO start we NOP and side set direction pin to 0 which is input/float, so it is obviously being reset. But this doesnāt happen unless the buffer is already an output/high (???) this feels like an RP2040 bug work around.
pio_sm_set_pins_with_mask(pio, sm, 1<<dir, 1<<dir); //dir to high (output to 1-wire) WHY?????
This same command is causing the RP2350 to be output low, and then nothing ever changes. I guess I need a debug hook to check if the program is even running?
So weird. Any thoughts welcome. This is in hw1wire.pio.
Going back to rp2350 to apply what Iāve found on RP2040.
SDK 2.0 seems to have blown out the logic analyzer on Bus Pirate 5 as well. It just freezes. Iām trying to run under debug to see what is happening, but debug quit working and all I get is the error:
warning: could not convert 'main' from the host encoding (CP1252) to UTF-32.
This normally should not happen, please file a bug report.
Soā¦ I feel like I need to either start the Bus Pirate vscode project over, or nuke vscode totally and start over.
This was due to this issue with the new Pico extension for VS code. After manually updating I can debug again.
I also feel like it is soon time to choose if SDK 2.0 is too buggy to use. Iāve fought it for over a week on different things. Iām sure Iāll pig headedly continue to pound at it for the rest of the week. Nothing involved moves the Bus Pirate forward in any way, just locating and fixing regressions.
1 Like
My favorite bug - something obvious with an easy fix! Bus Pirate 6 pins are working with the 4.7K hack, so we can debug the problems in 1-Wire mode.
ā.side_set 1 pindirsā at the top of the PIO program makes side set pins switch input/output instead of high/low.
We need high/low to control the buffer - remove āpindirsā directive and 1-Wire works on RP2350 chips. Weirdness, this should never have worked on RP2040 (BP5) either! Scared to look under that rock, so letās celebrate and scope the signals to see what effect 4.7K pull-downs have.
Iām really glad weāve arrived at this point today. If we canāt confirm a fix and push to manufacturing Monday, we are prepared to refund all the RP2350 orders and just pretend like it never happened.
5 Likes