InvenSense DMP and MPL porting problem, data ready interrupt not working

[YooLoo]

Hello everyone,

I am currently working on porting the InvenSense motion driver 6.12 to nrf52.

I am using MPU9250 and nrf52840 pdk.

I've managed to set up the DMP and MPL, but I got stuck when I trying to read data from DMP FIFO.

I am instructed to call function dmp_read_fifo whenever a data ready interrupt is detected. I connected pin INT of MPU to P1.08 of nrf52840pdk.

Here is how I set up the interrupt:

#define ARDUINO_7_PIN               NRF_GPIO_PIN_MAP(1, 8)
#define PIN_IN ARDUINO_7_PIN 

static void pin_in_read(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
		hal.new_gyro = 1; //set data ready indicator
}

static void GPIO_setup()
{
	uint32_t err_code = nrf_drv_gpiote_init();
	APP_ERROR_CHECK(err_code);
	
    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);
    in_config.pull = NRF_GPIO_PIN_PULLUP;
	
	err_code = nrf_drv_gpiote_in_init(PIN_IN, &in_config, pin_in_read);
    APP_ERROR_CHECK(err_code);			
}

However hal.new_gyro is never set. Does anyone meet the same problem?

My project can be found here.

Thanks in advance.

[MartinBL]

Have you remembered to enable your GPIOTE channel with nrf_drv_gpiote_in_event_enable()?

[YooLoo]

Hello Martin,

Yes you are right, I did forget nrf_drv_gpiote_in_event_enable() ! Thank you very much. However, after I fixed this error, I met another problem:

The code works fine at first, then after a short random time, dmp_read_fifo() and mpu_get_compass_reg() fails.

dmp_read_fifo returns an error code -1, which is caused by the function mpu_read_fifo_stream(). This function returns an error code -3, which is caused by the failure of function i2c_read;

mpu_get_compass_reg returns an error code -4, which is also caused by the failure of function i2c_read;

Here is my i2c_read function:

uint32_t mpu_twi_read_test(uint8_t slave_addr,
											uint8_t reg_addr,
											uint32_t length,
											uint8_t *data)
{
	  uint32_t err_code;
		uint32_t timeout = MPU_TWI_TIMEOUT;
	
	  err_code = nrf_drv_twi_tx(&m_twi_instance, slave_addr, &reg_addr, 1, false);
		if(err_code != NRF_SUCCESS) return err_code;

    while((!twi_tx_done) && --timeout);
    if(!timeout) return NRF_ERROR_TIMEOUT;
    twi_tx_done = false;	
	
	  err_code = nrf_drv_twi_rx(&m_twi_instance, slave_addr, data, length);
    if(err_code != NRF_SUCCESS) return err_code;
		
		timeout = MPU_TWI_TIMEOUT;
    while((!twi_rx_done) && --timeout);
    if(!timeout) return NRF_ERROR_TIMEOUT;
    twi_rx_done = false;
	
		return err_code;
}

Could you pls have a look what might cause this problem? I've updated my code on Github. Many thanks!

[MartinBL]

Are you saying that the function mpu_twi_read_test() is returning negative 4? Looking at the nrf_drv_twi_tx() and nrf_drv_twi_rx() code and documentation it doesn't look like they are capable of returning positive 4 (NRF_ERROR_NO_MEM), and definitely not negative 4. Error 3 (NRF_ERROR_INTERNAL) is possible though, and it indicates that you have a HW problem. Maybe you have some loose wiring or bad solder joints. 

[YooLoo]

Thank you, Martin. I rechecked my code, and I confirm that the error code returned from the nrf_drv_twi_tx() and nrf_drv_twi_rx() is 17, which indicate NRF_ERROR_BUSY.

It happens when the code runs for a short random time.

I checked related cases, but I am still quite confused why would this error happens. Could you pls give me some advice?

[MartinBL]

The NRF_ERROR_BUSY error could occur if you call nrf_drv_twi_rx() or nrf_drv_twi_tx() while a TWI transfer is already in progress.

What I suppose could be the issue, is that you call mpu_twi_read_test() from several different contexts in your code. For example, maybe you call it from your main context, and then you get a GPIOTE interrupt and call the function from within the interrupt context too, but the TWI is already busy with the transfer started in the main context is still in progress. 

It could be interesting to know whether it is nrf_drv_twi_tx(), at line 9 in your code snippet, or nrf_drv_twi_rx() at line 16 that returns the error. If it's the former, then you probably call mpu_twi_read_test() too often, if it's the latter then somehow the while((!twi_tx_done) && --timeout) "guard" is failing.