bool psu_fuse_ok(void) {
uint32_t fuse = amux_read(HW_ADC_MUX_CURRENT_DETECT);
// printf("Fuse: %d\r\n",fuse);
return (fuse > 300);
}
Confirmed the fuse is tripping because the current_detect hasn’t been changed to the IO pin. In REV1 the current_detect is moved to the XL9555, with notification using the XL9555 interrupt pin.
I reflowed my PSRAM. now I get:
HiZ> psram
PSRAM setup complete. PSRAM size 0x800000
Failed to allocate memory 1
This maybe because sytem_config is cleared after system_init.psram_size has been set by the PSRAM initialization which runs very early.
Thank you all for testing. I’m afraid the PSRAM detection in that firmware can’t be trusted because of my mistake.
There was an error i fixed where the system_config structure was initialized after the psram init. I wanted to be sure that issue was fixed and did a quick test, I’m pretty sure that’s the firmware I uploaded.
After testing on my board I can confirm that I uploaded that firmware. I’m sorry for that oversight.
The spark fun dev board with PSRAM didn’t arrive today so I don’t yet have a known good target to debug. Hopefully tomorrow morning.
Edit: @phdussud yes precisely
ok, then this is a firmware issue.
I don’t need this feature for the tests of the 7Rev0 I currently have planned. It was just something that I stumbled upon during use.
A Spark Fun dev board with PSRAM arrived and I flashed the Bus Pirate firmware. It finds the PSRAM and passes two memory allocation/write tests.
bus_pirate7.zip (304.9 KB)
This firmware is compiled for Bus Pirate 7 REV0 and includes fixes for the PSRAM detect and memory allocation tests. It should be a true and accurate assessment of the PSRAM on your board.
I will try to hot air rework my PSRAM chip next.
HiZ> psram
PSRAM setup complete. PSRAM size 0x800000
Memory 1 allocated
Memory 1 write OK
Memory 2 allocated
Memory 2 write OK
Yeah Ian!
Thank you so much for testing!
Unfortunately no such luck on mine:
HiZ> i
[...]
Bus Pirate 7
https://BusPirate.com/
Firmware main branch @ unknown (Mar 20 2025 13:15:45)
RP2350B with 512KB RAM, 128Mbit FLASH, 64Mbit PSRAM
S/N: E7426283131008BD
Storage: 0.20GB (FAT16 File System)
[...]
HiZ> psram
PSRAM setup complete. PSRAM size 0x0
PSRAM not detected - done
But with the older firmware I still get:
HiZ> i
[...]
Bus Pirate 7
https://BusPirate.com/
Firmware main branch @ unknown (Mar 18 2025 16:50:06)
RP2350B with 512KB RAM, 128Mbit FLASH, 64Mbit PSRAM
S/N: E7426283131008BD
Storage: 0.20GB (FAT16 File System)
[...]
HiZ> psram
PSRAM setup complete. PSRAM size 0x800000
Failed to allocate memory 1
Could this be for example that the first two data lines are properly connected to the PSRAM, but there are soldering issues on the other two? Then once you activate QPI mode and use all 4 lines it would fail.
But does the new size detection code already use QPI while the old one didn’t? Or is it something else?
No that was entirely a mistake on my part.
For testing my 7Rev0 I was previously using the binaries posted in this thread. But now I want to bend the firmware a bit to my will, so I have to compile myself.
The regular main branch is missing some parts for 7, the build for target bus_pirate7 failed, even after uncommenting the cmake rules for it.
I then tried the “psram_test” branch. This built fine and I can connect, but the output on the screen is garbled. There is some output visible, but it looks like some parts are rotated 90° and the colors are a bit off. Very strange. So I think something is wrong with this build too.
@ian could you check which branch you used to build your last binaries for the 7Rev0? Thanks.
The bp7R0 branch should compile OK. You are right there are bits of stuff everywhere. But bp7r0 should work (without uncommmenting anything). If it doesn’t, let me know and I will check it now.
Also, if you’re on main make sure you have the latest arm GCC, Henry enabled some C23 stuff.
Thanks, that worked.
I should have probably scrolled more carefully through the list of branches.
Builds may require GCC 13 … there’s no requirement for GCC14 (which is technically the latest), nor any requirement for pre-release GCC 15 builds.
For Ubuntu 24.04 LTS, apt default repositories include GCC 13.
One beauty of C over C++ is the strong focus on backwards compatibility.
Glad it worked.
Yes Henry is right, not the latest but I wasn’t aware of the exact version.
Hmm, is there a reason to believe that the ADC of the 7Rev0 is more noisy than the other versions?
Or was the limitation to one decimal place in the v command done because it already was this noisy on the previous versions?
I hacked the ADC code a bit to show me all digits and the values jump around like 100 mV or so. This is a bit more than I would have expected. The RP2350 even got the improved ADC in comparison to the RP2040.
--- a/src/commands/global/v_adc.c
+++ b/src/commands/global/v_adc.c
@@ -35,14 +35,14 @@ void adc_measure(struct command_result* res, bool refresh);
uint32_t adc_print(uint8_t bio_pin, bool refresh) {
// sweep adc
amux_sweep();
- printf("%s%s IO%d:%s %s%d.%d%sV\r%s",
+ printf("%s%s IO%d:%s %s%d.%03d%sV\r%s",
ui_term_color_info(),
GET_T(T_MODE_ADC_VOLTAGE),
bio_pin,
ui_term_color_reset(),
ui_term_color_num_float(),
((*hw_pin_voltage_ordered[bio_pin + 1]) / 1000),
- (((*hw_pin_voltage_ordered[bio_pin + 1]) % 1000) / 100),
+ (((*hw_pin_voltage_ordered[bio_pin + 1]) % 1000)),
ui_term_color_reset(),
(refresh ? "" : "\n"));
return 1;
This is in preparation for port impedance measurements.
Hmm, is there a reason to believe that the ADC of the 7Rev0 is more noisy than the other versions?
Maybe board layout? We didn’t change anything there.
Or was the limitation to one decimal place in the v command done because it already was this noisy on the previous versions?
As far as I recall it was always that way. I don’t recall making any changes to that.
The dac vreg does miss by .1v though. I didn’t debug it because it’s good enough for proving the rev and it’s gone on the next.
I did a quick git blame and there were no changes (except reformatting) to this code since initial firmware checkin in 2023.
So it could indeed always have been that noisy. Will probably check against my BP5.
I don’t think the ADC of the RP2350 is exceptionally good, for example what even the basic STM32 have is much better. But the ADC isn’t that bad that it fluctuates like 100mV, even after the voltage divider.
So there could either be issues with the opamps and muxes, or in the way the software drives them. Like giving them enough time to settle after switching the mux.
Looks like a side quest was just unlocked 
I was only referring to the ADC. For my tests I’m driving VOUT from the outside to reduce any inaccuracies that could be caused by the internal regulator.
No, Nome of the rp chip adc are especially good, but 2350 did calm down a lot. I haven’t experienced similar issues on 7r0, but I will poke at it a bit tomorrow.
Side quest successfully side-stepped with a quick averaging hack for the V command (continuous readout):
--- a/src/commands/global/v_adc.c
+++ b/src/commands/global/v_adc.c
@@ -48,6 +48,34 @@ uint32_t adc_print(uint8_t bio_pin, bool refresh) {
return 1;
}
+#define AVG_TIMES 64
+uint32_t adc_avg;
+
+uint32_t adc_print_avg(uint8_t bio_pin, bool refresh) {
+ // sweep adc
+ amux_sweep();
+
+ // average hack
+ if (adc_avg == UINT32_MAX)
+ adc_avg=(*hw_pin_voltage_ordered[bio_pin + 1])*AVG_TIMES;
+
+ adc_avg+=(*hw_pin_voltage_ordered[bio_pin + 1]);
+ adc_avg-=(adc_avg/AVG_TIMES);
+
+ printf("%s%s IO%d:%s %s%d.%03d%sV (Average: %d)\r%s",
+ ui_term_color_info(),
+ GET_T(T_MODE_ADC_VOLTAGE),
+ bio_pin,
+ ui_term_color_reset(),
+ ui_term_color_num_float(),
+ ((*hw_pin_voltage_ordered[bio_pin + 1]) / 1000),
+ (((*hw_pin_voltage_ordered[bio_pin + 1]) % 1000)),
+ ui_term_color_reset(),
+ (adc_avg/AVG_TIMES),
+ (refresh ? "" : "\n"));
+ return 1;
+}
+
void adc_measure_single(struct command_result* res) {
adc_measure(res, false);
}
@@ -63,6 +91,8 @@ void adc_measure(struct command_result* res, bool refresh) {
uint32_t temp;
bool has_value = cmdln_args_uint32_by_position(1, &temp);
+ adc_avg=UINT32_MAX; // magic value to init the averaging code
+
if (!has_value) { // show voltage on all pins
if (refresh) {
// TODO: use the ui_prompt_continue function, but how to deal with the names and labels????
@@ -104,7 +134,7 @@ void adc_measure(struct command_result* res, bool refresh) {
prompt_result result;
system_config.terminal_hide_cursor = true;
printf("%s", ui_term_cursor_hide());
- ui_prompt_any_key_continue(&result, 250, &adc_print, temp, true);
+ ui_prompt_any_key_continue(&result, 250, &adc_print_avg, temp, true);
printf("%s", ui_term_cursor_show());
system_config.terminal_hide_cursor = false;
}
After like twenty seconds or so the values are now good enough.