Occasional Hardware check failed

[electro991]

I get occasional « Hardware check failed » « Unable to determine front panel version » on boot. A simple off / on resolves it

It seems to occur only on first boot after being off.

Would you have an idea what could be causing this ?

[electro991]

Looks like i might have fried something when trying the 433tx module unfortunately. It started happening right after that. So far i tried a new picow and same issue.

[CrashOverride85]

that's weird, not sure why it would be intermittent.
More specifically, that error means it can't find find the ADC on the front panel - so possibly an issue with either that IC, or perhaps more likely, the ribbon cable / connector to the front panel.
It could also mean it can't find any i2c devices, so would would mean a fault on the i2c bus somewhere.

If you look at the serial output when it fails, it should be printing out an i2c scan as it powers up, which might give some clues about what's going on.

[electro991]

Thanks, I sourced an RS 232 adapter and connected 5 and 3 on accessory port to 5 and 2 on the adapter and got the output.

This is the output on a failed boot: I suspect my front panel has an issue, but I am not sure what to replace on it.

Hardware check (part1)

Running on Pico W (probably: ADC3 voltage = 0.025781v)
Battery: 100%
I2C scan:
00 . . . . . . . . . . . . . . . .
10 @ . . . . . . . . . . . . . . .
20 . @ @ . . . . . . . . . . . . .
30 . . . . . . . . @ . . . . . . .
40 . @ . . . . . . @ @ . . . . . .
50 @ @ . . . . . . . . . . . . . .
60 . . . . . . . . . . . . . . . .
70 . . . . . . . . . . . . . . . .
Done.

ERROR: unable to determine front panel version: device found at address 0x48 AND address 0x49?!
(only one - either - expected)
Digital potentiometer on audio board...Not found
ZC624 output board...Ok
EEPROM (write)...Ok
EEPROM (read)...Ok
Port expander for buttons (U7)...Ok
Trigger+Acc port expander (U8)...Ok
Status: FAILED

and right after, (turn off, wait 10 seconds and turn back on)

Hardware check (part1)

Running on Pico W (probably: ADC3 voltage = 0.024976v)
Battery: 100%
I2C scan:
00 . . . . . . . . . . . . . . . .
10 @ . . . . . . . . . . . . . . .
20 . @ @ . . . . . . . . . . . . .
30 . . . . . . . . @ . . . . . . .
40 . . . . . . . . . @ . . . . . .
50 @ @ . . . . . . . . . . . . . .
60 . . . . . . . . . . . . . . . .
70 . . . . . . . . . . . . . . . .
Done.

Front panel version 0.2
Digital potentiometer on audio board...Not found
Front panel (v0.2) LED driver (U9)...Ok
Front panel (v0.2) port expander (U2)...Ok
Front panel (v0.2) ADC...Ok
ZC624 output board...Ok
EEPROM (write)...Ok
EEPROM (read)...Ok
Port expander for buttons (U7)...Ok
Trigger+Acc port expander (U8)...Ok
Status: Ok

[electro991]

To add to the confusion here, i quickly setup a docker environment to compile the firmware and changed the bool for 0.1 panel check to false. Unit starts with that test firmware and no issues (front panel works , leds, buttons brightness, pots and rotary encoder)

seems like an issue on hardware check with 0x48 on the ADS1115IDGS responding on first boot. I don’t have a 0.1 panel and not too familiar with the code but wouldn’t checking 0x49 first and assume a 0.2 panel if it responds work ? Fallback to checking 0x48 after to see if a 0.1 panel is present

that is however assuming the ADS1115IDGS is behaving the way it should which i can’t really know for sure.

[CrashOverride85]

Thanks for the log, I think I understand what's going wrong / why.
When it fails, it's picking up the LED driver on 0x41 & 0x48, which I wasn't expecting to be there at initial power up.
Later on (in init_v0_2_front_panel()), it disables that feature of the LED driver where it shows up on 0x48 as well as 0x41.

I'm pretty sure the underlying cause is that the reset line of the LED driver is floating at the point determine_front_panel_version() runs - there really should have been a pullup or pull down on that line. If it gets read as high (i.e. not in reset), it shows up on 0x48 and confuses things.

I can see two solutions:

1. your suggested fix:

• look for the presence of something on 0x49, if present => v0.2
• look for the presence of something on 0x48, if present => v0.1
• else => error

2. If the io expander is detected on 0x38, use that to put the LED driver into a known state early on (reset high or low) to make things more predicable

I'll try and sort a fix this weekend, but it sounds like you've got it working reliably after updating that check?

[electro991]

Good afternoon. Thank for the reply. Yes it is working reliably now but what i did is quick and dirty and would break support of a 0.1 front panel. Awesome. I will test once you publish for sure

one more question, is it safe to flash the picos thru usb while plugged in the board / have you tried before. Not sure if 5v would back flow into the board or of its protected by a diode.

[CrashOverride85]

Glad it working for now at least :)

Yeah, it's fine to use the USB on the pico whilst it's plugged into the board, I often do that.
I'd suggest keeping the box switched off when USB is attached, but that's only because you'll likely get confusing errors otherwise (stuff powering up in the wrong order, in a weird state, etc.)

[Flyer133]

Hello CrashOverride85!

I tried to compile the code including the dev (fixing the HW check) but CMAKE show many errors...
I think that it comes form my computer...

Could you create a new firmware file including the new dev? I will very happy!
The dev to include large script files works very fine!

Thank you!
JR

[CrashOverride85]

I've added release 1.9..1 which fixes this issue and one other

[electro991]

Tested and fixed. Thanks