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. 

[YooLoo]

Hello Martin, sorry for delayed reply. My nrf52840PDK was broken last week, so I had to purchase another one, and it took few days before I received it.

Now I've checked that the NRF_ERROR_BUSY is returned from nrf_drv_twi_tx().

However, my code doesn't call nrf_drv_twi_read_test() from multiple contexts. It is only called in a while loop, whenever a data ready flag, hal.new_gyro is set. A GPIOTE interrupt is used only to set the data ready flag. 

I tried to set the output data rate to lowest allowed value, but the error still happens.

Could you suggest any possible problem?

My code is modified from the STM32F4 project in the motion_driver_6.12 provided by InvenSense.

Thank you very much.

[MartinBL]

If you reduced the transfer speed, then maybe you should try increasing the MPU_TWI_TIMEOUT value. It could be that the --timeout variable reaches 0 before your previous transaction has completed. Be generous when you increase it. Start by increasing it 100x or something just to see if it works. 

[YooLoo]

Hello Martin, due to the schedule I have to work on the other part of my project in the previous two months. Now I think I've figured out what causes the NER_ERROR_BUSY. I am using NRF_LOG_RAW_INFO to print data to uart. This error will happen when NRF_LOG_FLUSH() is called while the deferred log buffer is too long. So is there any more efficient way to print out float data other than NRF_LOG_RAW_INFO?

[Nguyen Hoan Hoang]

Would be better to directly print it via uart.  Add retarget.c then you can use the standard printf over uart.

[YooLoo]

Thank you for advice! I've fixed my problem now.