Part Number:CC2640R2F
Tool/software:TI-RTOS
Hey,
We've just started looking into using a CC2640R2F module instead of our current CC2650 one and are having issues with reliably running your example code. We notice strange behaviour during boot that is always related to the radio driver, RFCC26XX_singleMode.c. We're using simplelink_cc2640r2_sdk_1_50_00_58 and have tried both simple_np and simple_peripheral, but everything I mention below is from our simple_peripheral test.
We are using a ZB7412 module which has a 32 kHz external oscillator and CC2640R2F 5x5mm RHB VQFN32 package. I build the code with CC2650R2DK_5XD defined and then had to modify source\ti\blestack\target\board.h and change the include because cc2650r2em_board.h does not exist.
//#include "./cc2640r2em/cc2640r2em_board.h"
#include "../boards/CC2640R2DK_5XD/CC2640R2DK_5XD.h"
During boot the device will either work and begin advertising, or we get a BUSFAULT. It seems to occur randomly with roughly equal frequency. I enabled some exception decoding and see the error in ROV:
Hard Fault: FORCED: BUSFAULT: PRECISERR.Data Access Error. Address = 0x400c8000
The ROV helpfully tells me that it occurred during a Swi with handle 0x20001554. Unfortunately the ROV doesn't know about this Swi, but looking in my memory map I see that starting from 0x20001498 I have the .bss segment for RFCC26XX_singleMode.obj for 0x2a8 bytes. Open that in the memory bowser, and we see the relevant Swi is swiFsm whose function is swiFxnFsm.
Now, I don't know what exactly how the radio driver works, or what's relevant, but I'll describe what I think its relevant state is:
nClients = 0x01;
bRatSyncWasRequested = true;
bRadioHasBeenBootedBefore = false;
bRadioIsActive = false;
bRadioIsBeingPoweredUp = true;
bRadioIsBeingPoweredDown = false;
bRadioYieldingWasRequested = false;
bRadioYieldingWasCancelled = false;
bRadioDelegateXOSCHFSwitching = false;
pCurrClient = 0x20004988 (rfObject);
pFsmState = 0x6Fa5 (fsmPowerUpState);
I can't get a usable stack trace, so not sure where exactly it's gone wrong. However, LR = 0x10001d2b and PC = 0x10001d30, but I can't find anything in that range within my memory map. I'm assuming that it's a ROM address, but really have no idea. Stack starts at 0x20004000, is 0x400 long and current SP = 0x20004330.
I've copied the exception context below:
$addr N/A
$type ti.sysbios.family.arm.m3.Hwi.ExcContext
threadType Swi
threadHandle 0x20001554
threadStack 0x20004000
threadStackSize 0x400
r0 0x0
r1 0x2
r2 0x400c8000
r3 0x1c
r4 0x400ca036
r5 0x2
r6 0x7f
r7 0x0
r8 0x0
r9 0x2
r10 0x20004d2c
r11 0x0
r12 0x20004d2c
sp 0x20004330
lr 0x10001d2b
pc 0x10001d30
psr 0x41000000
ICSR 0x414803
MMFSR 0x0
BFSR 0x82
UFSR 0x0
HFSR 0x40000000
DFSR 0x0
MMAR 0x400c8000
BFAR 0x400c8000
AFSR 0x0
Going through my map, 0x20004d2c = rfSetup. Could just be junk in the registers, but rfSetup is the command that was executed via RF_runCmd. I can see that when it crashes, its status is always 0, which I believe is RFSTAT_IDLE and implies the command didn't get around to executing before it crashed (note: it WAS scheduled and I can see this if I break in RF_runCmd). I have also noticed (in simple_np) that this CMD_RADIO_SETUP will sometimes start (status=2) but not finish, which results in ICall_abort being called during gapRole_init because osal_snv_read(BLE_NVID_IRK, KEYLEN, gapRole_IRK) times out.
I hope that gives someone knowledgeable in this code enough information to figure out what may be going wrong, any help is much appreciated.
Thanks
Campbell