• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 1865 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.

Bluetooth Smart affects somehow (?) Sensor Controller task execution

Ioannis Vourvoulakis
Prodigy 190 points
Other Parts Discussed in Thread: CC2650

Hi all,

Our application involves Bluetooth Smart communication and ADC use of CC2650.
Specifications are strict and we need samples from ADC every 125us.
We use sensor controller for the signal acquisition since it is a separate processor and it can precisely capture our input.
When I have an empty project in TI-RTOS, I can start successfully the task in the sensor controller and it runs every 125us (actually 122us using RTC based scheduler).
I can see that in the oscilloscope assigning a GPIO pin as output and it toggles every time the sensor controller task runs.

The problem is that when I use the Simple BLE peripheral example to add the sensor controller task, I do not notice stable toggling in the GPIO output pin.
Since sensor controller runs asynchronously with MCU, it shouldn't affect its operation.

The only thing I can imagine is that maybe something happens with the power managment but I cannot tell for sure.
Any ideas?
Is possible the BLE functionality to affect somehow when the tasks are executed in sensor controller?

Thank you in advance.

  • 0
    TI__Guru 56590 points
    Hello Ioannis Vourvoulakis,
    Are you only using the ADC? This should work. Have you made sure not to open the GPIO/DIO you use in the sensor controller in your BLE application as well? Please review your Board.c and Board.h files and make sure not to use the same DIO used by the sensor controller. You can add the DIO to BoardGpioInitTable to setup the default configuration, but you must make sure that your TI-RTOS application does not run PIN_open of any conflicting pin.

    In case further debugging is required you can disable power saving and run the code with the Simple BLE peripheral without initializing GAP role to. Comment out the following in your task function:
    // Initialize application
    // SimpleBLEPeripheral_init();

    Let me know how that works.
  • 0 in reply to Eirik V
    Prodigy 190 points
    Eirik thank you very much for your answer.

    I use only ADC from sensor controller.
    GPIOs are used at the moment just for debugging purposes.
    I do not use the same I/Os, I double checked it.

    I made comment the SimpleBLEPeripheral function and I the problem resolved so somehow BLE operation had an effect of sensor controller engine.
    Then I enabled BLE again (included the SimpleBLEPeripheral function) and disabled power saving.
    The problem was solved. I had stable calls for the sensor controller task and concurrently the BLE operation.
    The power consumption was increased from 1.2mA to 2.4mA (it was doubled).
    I will continue the development by disabling the power saving but the point is that the target application will be powered from battery and this feature is necessary.
    If there is any other suggestion or material to study better in order to have power managment enabled, SCE and Bluetooth Smart functionality let me know.

    Regards,
    Yiannis
  • 0 in reply to Ioannis Vourvoulakis
    TI__Guru 56590 points
    Hello Ioannis Vourvoulakis,
    Great.
    Are you setting periodical triggers to the ADC with AUX Timer 0?

    Because you are running an application which will enable power domains, dcdc, and clocks, the startup time for the sensor controller will vary depending on the current device state at the scheduled startup time. The startup time for the sensor controller when the whole device is in standby is more than 125 us. I would suggest you start a task that runs forever and initiate ADC conversions by using the AUX timer 0 as trigger source. You will then have to read out data from the sensor controller RAM periodically from your RTOS application as the sensor controller is not able to generate event/interrupt to the system processor until task completion. We are however working on future enhancements in SCS which might allow this.
  • 0 in reply to Eirik V
    Prodigy 190 points
    Thank you very much for your time.
    The clock tick for AUX timer0 is 4KHz, i.e. 250us and I thought I cannot use it. Have I misunderstood this interval?

    I will follow your recommendation about the task that will run for ever.
    One last thing. By enabling the POWER_SAVING feature, I made comment the Power_setConstraint(Power_IDLE_PD_DISALLOW) function and the problem has been also resolved having 1.9mA consumption (0.5mA less).

    Thanks again for your help.

    Regards,
    Yiannis
  • 0 in reply to Ioannis Vourvoulakis
    Prodigy 190 points

    Now I got it about timer0.
    Thanks again,

    Regards,
    Yiannis

  • 0 in reply to Ioannis Vourvoulakis
    TI__Guru 56590 points

    Hello Ioannis Vourvoulakis,
    No that is AUX Timer 1. The SCS API sets up AUX Timer 0 to run at 3000000 ticks per second (3MHz). Is is divided down from the AUX clock which is running at 24 MHz when the sensor controller is active. The adcStartAuxTimer0Trigger multiply the input period argument with 3 so that you simply select your wanted interval in us.

    // Start AUX Timer0 period trigger source for ADC to 125 us
    adcStartAuxTimer0Trigger(125) ;

  • 0 in reply to Ioannis Vourvoulakis
    TI__Guru 56590 points
    Do you mean you have the following setup that works?
    Power_setConstraint(Power_SB_DISALLOW);
    //Power_setConstraint(Power_IDLE_PD_DISALLOW);
  • 0 in reply to Eirik V
    Prodigy 190 points

    Eirik V said:
    Do you mean you have the following setup that works?
    Power_setConstraint(Power_SB_DISALLOW);
    //Power_setConstraint(Power_IDLE_PD_DISALLOW);

    Yes.

    Regards,
    Yiannis

  • 0 in reply to Eirik V
    Prodigy 190 points
    There is a small drift between clock that I use to read ADC data (from the RTOS application) and the clock that timer0 uses to produce the interval in the sensor controller.
    Is it possible to use somehow the same clock so the two processes to be synchronized?
    Otherwise, can you estimate when woulb be possible to alert the main CPU from a sensor controller task before the end of the task?

    Regards,
    Yiannis
  • 0 in reply to Ioannis Vourvoulakis
    TI__Guru 56590 points
    Hello,
    How did you implement the RTOS clock?

    I think the current plan is to update SCS to version 1.1.1 in Q1-2016 with support for a fwGenQuickAlertInterrupt () procedure do generate interrupt while a SC task is running.
  • 0 in reply to Eirik V
    Prodigy 190 points

    Thank you very much for your answer.

    I create a clock as the periodicClock in the example with period 1ms.
    The only difference is that the clock is not one shot clock.
    I have declare another event for this clock, the new clock handler function posts the application semaphore and the processing code runs in the application task's function.

    The SCS v1.1.1 will be a future version of SCS?

    Regards,
    Yiannis

  • 0 in reply to Ioannis Vourvoulakis
    TI__Guru 56590 points
    Hello,
    This TI-RTOS clock tick is based on the AON RTC running at 32768 Hz while the AUX timers run on 24 MHz. This explains the drift. What you can try is to pend on a semaphore in your RTOS task and set up a ISR handler function for the ADC interrupt where you post the appropriate semaphore. You should try to verify that the interrupt only occurs one time for each ADC measurement routine. The interrupt might occur before the result is ready in AUX RAM. In that case you can introduce a delay by one sample (read previous result when ADC event occurs).

    See how to clear the correct event flag for the AUX ADC in the code example in this thread:
    e2e.ti.com/.../1433112

    Yes, version 1.1.1 is a future version.