[CC2650] App crash when calling osal_snv_read and osal_snv_write from characteristic read and write callback functions

Yu Wan

Other Parts Discussed in Thread: CC2541, CC2650

I am porting codes from cc2541 to cc2650. It is a project with OAD support, i.e. the whole image includes BIM, Image A, Image B and Stack. The project is developed with reference to the document OAD for CC26xx.docx.

I add a new profile. My profile code calls GATTServApp_RegisterService() and provides the attribute table and the read and write callback functions.

In the read and write callback functions, it needs use osal_snv_read and osal_snv_write to retrieve and write parameters in the SNV area. However the app crashes on calling osal_snv_read and osal_snv_write every time within the callback functions. If I move the osal_snv_read and osal_snv_write functions to the taskFxn in the main app file through the appMsgQueue, there is no crash. However I could not find a way to block the callback functions until osal_snv_read and osal_snv_write functions finish. I try to use Semaphore_Handle method to block the callback functions, but it crashes as well.

Is this due to the configuration? Or these osal functions are not allowed to use this way? In cc2541, I use the same code base and no problem.

In the stack project, the setting is: OSAL_SNV=1.

over 10 years ago

0 JXS over 10 years ago

TI__Guru** 105180 points

Hi Yu,

As noted in the SW Dev Guide (SWRU393), you must minimize processing in a callback fxn. This limitation includes not making an BLE Stack API calls within the callback context If you need to delay sending a Read response, you can use the blePending return code, then call ATT_ReadRsp from your App task after you do the NV read. The use and restrictions for returning blePending to a Stack callback function are documented in the gattservapp.h include file.

Best wishes

0 Yu Wan over 10 years ago in reply to JXS

Prodigy 80 points

Hi JXS,

Thanks for your reply! I tried to use blePending and it did block the response. However in the GATT read callback function, the connHandle is always 0. Thus the app can't send the ATT_ReadRsp with correct connHandle to complete the process. As the callback function is called from the Stack, I am not able to debug it why the connHandle value is not set. Below is the prototype of the GATT read callback function.

typedef bStatus_t (*pfnGATTReadAttrCB_t)( uint16 connHandle, gattAttribute_t *pAttr,

uint8 *pValue, uint8 *pLen, uint16 offset,
uint8 maxLen, uint8 method );

Best wishes,

Yu Wan

0 JXS over 10 years ago in reply to Yu Wan

TI__Guru** 105180 points

Hi Yu,

A connHandle of 0 is a valid connHandle value. Usually, this is the first connection that is established.

Also, make sure you allocate the memory that is passed into ATT_ReadRsp using GATT_bm_alloc, only only free the memory if the return code from the ATT API is not SUCCESS.

Best wishes