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

[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?