Intermittent issues with i2c interface and interrupt line on microbit v2.21

[relia1]

Configuration

Operating System: MacOS 14.3.1 (although also seen on windows and linux)
Device: Microbit v2.21 (nrf52833)
Device DETAILS.TXT

# DAPLink Firmware - see https://daplink.io
Build ID: v0258-beta3-g0004198b (gcc)
Unique ID: 9906360200052820ed5513866061c627000000006e052820
HIC ID: 6e052820
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Incompatible image detection: 1
Page erasing: 0
Daplink Mode: Interface
Interface Version: 0258
Bootloader Version: 0257
Git SHA: 0004198b3ad9b0938a1039e28405b759fea78c11
Local Mods: 0
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x725bea7d
Interface CRC: 0x38953278
Remount count: 0
URL: https://microbit.org/device/?id=9906&v=0258

Steps to reproduce

1. Flash a user program on the microbit v2 that utilizes the combined interrupt over i2c (p0_25) for dataready on the lsm303agr (accelerometer)
2. Run said program from the host connected over USB
3. Disconnect the device from the USB and then plug it back in

Results

Intermittently getting unending busy being returned (0x39)
Intermittently I am getting addressnack back from the i2c interface with the user program unable to get interrupts
Upon disconnecting and reconnecting I consistently run into the above issue

Expected results

Expected the interrupt line to be released so interrupts from the lsm303agr are able to occur
Expected microbit to be able to run user software even when unplugging and plugging it back in

Additional Notes

Adding a sleep and a dummy read on the i2c interface has seemed to help a decent bit, but it does not help with the unplugging and plugging back in scenario.

Rust program I have been using for testing these scenarios
https://github.com/relia1/state_machine

[mbrossard]

This looks like a question for @microbit-carlos

[microbit-carlos]

Hi @relia1, I think I understand more or less the issue, but need to confirm some things from your description:

3. Disconnect the device from the USB and then plug it back in

Is there a battery pack connected to the micro:bit in this scenario. Or does disconnect and reconnect the USB cable mean the board fully power cycled?

Intermittently getting unending busy being returned (0x39)

Is that from the lsm303agr?
Who/what is "returning busy" and where is the value 0x39 coming from?

Intermittently I am getting addressnack back from the i2c interface

When trying to communicate with the LSM?
I've never seen this specific issue before, which on first impression might independent of the interrupt signal?
If a NACK is received after sending the address it usually means no device has responded, which might be unrelated to the Interface MCU with DAPLink? This one might be harder to diagnose.

with the user program unable to get interrupts

Unable to get interrupts? What does that mean exactly?
As you mentioned later, assuming the issue is that DAPLink is keeping the shared interrupt line "active", do you mean that no additional interrupt is being detected in the target MCU pin simply because the signal is not toggling (as DAPLink is already pulling it)?
Or do you mean something else?

Adding a sleep and a dummy read on the i2c interface has seemed to help a decent bit,

Just to double check, this is an I2C read from the Interface MCU running DAPLink?
Which address?
When are you doing this dummy read?

---

As you have already noticed, there are some events in the Interface MCU that will assert the interrupt signal and keep it asserted until an I2C read operation is performed. Mostly pressing the reset button for 5 seconds, or inserting the USB cable when battery powered.

The interrupt signal will stay asserted until an I2C read is done, so any other interrupts from other devices in the shared pin will be "lost".

Assuming you are doing a sleep and dummy read on startup, it might also be important to ensure the sleep is around 1 second, as it might take that long for DAPLink to fully startup.

[relia1]

Is there a battery pack connected to the micro:bit in this scenario. Or does disconnect and reconnect the USB cable mean the board fully power cycled?

Just connected via the USB cable (no battery pack)

Is that from the lsm303agr? Who/what is "returning busy" and where is the value 0x39 coming from?

That value was when I was doing an i2c read to 0x70 (I2C config/comms interface)

When trying to communicate with the LSM? I've never seen this specific issue before, which on first impression might independent of the interrupt signal? If a NACK is received after sending the address it usually means no device has responded, which might be unrelated to the Interface MCU with DAPLink? This one might be harder to diagnose.

This would be I2C config/comms interface returning that

Unable to get interrupts? What does that mean exactly? As you mentioned later, assuming the issue is that DAPLink is keeping the shared interrupt line "active", do you mean that no additional interrupt is being detected in the target MCU pin simply because the signal is not toggling (as DAPLink is already pulling it)? Or do you mean something else?

Yeah specifically not seeing the shared interrupt line interrupts coming from the lsm303agr due to the line already being held down.

Just to double check, this is an I2C read from the Interface MCU running DAPLink? Which address? When are you doing this dummy read?

I keep getting it flipped on which is target and which is interface, but I think it is a read from the target mcu to the interface mcu over i2c.

As you have already noticed, there are some events in the Interface MCU that will assert the interrupt signal and keep it asserted until an I2C read operation is performed. Mostly pressing the reset button for 5 seconds, or inserting the USB cable when battery powered.

Assuming you are doing a sleep and dummy read on startup, it might also be important to ensure the sleep is around 1 second, as it might take that long for DAPLink to fully startup.

That's pretty much what I have done. But it hasn't helped in the scenario in which I unplug/plug it back in (without the battery pack)

[microbit-carlos]

Is that from the lsm303agr? Who/what is "returning busy" and where is the value 0x39 coming from?

That value was when I was doing an i2c read to 0x70 (I2C config/comms interface)

Ah, I see, thanks for the clarification.
This is the "default" state when there is nothing to report.

When trying to communicate with the LSM? I've never seen this specific issue before, which on first impression might independent of the interrupt signal? If a NACK is received after sending the address it usually means no device has responded, which might be unrelated to the Interface MCU with DAPLink? This one might be harder to diagnose.

This would be I2C config/comms interface returning that

So just to confirm, sometimes when trying to do an I2C transmission to address 0x70, there is a NACK after the address, which would indicate no device has responded, is that right?

So, how often are you trying to communicate with the Interface via I2C? From the link to the repo you've posted it looks like it's only done once during startup?
If that's the case, I guess it's possible the I2C transmission is attempted before the Interface had a chance to initialise the I2C driver and that might be why it's not ACKing.
However, there is already a 1 second delay during startup, so that should have given the Interface enough time to initialise everything. If you increase to something ridiculous like 5 seconds, do you still get NACKs from the Interface?