I just bought a BP5 rev 10 from the Swedish vendor Electrokit.com a few days ago.
I started reading through the documentation and came to the firmware upgrade step.
The ‘i’ command shows:
Bus Pirate 5 REV10
Firmware v0.1.0 (commit unknown)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: 2A0E3FD3012961Ex
Following the instructions, I downloaded the currently latest zip (ci-buspirate5-main-fc8f968.zip) from: https://forum.buspirate.com/t/bus-pirate-5-auto-build-main-branch/20/269
I typed ‘$’ in the terminal and pressed enter, the RPI-RP2 flash disk mounted as expected.
On my computer, I extracted the “bus_pirate5_rev10.uf2” file from the zip archive and copied it to the RPI-RP2 flash disk:
C:\temp\>unzip -t ci-buspirate5-main-fc8f968.zip
Archive: ci-buspirate5-main-fc8f968.zip
testing: attic/bus_pirate5_rev8.uf2 OK
testing: bus_pirate5_rev10.uf2 OK
testing: git.log OK
testing: make.log OK
No errors detected in compressed data of ci-buspirate5-main-fc8f968.zip.
C:\temp\>unzip ci-buspirate5-main-fc8f968.zip bus_pirate5_rev10.uf2
Archive: ci-buspirate5-main-fc8f968.zip
inflating: bus_pirate5_rev10.uf2
C:\temp\>vol D:
Volume in drive D is RPI-RP2
Volume Serial Number is 0003-9F74
C:\temp\>copy bus_pirate5_rev10.uf2 D:\
1 file(s) copied.
As soon as the file has finished copying, all the LEDs on the BP5 light up solid red (NOT blinking) and it stays that way.
The documentation says the flashing should take a few seconds, I left it on for several minutes without any change.
Finally I unplugged the USB for a few seconds and plugged it back in, it goes immediately to solid red on all LEDs again.
I unplugged the USB again and held in the bootloader button on the bottom while plugging in the USB, now the LEDs are off and the screen is blank, and the RPI-RP2 flash disk mounted again.
I tried copying the “bus_pirate5_rev10.uf2” file to the flash disk again, and the same thing happened, immediately when the copy finishes, the LEDs go solid red.
It doesn’t matter if I drag and drop the “bus_pirate5_rev10.uf2” into the flash disk (this is how I did it on the first try) or copy the file from the Command Prompt.
What do I do now? The BP5 is completely unresponsive in the state when it is solid red.
If it helps, I also had the issue before doing the firmware upgrade, that the binary mode terminal got the lower port number and the VT100 terminal got the higher port number, but I found the solution to that here on the forum.
My computer has Windows 11 23H2 on AMD 5900X processor and X570 motherboard chipset.
I will prioritize getting a debugger connected … but I may need an assist pointing to where in the code it’s hanging, as I’ve had issues getting a debugger working.
If anyone has a good description of how to get a Raspberry Pi Debug Probe setup and working flawlessly under WSL2, let me know.
WSL2 debugging info
VSCode is working to edit and build source files in WSL2.
Currently, USBIPD is working well to redirect specific USB devices to WSL2. Admin access is only required when choosing to redirect a device the first time, which is nice.
OpenOCD v0.12 is installable by upgrading to Ubuntu 24.04 LTS … prior versions of Ubuntu only had older versions of OpenOCD installable via apt
Need to enable udev in WSL2 to avoid need for admin permissions running openocd. Do this by following instructions to edit /etc/wsl.conf to have the following:
[boot]
systemd=true
Manually running openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" from a WSL2 shell connects to the rp2040 just fine.
Manually running openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000; program ./build/bus_pirate5_rev10.elf verify reset exit" successfully updates the BP5 with a new binary.
Integration with VSCode for debugging … this is where I have not yet found success. It appears to connect, but when trying to break into the debugger, the following message appears on the console where OpenOCD is running:
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1016 ms). Workaround: increase "set remotetimeout" in GDB
After which, “nothing happens” with great gusto, while I am expecting the debugger to break in, and see a stack trace / variables / etc.
I am NOT able to reproduce this issue with either commit fc0b9c9 nor fc8f968 on my 1Gbit Rev10 board. In case it was related, I also formatted the storage to ensure a “fresh” installation.
Bus Pirate 5 REV10
Firmware main branch (2024-07-23T02:56:02Z)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: 28XXXXXXXXXXXXE4
https://BusPirate.com/
Storage: 0.10GB (FAT16 File System)
When loading fc8f968 on a brand-new, never-used 2Gbit Rev10, I AM able to reproduce this. At a guess, could this be related to some initialization of the flash media? (???)
I am not able to get a debugger connected under VSCode, even though I can program the image using OpenOCD manually (directly from bash).
Ian - you mentioned that you can reproduce this issue. Does a stack trace provide any hints? Since I cannot get the debugger to be helpful to me yet, I’m at a bit of a loss on how to proceed.
OK, I’m not able to get gdb working under VSCode, but I can connect it manually. The stack trace is consistently at:
0x10021550 in busy_wait_us_32 (delay_us=delay_us@entry=100000)
at /home/henrygab/buspirate5-firmware/build/_deps/pico_sdk-src/src/rp2_common/hardware_timer/timer.c:66
66 while (timer_hw->timerawl - start < delay_us) {
(gdb) bt
#0 0x10021550 in busy_wait_us_32 (delay_us=delay_us@entry=100000)
at /home/henrygab/buspirate5-firmware/build/_deps/pico_sdk-src/src/rp2_common/hardware_timer/timer.c:66
#1 0x1002157a in busy_wait_ms (delay_ms=delay_ms@entry=100)
at /home/henrygab/buspirate5-firmware/build/_deps/pico_sdk-src/src/rp2_common/hardware_timer/timer.c:88
#2 0x1000252c in mcu_detect_revision () at /home/henrygab/buspirate5-firmware/pirate/mcu.c:36
#3 0x100004c0 in main () at /home/henrygab/buspirate5-firmware/pirate.c:68
I look at pirate/mcu.c at line 36, and I don’t see anything particularly interesting. However, it appears this bus_wait_ms(100) is never completing?
Could this be a compiler optimization eliding code that would appear (to mere mortals) as valid?
Curiouser and curiouser … It appears that the timer_hw is not progressing. Manually reading the timerawl field continuously reports zero:
From gdb: x/w 0x40054000+0x28
Final note from me for tonight:
For my Rev10 2Gbit board, the following commit is where it starts to fail:
status
commit
description
b02dbad
Add enumeration for led effects
f1e28f5
Store actual RGB color directly in config file
Same binary will work on my Rev10 1Gbit board, but will fail on my Rev10 2Gbit board.
I’ll take a stab at it. To be clear, I’m not sure if I have a board that will fail here, this happened with the test board from a new batch in the Shenzhen office.
None of the Bus Pirates I have here are unresponsive, however they do light up solid red with the latest firmware if the disk has been formatted. This is also what I see when “party mode” is configured.
The Bus Pirate in the office that started up red is also not unresponsive, they just confirmed for me.
Upgrading from the shipped firmware to the latest and greatest has major updates to USB, so the port numbers change and for some reason the terminal and binary ports do seem to be swapped for everyone. Is it possible your ports changed or the binary and terminal mode ports are swapped? That would appear as unresponsive, but if you hit enter the 3.3volt supply should turn on.
I tried again with ci-buspirate5-main-fc8f968.zip with no other changes and now everything works and there is no solid red on the LEDs?
The output from ‘i’:
Bus Pirate 5 REV10
Firmware main branch (2024-07-17T11:04:01Z)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: 2A0E3FD3012961Ex
https://BusPirate.com/
Storage: 0.10GB (FAT16 File System)
The difference I can discern is that now I have saved configuration, I didn’t have that when I flashed this version before.
If it is interesting, here is the content of my BPCONFIG.BP file:
And yes, the shipped firmware v0.1.0 (commit unknown) was on ports COM4 and COM3, while all of the firmwares I’ve tried from the “latest” category have been on ports COM7 and COM6 respectively.
I don’t recall now when in the sequence of events I realized that new ports were in use, certainly when I jumped back to the old versions and went forward from there.
I guess I never tried pressing enter in the terminal once I had flashed in a late enough firmware that it defaulted to solid red on all LEDs again.
By the way; is the flash disk where the BPCONFIG.BP file is located, supposed to be write protected from Windows?
Thank you for the follow up. I also suspect there is an interaction with loading the config file (or lack there of). Henry has, I believe, some pending updates to LEDs - if not let me know and I’ll debug this further now.
The disk is write only while the terminal is open. When you close the terminal it will reattach as a read/write disk. I really need to update the docs on this.
Working device where storage is reformatted is not enough to cause repro
This will therefore primarily affect new customers, which is “bad”. Worse, even if it appears the issue is resolved, without factory-fresh devices (at least until root cause is known), it will be a Sword of Damocles…
Was it not resolved? I thought the core issue was non-responsive Bus Pirate? I’m sorry if I misunderstood, I will dive back in.
The red LED issue with no existing config file I think I understand and found accidentally while doing a general rework of the code. I will investigate and push a fix asap, but we’re all hands on deck at the moment.
Oh, it’s possible that I misunderstood. My fresh 2Gbit board ends up non-responsive with the red lights showing on some builds, but not others. I thought you also found a board where this reproduced?
If you understood the cause, then great! (and can you help me understand what it is that causes this?)
If not, then … … my previous post of concerns remains.
If your BP5 lights up, but appears unresponsive when connecting to its COM port:
Steps to diagnose
Disconnect the BP5
Reconnect the BP5
Notice the upper left corner of the OLED screen … it should indicate 0.0V
Connect to the lower numbered COM port with your terminal program
Hit “Enter” to attempt to use the BP5.
Expected Results:
For a fresh device / no config file, the BP5 would prompt: VT100 compatible color mode? (Y/n)>
For a used device, the screen will be redrawn with the expected UI.
Alternate Results:
Check the upper left corner of the OLED screen again … does it now indicate 3.3V instead of 0.0V? If so, good news! The device is likely functional, just the order in which the COM ports was exposed is now reversed. Redo the diagnosis steps, except connect to the higher COM port (instead of the lower).
Otherwise:
If the COM ports do not enumerate, or is neither one is responsive, then post a new issue for additional troubleshooting help.
There were a bunch of very nice updates to the USB descriptors, however the ports did switch. So I either need to fix that, or update the documentation. Also, the default binmode should probably respond to \r\n with “Wrong port! Try the other :)” or something useful.
I’m having difficulty connecting this to my PC (Windows 11). The PC recognizes it initially but then reverses that recognition shortly after (I get a “USB device not recognized” prompt).
In addition, when flashing to the latest firmware, the device shows a solid red color (windows still does not recognize it). I reverted to an older firmware and the rainbow scheme is exhibited once more, however, because of the earlier mentioned issue - I cannot use the device.
I’ve tried two PCs so far - same issue.
I also just tried your steps @henrygab but to no avail.
(and can you help me understand what it is that causes this?)