• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 278 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2340R5: BLE Stack Initialization fails in custom board containing CC2340R53(64 KB part)

Akash Saji
Intellectual 790 points
Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

One of my customers has flashed the same code in TI CC2340R53(64KB part) evaluation board and their custom board having CC2340R53(64KB part). In TI board the code is working whereas in the custom board they are facing the ICall_abort issue.

BLE stack is not getting initialized fully and before that they are getting ICall_abort.

To confirm the issue, we have also tried flashing SDK example application (simplelink_lowpower_f3_sdk_8_10_01_02\examples\rtos\LP_EM_CC2340R53\ble5stack\basic_ble) into the custom board and still we see the same issue.

On commenting out the BLE init API ,BLEAppUtil_init(&criticalErrorHandler, &App_StackInitDoneHandler,&appMainParams, &appMainPeriCentParams) from the basic BLE example application and have another user task which blinks LED, accessing I2C ports they are all working as expected.

On initializing the BLE stack it is throwing error in the custom board only.


I just checked the differences in dev board and custom board.

TI board has external flash which the custom board don't have.
Are any of the BLE parameters or stack stored in the external flash and accessed while booting/ initializing?


The 48MHz crystal used in custom board is ABM11W-48.0000MHZ-7-K1Z-T3 whereas in dev board TZ3908AAAO43 is used.
And 32KHz crystal used in custom board is ABS07AIG-32.768KHZ-7-T - 32Khz whereas in dev board TZ3359DAAO73 is used.

Can you give a solution for this as they need to fix the issue very soon to meet the production deadlines.

Regards,

Akash Jose Saji

  • 0
    TI__Guru** 101460 points

    Hi Akash, 

    Thank you for reaching out. 

    Can you check whether the pre-compiled basic_ble example in SDK 8.40.00.61 (attached for convenience) produces the same issue? https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1051/0118.basic_5F00_ble_5F00_app_5F00_cc2340r53.hex

    Best regards, 

  • 0 in reply to Clément
    TI__Intellectual 790 points

    Thanks, Clement, for the response.

    Will check this out and get back to you.

    Regards,

    Akash Jose Saji

  • 0 in reply to Akash Saji
    TI__Intellectual 790 points

    Hi Clement,

    I just checked this with customer, it was not working for them.

    Regards,

    Akash Jose Saji

  • 0 in reply to Akash Saji
    TI__Guru** 101460 points

    Hi, 

    Thanks for telling me. Here are a few more questions to try to get closer to the root cause of the issue.

    1. Have you also tested whether the image I have shared works on the LaunchPad? 
    2. Can you share the marking of the device on the evaluation board and on the custom design? 
    3. Can you try commenting out the other user task and see if the issue still occurs? 
    4. Can you share your SysConfig file?

    Analyzing the call stack you have provided, I see the error is raised by after calling "GAP_RegisterForMsgs" (line 157 of ble_stack_api.c). The most obvious reason why this function could fail is because the ICall_EntityID passed to bleStack_initGap is incorrect. Skipping a few steps, the ICall_EntityID is created by the function BLEAppUtil_stackRegister that MUST be called before any other ICall related function call. 
    All this to say, that if this is the root cause of the issue, we should expect the issue to reproduce on the LaunchPad as well.
    For sanity, I would still recommend to verify the function BLEAppUtil_Task() has not been accidently modified. Below is the expected content:

    void *BLEAppUtil_Task(void *arg)
{
    // Register to the stack and create queue and event
    BLEAppUtil_stackRegister();

    // Init the ble stack
    BLEAppUtil_stackInit();

    Best regards, 

  • 0 in reply to Clément
    TI__Intellectual 790 points

    Hi Clement, the stack issue is resolved.

    The customer had mounted DNP resistor R8(0 ohms) across the 48 MHZ XTAL. After removing it, it started working fine.

    Now they have few queries related to the HFOSC 48MHz:

    1. Even with the resistor R8(0 ohms)  across the 48 MHZ XTAL  present,  for the functions in software(except  BLE) , there is no  icall abort issue and  RTOS Scheduling,  peripherals like I2C ( which needs clock) are functioning , why is that so ?

    2. Is the MCU runs always in internal RC High Frequency oscillator? Since there is no option to change the setting of high frequency clock source in sysconfig user configuration settings.

        Is there a way to configure MCU to run in External XTAL in case there is no straightforward settings in sysconfig tool?

    3.  It is mentioned that HF RC Oscillator tracks its accuracy against an external 48 MHz Xtal, does this affect peripheral clocks if in case 48 MHz external Clock is not present or not functional??

    Can you provide some inputs on the above queries?

    Regards,

    Akash Jose Saji

  • 0 in reply to Akash Saji
    TI__Guru** 101460 points

    Hi Akash, 

    Good to hear the issue has been root caused. 

    Could you please open a new thread to discuss the XTAL as it will require participation of our HW experts?

    Thanks and regards,