another compdcm_mpu9150 question

MPU9150Init also sometimes fails with an error code 3 and I'm handling it this way :

    while (1)
    {
        //
        // Initialize the MPU9150 Driver.
        //
        MPU9150Init(&g_sMPU9150Inst, &g_sI2CInst, MPU9150_I2C_ADDRESS,
                MPU9150AppCallback, &g_sMPU9150Inst);

        //
        // Wait for transaction to complete
        //
        MPU9150AppI2CWait(__FILE__, __LINE__);

        //
        // Handle error
        //
        if (!g_vui8ErrorFlag)
            break;
        else
        {
            g_vui8ErrorFlag = 0;
            delayMs(5000);
        }
    }

I'm looking for something similar for the read.

Hello Jeff,

The error code 3 is I2CM_STATUS_ARB_LOST. Is this a multi master configuration?

Regards

Amit

I'm afraid I'm going to have to admit my ignorance here.  I'm just a GUI programmer thrown in way over my head struggling to stay afloat.  :)

I'm trying to combine the compdcm_mpu9150 example with code from another vendor.  Here's the configuration from that piece of code:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    SysCtlDelay(10);
    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_5); // PA5    Module SS & MRDY

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
    SysCtlDelay(10);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI2);
    SysCtlDelay(10);
    GPIOPinConfigure(GPIO_PB4_SSI2CLK); // PB4        Module SCLK        SSI2CLK
    GPIOPinConfigure(GPIO_PB6_SSI2RX); // PB6      Module MISO        SSI2Rx
    GPIOPinConfigure(GPIO_PB7_SSI2TX); // PB7        Module MOSI        SSI2Tx
    GPIOPinTypeSSI(GPIO_PORTB_BASE, GPIO_PIN_4 | GPIO_PIN_6 | GPIO_PIN_7);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);
    SysCtlDelay(10);
    GPIOPinTypeGPIOOutput(GPIO_PORTE_BASE, GPIO_PIN_0); // PE0        Module Reset

    SysCtlDelay(10);
    SSIConfigSetExpClk(SSI2_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0, SSI_MODE_MASTER, 1000000, 8);
    SSIEnable(SSI2_BASE);
    uint32_t ulDataRx[5];
    while(SSIDataGetNonBlocking(SSI2_BASE, &ulDataRx[0]))
           ;
    SPI_SS_CLEAR();

I'm just too much off a noob in this area to tell if anything is conflicting.

At this point, I'd just be happy to get the sensor restarted when there's an error.

Just noticed this in the interrupt handler :

     //
    // Clear all the pin interrupts that are set
    //
   GPIOIntClear(GPIO_PORTB_BASE, ulStatus);

If ulStatus indicates an error, will this still clear the interrupt, or will this permanently disable it?

Hi Jeff,

     Most likely if there is any error it will go to a fault handler.

     ulStatus value is taken from GPIOIntStatus right?

     Based from datasheet GPIOMIS, there are only two status to return, either an interrupt has occurred or not on that pin. See, details on the datasheet.

-kel 

You're right, I was confusing it with another status flag elsewhere. 

I'm just trying to figure out what to put in the "more robust code goes here" spot in the error handler.

    //
    // Go to sleep wait for interventions.  A more robust application could
    // attempt corrective actions here.
    //
    while(1)
    {
        //
        // Do Nothing
        //
    }

More "robust" and "noob!"  Some where/how - that twain ain't too likely to meet...  (i.e. some consideration should be directed to task demands vs. experience, skills, capabilities)

And - creating a post subject/title, "another xxx for yyy" while bit descriptive - would better benefit future searchers if it included some specifics... 

I have frighteningly little control over what the boss asks me to do on any given day.

Jeff Kenney said:

I have frighteningly little control over what the boss asks me to do on any given day.

Feel your pain - yet stand by past comment, "robust & noob" unlikely to end well.  (Brain Surgery for noobs, anyone?)

I was not attempting to be unkind/snarky - instead alert to the "reality" which seems buried w/in your quest.  Net, tube often have created unwise - spectacularly unrealistic expectations!   Too many fall victim...

And - you are "importing data from outside/other sources" and while resourceful - such just adds to your design complications & likely pitfalls.

Leading edge tech does have appeal - but best/fastest results (not to forget robust) are not (too often) achieved by those self-classed as "noob."  Boss in question may wish to "adjust" his/her thinking - better accept reality...

My ability to adjust the boss's thinking is limited as well :)

It just seemed likely to me that restarting the sensor after an error had occurred would be something that others had solved before and would be willing to share.