I’m using the latest firmware on my BP5 and BP6. I’m having trouble with the built-in device demos. In particular, the tsl2561 light sensor and the SI7021 .
Here’s a summary
On a BP6 - 12c scan doesn’t work… So I stopped testing.
On a BP5 - scan works, but if I execute “tsl2561” or “si7021” - I get no response. . But if I execute bus commands, they start to work, and then the tsl2561 command started working again,
This session is attached.
In another session, I followed the step by step instructions on the web page, and the bus commands returned I2C bus errors. Bug2.txt (2.4 KB)
Thanks for the bug report. I reworked I2C this week and the tested the si7021 demo specifically, it should be ok.
Firmware main branch @ unknown (2024-10-12T17:20:50Z)
This seems a bit old, and the bus errors are no longer a thing because of how I wrote the new PIO program. Could you please try this one.
To be fair, I have not tested tsl2561 or the other demo because I can’t find the boards. I also did the I2C rework on v5 and haven’t tested on 6. I will do a complete test of everything before the end of the week.
Which is what I have done in the past, I then I discovered that in all of the previous builds, the firmware was output in ./bus_pirate5_rev10.uf2 but in the new version, the firmware is now in ./src/bus_pirate5_rev10.uf2 and the old firmware was not deleted. So by doing what I have always done in the past, I installed the old firmware by mistake
Update. I have a breadboard with both devices on it.
BP6:
I2C> scan
I2C address search:
Found 0 addresses, 0 W/R pairs.
I2C> tsl2561
Read light intensity (LUX) from TSL2561 sensor
I2C> si7021
Read temperature and humidity from SI7021/HTU21/SHT21 sensor
Error writing humidity register
BP5:
I2C> scan
I2C address search:
0x39 (0x72 W) (0x73 R)
0x40 (0x80 W)
Found 3 addresses, 1 W/R pairs.
I2C> tsl2561
Read light intensity (LUX) from TSL2561 sensor
ID: 5 REV: 0
Chan0: 92 Chan1: 92 LUX: 1
I2C> si7021
Read temperature and humidity from SI7021/HTU21/SHT21 sensor
Error reading humidity data
As I recall, the humidity sensor chip wasn’t actually a SI7021, but similar, perhaps a HTU21D, but as I recall, when I last successfully ran the si7021 command, it was able to make several measures, except the firmware version, which was chip specific.
But now it doesn’t work at all.
So in summary:
Command BP5 BP5
Scan Yes No
tsl2561 Yes No
si7021 No No
I2C> ms5611
Read temperature and pressure from MS5611 sensor
Temperature: 18.969999
Pressure: 1024.660034
I2C> si7021
Read temperature and humidity from SI7021/HTU21/SHT21 sensor
Humidity: 43.90% (0x66 0x32)
Temperature: 29.17C (0x6e 0xc0)
This is actually HTU21
I2C> si7021
Read temperature and humidity from SI7021/HTU21/SHT21 sensor
Humidity: 84.63% (0xb9 0x9a)
Temperature: 29.92C (0x6f 0xd8)
Serial Number: 0xffff00ffffff0aff
I2C> ms5611
Read temperature and pressure from MS5611 sensor
Temperature: 24.660000
Pressure: 1024.469971
I2C> si7021
Read temperature and humidity from SI7021/HTU21/SHT21 sensor
Humidity: 69.87% (0x9b 0x62)
Temperature: 28.43C (0x6d 0xac)
Serial Number: 0xffff0000000015ff
Unfortunately I wasn’t able to reproduce the bug. Do you have a version of PulseView with FALA support compiled? That would help us get a better look at whats happening on the bus.
Here is a status update using 2024-11-20T18:01:23Z and the most recent build : “Firmware main branch @ 664f569 (2024-11-19T10:10:06Z)”
BP5/BP6 - the individual bus commands work for the SI7021
BP5/BP6 - “si701” returns error
BP5 - tsl2561 works, scan works
BP6 - tsl2561 returns no results. scan does not work.
I’m working on porting the FALA Pulseview for Linux.
Try the bus at 100khz. There are some grimlins. It seems like we don’t always know when the PIO state machine is actually idle so stuff gets garbled up. I haven’t had any issues with the actual i2c syntax, but the demos use higher level functions that seem to be effected. Henry has a recommended fix I will test in the next day or two.
Probably best to use any other mode with FALA. I2C is the only one I haven’t verified because I need a full day block of time to do the needed testing and revisions.
I found multiple places with (not officially confirmed) rumors that, if the PIO program includes a delay on the pull instruction (or maybe the instruction prior to the pull instruction), it might prematurely flag the UART as empty in the PIO’s debug flag. Specifically, if the delay causes the pull to not immediately execute, the flag indicating it’s stalled while reading the UART would be set if this bug is real.
Admittedly, this seems an unlikely thing, even as an errata (which I’ve not seen evidence of).
However, it would be consistent with a premature termination of the hwled_wait_idle() function, which would be consistent with the too-short delays shown in that earlier bug. Thus, it was at least worth investigating as a potential cause.
The workaround is innocuous (checks that the UART buffer is empty prior to checking the debug txstall flag), but the order of operations was indicated to be important … why is outside my ken. If it fixes the issue, maybe the real reason is because it forces a delay between writing and reading the debug register? I’ve seen wierder things…
If workaround still flaky...
…, then as an additional step, it is possible to calculate which instruction in the PIO program contains the pull from the FIFO, and verify that’s where the PIO program is stalled. I did not implement this in the first workaround, as if that were needed, then it would suggest a much more significant bug (e.g., documentation of the debug flags’ meanings would, at minimum, need to change).
workaround code in brief
// 1. Clear the (latching) state machine `txstall` bit
// 2. Check if the state machine TX fifo is empty
// 3. Check if the state machine `txstall` bit is set
// define the bit to be cleared / tested
uint32_t SM_STALL_MASK = 1u << (PIO_FDEBUG_TXSTALL_LSB + pio_config.sm);
// write that bit to the register to clear the bit
pio_config.pio->fdebug = SM_STALL_MASK; // writing a 1 clears the bit
// check for empty FIFO first...
// and only if it's empty, check if the stall mask is set.
bool result =
pio_sm_is_tx_fifo_empty(pio_config.pio, pio_config.sm) &&
(pio_config.pio->fdebug & SM_STALL_MASK);
return result;
}
Today I have been using the si7021 command at 400khz and it appears to be working. I2C mode validation is still in progress, so I can’t say it’s bug free
One thing that might be useful (in general) is that when there is an error - provide more details. Or optionally a “-v” option that shows the individual measurements.
// humidity
data[0] = 0xf5;
if (pio_i2c_write_array_timeout(0x80, data, 1, 0xffff)) {
printf("Error writing humidity register\r\n");
goto si7021_cleanup;
}
busy_wait_ms(23); // delay for max conversion time
if (pio_i2c_read_array_timeout(0x81, data, 2, 0xffff)) {
printf("Error reading humidity data\r\n");
goto si7021_cleanup;
}
In the si7021 command, some error text is shown. In reality, both errors mean the chip didn’t ACK it’s address or payload bytes. I’m open to suggestions to make this more clear. It’s not something I’ve thought a lot about.
If you still have issues please let me know. The best feedback would include a screenshot of the FALA output so we can see exactly what is happening in the wires.
I will try. I haven’t gotten the FALA working yet. I think I have to use pulseview on Windows to do this, correct? (The Linux version isn’t compiling for me yet).
My fix was merged into @phdussud 's repo upstream doesnt have it yet. So you may use mine or @phdussud fork bp5-fala branch. I mean at least it worked at that time I see there were some changes to fala depends if compatible
I’m making a script to demonstrate the problem (See my other post), but right now I see that I may have an error in my setup. I have a light sensor and humidity sensor on a breadboard, and this is the same setup I had months ago, when it worked.
Now I am looking at it in detail, and I see I’m getting different results from the Device Demo when done in discrete steps, which perhaps explains why the macro doesn’t work. So now I suspect I damaged my sensors somehow. However, scan finds the two sensors on my BP5, so I am confused.
