CCS/CC2640R2F: Call to "icall_directAPI(...)" falls into ICall_abort()

Tool/software: Code Composer Studio

I am developing application on the CC2640R2F chip. I used SimplePeripheral example as a base for my application. My only changes to the example was removing two-button menu and adding one functionality to the application thread that is called using MessageQueue.

The application is working properly on the LAUNCHXL-CC2640R2. As I am targeting custom board I have made some changes to board files - removing pin declarations for buttons and changing LEDs locations, but the most important pins (UART, SPI etc.) are the same.  I am using single ended configuration of RF on RF_P pin.

When I load my application on the custom board, the problem occurs inside the SP_init() function. ICall_registerApp() call finish successfuly. The problem originate in the GGS_SetParameter(GGS_DEVICE_NAME_ATT, GAP_DEVICE_NAME_LEN, attDeviceName) call (which is defined as a call to icall_directAPI(...) ). Inside the "icall_directAPI(...)"  execution goes fine until the "ICall_waitMatch(...)" call which return ICALL_ERRNO_TIMEOUT. This cause entering ICall_abort() later.

My custom board works with the UartEcho example for TI drivers and with the SensorController Studio, so the configuration of the board should be correct. The code is working properly on the LaunchPad, even when using custom board files.. I have investigated if the problem lies within the oscillator.

Looking at the registers:

AUX_DDI0_OSC.CTL0.SCLK_LF_SRC_SEL = 0b11 -> low freq. XOSC

AUX_DDI0_OSC.STAT0.SCLK_LF_SRC = 0b11 -> low freq. XOSC

So the oscillator seems to be correcty selected and used as a source of LF_Clock. I have outputted it on the pin and checked with the Oscilloscope and the signal operates on 32.76kHz +/-  0.03.

I am using ABS-7-32.768KHZ-6-T with 6pF load capacitance and +/- 20ppm. The capacitors used together with the oscillator are 12pF.

My understanding now tells me that the problem most likely lies in the 32kHz clock delivery for BLE5 stack and that's the reason why the message to the stack is lost and the ICall_waitMatch throws TIMEOUT. However, register settings and the clock output indicates that clock is indeed used and operates at correct frequency.

What could cause the problem of always fliing into the ICall_abort()?

Thanks,

Maciej