• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 154 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2642R: critical section

John Quant
Prodigy 80 points
Part Number: CC2642R

Hello.
We need to periodically generate a pulse at the GPIO output of a certain duration from 20 to 500 microseconds ± 15%.
We create our application based on the simple_peripheral SDK 5.20 .

We change the output to the port directly in the timer interrupt function (the timer priority is set to the highest (1<<5)). The pulse duration is formed using CPU delay().
The moment of pulse formation is wrapped in HAL_ENTER_CRITICAL_SECTION and SysTickDisable(), but despite this, the pulse sometimes receives an addition of more than 20%, the feeling that something interferes with the process of pulse formation.

Our code:

static void pulse(GPTimerCC26XX_Handle handle, GPTimerCC26XX_IntMask interruptMask)
{
SysTickDisable();
HAL_ENTER_CRITICAL_SECTION(key);
HWREGB(GPIO_BASE + TEST_PIN) = 1;
CPUdelay(3000);
HWREGB(GPIO_BASE + TEST_PIN) = 0;
HAL_EXIT_CRITICAL_SECTION(key);
SysTickEnable();
}


For us, the pulse duration is very critical, how in our case can we take 100% CPU time without breaking the application?

What are the problems with disabling interrupts for 500 µs every 10ms?

Please, give any thoughts, advice or indicate a possible direction for solving this problem!
Regards John

  • 0
    TI__Guru**** 202256 points

    Hi John,

    HAL_ENTER_CRITICAL_SECTION will call HwiP_disable but not delay other software operation for tasks of equal or greater priority.  The BLE5-Stack library is likely taking control of the core to accomplish it's own necessary tasks, regardless of the application task's usage.  There are some possible ways to avoid this behavior:

    1. Use the Sensor Controller Studio as the separate ARM core will avoid interference from the main core and/or BLE5-Stack operation.
    2. Employ PWM control to allow the hardware timers to create more accurate pulses.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 80 points

    But this function is called from a hardware interrupt, so it should have priority over software interrupts, + HAL_ENTER_CRITICAL_SECTION also contains swi_disabled. We thought that the systick timer could be built into the critical section, and turned it off, but to no avail. Perhaps it is possible to stop all interrupts at the kernel level (except built-in ones)? Why is this question more interesting to us, 1. because. the function of pulse formation and control has already been implemented 2. the sensor controller is busy processing capacitive touch buttons, 3. we also need to start the ADC after a certain time after the beginning of the formation and also until the end of the formation of the pulse and compare the read values ​​with the template.
    The PWM controller is an interesting idea, thanks, but so far I don’t understand how in this option to determine a certain time from the beginning of the pulse formation to the end of the pulse formation, taking into account the delays for the ADC conversion.

    Sorry for not providing details sooner.

  • 0 in reply to John Quant
    Prodigy 80 points

    we also tried using an empty loop operation instead of CPUdelay

  • 0 in reply to John Quant
    TI__Guru**** 202256 points

    It certainly is not a good idea to hold your application inside a hardware interrupt for so long.  Can you test whether the BLE is active during this time (by monitoring the RF pins or power consumption)?  Have you considered starting another timer before turning on the test pin, which is then turned off after expiration of the timer triggers another hardware interrupt?  Also be sure to not have your application enter standby mode and use an accurate HF external crystal to source your clock.  https://e2e.ti.com/f/1/t/1125349 

    Regards,
    Ryan