TWI communication failes after soft reset

[chrizz]

Hi community,

in our setup we use the LSM6DSL IMU using TWI. First we initialize the TWI peripheral, then we configure the IMU. After that we initialize PPI to automatically request information from the IMU once the IMU's interrupt pin toggles from low to high. Everything is working fine so far, unless we do a soft reset (e.g. triggered by an OTA update). Then ocassionally the initialization fails during nrf_drv_twi_tx.

Our first idea was that somehow the registers might not be reset correctly but regarding the nrf52832 datasheet they do. We also considered that some variables were retained in RAM. Therefore we forced clearing the bss section on startup by removing the following lines from gcc_startup_nrf52.S file.

#ifdef __STARTUP_CLEAR_BSS
#endif

Unfortuately this attempt did not help getting rid of our problem. Or is there a more elegant way to clean the RAM contents before entering main function?

Can it be that some the IMU communication disturbs the initialization of the TWI/PPI peripheral? Meanwhile I don't know what to do anymore :-/

Best regards

Christian

[Vidar Berg]

Hi Christian, 

The application's reset handler will re-load everything to RAM on before entering main(), so I don't think that's the issue. Do you know if the error is returned from the  nrf_drv_twi_tx() function or if it's notified through your TWI callback? Also, are you using the TWI driver from the SDK, or your own?

Best regards,

Vidar

[chrizz]

Vidar Berg said:

Do you know if the error is returned from the  nrf_drv_twi_tx() function or if it's notified through your TWI callback?

It seems likes nrf_drv_twi_tx() does not return.

Vidar Berg said:

Also, are you using the TWI driver from the SDK, or your own?

I'm using the driver from the SDK (12.2.0)

Regard

Christian

[Vidar Berg]

Thanks for confirming the SDK version. Is the driver configured in blocking or non-blocking mode (TWI master) and how is it powered,  is it through a GPIO pin? 

Regards,

Vidar

Edit: No longer relevant, but just to clarify that by "and how is it powered,  is it through a GPIO pin?" I meant to ask if the sensor was powered through another GPIO pin.

[chrizz]

Vidar, thanks you for your efforts so far.

We meanwhile figured out that enabling the bus clearing procedure during init (clear_bus_init=true in nrf_drv_twi_config_t ) solves the problem. (similar to this issue)

This problem wasn't present when we were using TWI in blocking mode only. But after switching to PPI based (non-blocking) mode it obviously seems to be necessary (in our setup) to clear the bus on init. I assume the slave starts "talking" with the first clock signal (after soft reset) und therefore it disturbs nrf_drv_twi_tx().

Best regards

Christian

[Vidar Berg]

Hi Christian,

Glad to hear that you found the problem. Is it possible that you may have had an ongoing TWI transaction when you initiated DFU, and that is why the bus gets "stuck"? Or maybe the same IOs are used for something else in DFU mode? Anyway, I don't see any drawbacks in enabling this option. 

Best regards,

Vidar