bspI2cInit() vs sensortagI2cOpen()

Hello Morgan,

We have not ported the SensorTag sample application to TI-RTOS 2.14. Also, the version used by TI-RTOS 2.16 is SensorI2C_open(), which will be supported in the next BLE-Stack SDK release.

We don't have any specific document, but the sample application code + the MPU9250 data sheet can serve as reference.

Best wishes

Ok.. When is RTOS 2.16 available?

Im trying to understand why after Powering Up the MPU and waiting 100ms why the RTOS is generating an exception handler? 

PIN_setOutputValue(hGpioPin,Board_MPU_POWER, Board_MPU_POWER_ON);
    delay_ms(100);

    sensorMpu9250Init();

What step I am missing or why is  the following code 'Semaphore_pend' is  generating an exception...

bool bspI2cSelect(uint8_t newInterface, uint8_t address)
{
  // Acquire I2C resource
  if (!Semaphore_pend(Semaphore_handle(&mutex),MS_2_TICKS(I2C_TIMEOUT)))
  {
    return false;
  }

TI-RTOS 2.16 is available now.

Th exception will happen if PIN_init() was not called or failed (trying to init non-existing pins or reserved pins). Did you check the PIN status? Can you confirm the PIN table is correct.

PIN_init is the function setting up the semaphore used by the pin driver and pending on a semaphore where all contents are 0's would lead to an exception.

Best wishes

I have PIN_init in there already and I have checked the PIN_Status using:

PIN_Status PS_retVal=PIN_init(BoardGpioInitTable);
	if (PS_retVal==PIN_SUCCESS)
	{
		System_printf("PIN_Status == PIN_SUCCESS !\n");
	}
	else
	{
		System_printf("PIN_Status == PIN_FAILED !\n");
	}

The Status is PIN_SUCCESS... The Board filed in 'BoardGpioInitTable' I am using in another project and it is good ... I get past the SELECT()

The difference is that in the other project I am using RTOS 2.13 and this project I am using RTOS 2.14 and have to use 'sensortagI2cOpen();' vs 'bspI2cInit();' in the old project?

I have checked the return value of 'sensortagI2cOpen();' and it is okay with RTOS 2.14 but maybe there is a step missing (difference between 'sensortagI2cOpen();' and ''bspI2cInit();' ??

Bool retVal=sensortagI2cOpen();
if (retVal==FALSE)
{
System_printf("sensortagI2cOpen did not initialise properly!\n");
}

What are the steps for migrating a project from 2.14 to 2.16 ? Is there a link somewhere to guide me and I can try that? with ble 2.1

The 'exception handler' is generated by the following clause in the 'if' statement:

bool bspI2cSelect(uint8_t newInterface, uint8_t address)
{
// Acquire I2C resource
if (!Semaphore_pend(Semaphore_handle(&mutex),MS_2_TICKS(I2C_TIMEOUT)))
{
return false;
}

Will 2.16 make a difference from 2.14 using BLE 2.1?

Porting topic has been discussed in associated post: e2e.ti.com/.../505428

We have not tested BLE 2.1 with TI-RTOS 2.16. Please refer to the sticky CC2640 FAQ: "Q: Are newer TI-RTOS releases compatible with an existing BLE-Stack SDK?" regarding this topic.

For the sem_pend abort, can you use the debugger to confirm the mutex is valid?

Best wishes

JXS,

Im not sure (low level OS is not my expertise)

&mutex maps to *str and what I see for the that in the debugger is

*(str) struct ti_sysbios_knl_Semaphore_Struct {...} 0x20002C70 
 __f0 struct ti_sysbios_knl_Event_Object * 0x00000000 0x20002C70 
 __f1 unsigned int 0 0x20002C74 
 __f2 enum ti_sysbios_knl_Semaphore_Mode ti_sysbios_knl_Semaphore_Mode_COUNTING 0x20002C78 
 __f3 unsigned short 0 0x20002C7A 
 __f4 struct ti_sysbios_knl_Queue_Struct {...} 0x20002C7C 
 __name struct xdc_runtime_Types_CordAddr__ * 0x00000000 0x20002C88 

I am not using a custom board - I am using the CC2650 SensorTag with the DevPack..If the problem is that the OS is thinking that the I2C bus is selected by some other component - I don't think so - it should be free to be SELECTed ...

Im really stuck here ... don't know what the next step is here to do?

I have gone back to using 'bspI2cInit' but "HapiResetPeripheral(PRCM_PERIPH_I2C0); " is not supported.
I found the following in the release notes for RTOS 2.14
C:\TI\tirtos_simplelink_2_14_01_20\docs\cc26xxTiRtos_drivers_release_note.txt

"Item 110

Summary : SPI driver used unsave reset mechanism.
Severity : Major
Affected Comp : SPICC26XXDMA
Release Notes : In SPI_transferCancel(...) there was a call to HapiResetPeripheral(...)
which is not safe.
Instead, we've implemented a safe TX FIFO flush function to avoid
having to call the unsafe HapiResetPerhiperal(...) function.

Workaround : Remove the call to HapiResetPeripheral(...) and replace it with the new
function SPICC26XXDMA_flushTxFifo(...)."

what function should I use with 2.14 for the I2C? This SPI method will not work I guess

I tried commenting this out and the SELECT() works now but the 'exception handler' now occurs when the following line is executed:

// Check the WHO AM I register
ST_ASSERT(sensorReadReg(WHO_AM_I, &val, 1));