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.

Unexpected delay on CC2540 caused by BLE stack

Dear All:

When we implement an interrupt on a timer to generate a periodic waveform in 120 Hz,

we find there will be a little bit delay for every 2-3 cycles.

But when I disable BLE stack, the delay disappears!

Is there a specific periodic task in BLE stack and is it possible to lower its priority or

any other method to minimize the effect of the delay?

Any suggestion will be welcome.

Ray

  • Hi, Ray

    What frequency tolerance may be acceptable for your design? Could you clarify how much delay do you have? Which timer do you use?

    BR,

    Oleg 

  • Dear Oleg:

    Timer 1 is used, because we need to synchronize the waveform to a 120 Hz input signal source.

    The found delay is about 360 us currently. We prefer to reduce the delay less than 80 us.

    Is it possible to be done?

    If the delay is unavoidable, what will be the minimum delay we can get by optimization?

    Thank you for paying attention on this issue.

    Ray

  • So, to make it clear: the idea is to use external 120 Hz waveform as an interrupt source and produce a waveform that is synchronized to input's edges?

    ISR routine and then event processing will take some time when full stack is active - unavoidable overhead. Unfortunately, I have no accurate worst-case estimation of ISR-to-event delay, if it is the delay you want to shorten. The only thing that will be undoubtely fast is using ISR that does all processing by itself (e.g. set appropriate output bits).

    Try following for start:

    1. Disabling power saving modes (PM2, 3):

      osal_pwrmgr_device( PWRMGR_ALWAYS_ON );

    2. Find (Ctrl+Shift+F) the following string in SimpleBLE project and change ENABLE to DISABLE

    HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_ENABLE_CLK_DIVIDE_ON_HALT );

    3. As an off-chance - check your IO pin configuration. Timer1 uses same pins that one of USARTs does, so make sure the latter is not enabled (set pin priority appropriately)

     

    BR,

    Oleg

  • Dear Oleg:

    Thanks for your suggestion.

    We have added 

    HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_DISABLE_CLK_DIVIDE_ON_HALT);

    and

    osal_pwrmgr_device( PWRMGR_ALWAYS_ON );

    in the end of XXXApp_Init task.

    Since we are using alternative 2: P0.6 and P0.7, it will not conflict with UART1.


    Originally the delay is around 360 us.

    After the modification, the delay will vary dynamically from 0 us to 360 us.


    Will there be any other possibility to further improve it?

    Best regards,

    Ray


  • Hi, Ray

    Just to check - look at your _Main.c file. In the end of SimpleBLEPeripheral_Main.c, there should be following:

    // Final board initialization
    InitBoard( OB_READY );

    #if defined ( POWER_SAVING )
     osal_pwrmgr_device( <some mode> );
    #endif


    /* Start OSAL */
    osal_start_system(); // No Return from here

    osal_init_system() is called earlier that that, it is possible that red-text part discards your power settings in App_Init.

     

    BR,

    Oleg 

  • Dear Oleg:

    The osal_pwrmgr_device() had been removed before I posted this question.

    Best regards,

    Ray

  • Hi,

    I'd recommend to change HCI_EXT_ClkDivOnHaltCmd( HCI_EXT_ENABLE_CLK_DIVIDE_ON_HALT ) to DISABLE right within stack, but if you did it after HCI init, it probably does not matter.

    Can you elaborate more on the way your code works, please? Like, what timer ISR does and how it conveys event/message to higher-level task, and how that task creates waveform. I ask because I am not sure what to recommend without understanding the basic cause of delay.

    Obviously, the interrupt itself has rather predictable execution time (if it is a critical section, of course), but once you return control to OSAL, there is no way to predict delays e.g. between events. You may want ro consider creating your own task with high priority, and move it up the task queue until radio part of stack fails. Not best design practice, I admit.

     

     BR,

    Oleg

     

  • Dear All:

    Recently I found the answer!

    Try to use

    HCI_EXT_HaltDuringRfCmd( HCI_EXT_HALT_DURING_RF_DISABLE );

    It will fix the problem I posted before.

    Thanks to everyone, especially Oleg.

    Best regards,

    Ray