nRF51 and MPU6050 TWI Issue

RE: nRF51 and MPU6050 TWI Issue

FA — Fri, 11 Mar 2016 04:10:34 GMT

I think this post was the reason of the unwanted delay discussed in the comments.

RE: nRF51 and MPU6050 TWI Issue

MartinBL — Wed, 17 Feb 2016 11:50:24 GMT

Just thought I should let you know that we will look into this, but the SDK team is very busy these days and it might take while.

RE: nRF51 and MPU6050 TWI Issue

FA — Mon, 08 Feb 2016 05:55:20 GMT

I added another IO pin toggle after the while loop to see when the program comes out of it + a conditional IO toggle based on twi_tx_done:

if (twi_tx_done) nrf_gpio_pin_toggle(20);

As shown in 3rd figure, this test again shows that there is a delay between the time the program goes to the TWI event handler and exiting the while loop. I don't know what is causing this delay. The radio is not advertising when using TWI, and the previous scanning with time slot API has been closed by using:

sd_radio_session_close ();
sd_nvic_DisableIRQ(SWI0_IRQn);
sd_nvic_DisableIRQ(SD_EVT_IRQn);

RE: nRF51 and MPU6050 TWI Issue

FA — Fri, 05 Feb 2016 04:12:28 GMT

I updated the second figure with a new test. In this case an IO pin toggles after each NRF_DRV_TWI_RX_DONE event (in the TWI even handler). This should take the program out of the while loop below and go to the next transmission. But as you can see there is a considerable delay between this signal and the next SCL changes.

while((!twi_tx_done) && timeout--);  
if(!timeout) return NRF_ERROR_TIMEOUT;
twi_tx_done = false;

err_code = nrf_drv_twi_tx(m_twi_instance, MPU9150_ADDRESS, p_data, length, false);
if(err_code != NRF_SUCCESS) return err_code;

RE: nRF51 and MPU6050 TWI Issue

FA — Thu, 04 Feb 2016 05:56:06 GMT

Hi again! In your trace we should look at the gap around 0.6msec, which is between writing address (0x19) and writing the first byte (0x07). Still the delay is around 50usec. I started playing with MPU9150_TWI_TIMEOUT, which was 5000 in previous code and is 4000+1 in the new code you posted here. To me this just looked like a maximum wait time to generate an error in I2C read/write functions. But as you can see in the 2nd trace when I changed it to 1000, the delay dropped to around 250usec. I was getting some TWI errors when I used 500 and will test it again. Any thoughts why is this happening? I'm attaching the main function and MPU files. Main is using the same functions you are using and I checked all the used functions in MPU files and they are the same as yours. My whole project files are not still well documented, so it might be confusing to post, but that might be our last resort.

RE: nRF51 and MPU6050 TWI Issue

FA — Wed, 03 Feb 2016 15:08:11 GMT

Only in case of an error, yes, an LED blinks for 3 sec.

void mpu9150_twi_event_handler(const nrf_drv_twi_evt_t *evt)
{ 
    switch(evt->type)
    {
        case NRF_DRV_TWI_TX_DONE:
            twi_tx_done = true;
            nrf_gpio_pin_toggle(0);
            break;
        case NRF_DRV_TWI_RX_DONE:
						 twi_rx_done = true;
						 nrf_gpio_pin_toggle(20);
            break;
        case NRF_DRV_TWI_ERROR:
						for(uint8_t i=1; i<4; i++) {
							 gpio_blink2(1000);
							 }
            switch(evt->error_src)
            {
                case NRF_TWI_ERROR_ADDRESS_NACK:
                    break;
                case NRF_TWI_ERROR_OVERRUN_NACK:
                    break;
                case NRF_TWI_ERROR_DATA_NACK:
                    break;
                default:
                    break;
            }
            break;
        default:
            break;
    }        
}

RE: nRF51 and MPU6050 TWI Issue

MartinBL — Wed, 03 Feb 2016 14:52:17 GMT

I'm not seeing such delays. Here is my trace of the transmissions happening in mpu9150_config():

As you can see there is only a 28.93us delay. Do you do anything in your TWI handler that might take time?

RE: nRF51 and MPU6050 TWI Issue

FA — Wed, 03 Feb 2016 05:27:56 GMT

Hi Martin, thanks for your response and the example in SDK 9. I figured out the problem was maybe due to the 10usec toggling code in the twi_tx_done + setting the oscilloscope to capture the few transitions. So, now I can see that the code goes to twi_tx_done and SCL/SDA pins are changing as shown in the attached picture. I have one other question about the timing of TWI events in this code, which maybe is good to have it answered in this topic: You can see a constant separation between TWI events, e.g., the above picture shows 4 writes to 4 different registers in the MPU and there is around 1.3msec between them. I saw a similar separation during twi_read between sending the register address and receiving its value. Is this something related to the nRF TWI driver or MPU? Which parameter controls it?

RE: nRF51 and MPU6050 TWI Issue

MartinBL — Tue, 02 Feb 2016 10:39:59 GMT

Hi,

I ported the github MPU9150 example to SDK 9 (quick and dirty, but at least it works on my MPU9150). Here is the ported example.

A few questions:

Are you able to run the simple TWI example (without the MPU drivers) and get a response from your MPU? I.e. can you confirm that the MPU is working? If I understand you correctly you are able to communicate with it, but I still have to ask; are you using the correct pins?
How are you monitoring the TWI pins? Do you have a logic trace so you are absolutely sure that nothing happens on the TWI lines?
Maybe you can post your code? You can do it on our Support Portal if you want some confidentiality.