Hexspansions with non eeprom I2C devices cause crash

[ChrisDick]

Hexspansion has 2 I2C devices, one eeprom and one motor controller.

output log:

Registered async event handler for RequestForegroundPushEvent: _Scheduler - _handle_request_foreground_push Registered async event handler for RequestForegroundPopEvent: _Scheduler - _handle_request_foreground_pop Registered async event handler for RequestStartAppEvent: _Scheduler - _handle_start_app Registered async event handler for RequestStopAppEvent: _Scheduler - _handle_stop_app Registered async event handler for HexpansionInsertionEvent: HexpansionManagerApp - handle_hexpansion_insertion Registered async event handler for HexpansionRemovalEvent: HexpansionManagerApp - handle_hexpansion_removal Registered event handler for ButtonDownEvent: HexpansionManagerApp - handle_button_down Registered event handler for ButtonUpEvent: HexpansionManagerApp - handle_button_up Registered async event handler for PatternEnable: PatternDisplay - _enable Registered async event handler for PatternDisable: PatternDisplay - _disable Registered event handler for ButtonDownEvent: Launcher - _handle_buttondown Registered async event handler for RequestStopAppEvent: Launcher - _handle_stop_app Registered async event handler for InstallNotificationEvent: Launcher - _handle_refresh_notifications Registered async event handler for ShowNotificationEvent: NotificationService - _handle_incoming_notification Hexpansion inserted in port: 2 Found hexpansion header: HexpansionHeader[ manifest version: 2024, fs offset: 32, eeprom page size: 32, eeprom total size: 8192, vendor id: 0xCAFE, product id: 0xCAFF, unique id: 0, friendly name: Caffeine!, ] Could not initialize eeprom: ('Non-contiguous chip addresses', [87, 90]) Hexpansion inserted in port: 3

[walkerdanny]

I've done a bit of poking around and found what's going on here.

The helper script mount hexpansions.py is calling: https://github.com/emfcamp/badge-2024-software/blob/6900e39443cb653541ff73cc8d7156d0650755fa/modules/system/hexpansion/util.py#L57

This in turn constructs an EEPROM object, and in the constructor function for this object, it performs a scan for EEPROM devices: https://github.com/emfcamp/badge-2024-software/blob/6900e39443cb653541ff73cc8d7156d0650755fa/modules/lib/eeprom_i2c.py#L39

Because an EEPROM object can consist of up to 8 physical EEPROM chips, the scan tries to collect all of the EEPROM addresses within a range of 8 from the base address. Therefore everything within the range of (in the case of the Zetta part) 0x57 to 0x5F could be a valid EEPROM IC that needs to be part of this logical device! https://github.com/emfcamp/badge-2024-software/blob/6900e39443cb653541ff73cc8d7156d0650755fa/modules/lib/eeprom_i2c.py#L52

It then errors out because the address of the TI DRV2605 that I used on the Club Mate Caffeine Jitters hexpansion is 0x5A, but it isn't consecutive with any other address, so there must be something wrong.

I can think of two ways of fixing this (one is in #118).

• Hard-limit the number of EEPROM ICs to be 1 by passing max_chips_count = 1 to the EEPROM constructor in util.py
• Add a check into the scan to verify that the four most significant bits of any device found are 1010. I think this is the general device identifier for a serial EEPROM across manufacturers.

Bonus content:

The AW9523 port expander IC that's used on the main board has an address range of 0x58 - 0x5B, so if someone has used that on a hexpansion along with the Zetta EEPROM (and I know of at least one case of this) they'll probably be experiencing the same issue.

[hairymnstr]

We can't hard-limit the EEPROM IC count to 1 unfortunately because the other recommended EEPROM (M24C16) presents as 8 separate 256 byte EEPROMs at 0x50-0x57. That presents other problems. Masking to 1010 sounds like a good solution.

[hairymnstr]

Fixed in 1.8.0, only single-address EEPROMs at 0x50 or 0x57 or a multi-address EEPROM from 0x50-0x57 are now considered.