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.

RTOS/MSP432P401R: Timer period issue

Part Number: MSP432P401R


Tool/software: TI-RTOS

Hello,

Timers in periodic callback mode will not execute any faster than a 9-10 uS period. Is this an RTOS issue with bulky code or a threading issue? MCU operating at 48 MHz MCLK, 24 MHz SMCLK (Power profile 3). 

Issue easily demonstrated with the timer blink led demo in the simple link SDK (simple link for MSP432P401R demo board), reconfigured LED GPIO pin for P3.0 with direct port write to speed up (P3OUT = 0x01, P3OUT = 0x00) and timer period to 1 (US).

Timer clocked by SMCLK at 24 MHz, SMCLK verified by porting out P7.0 to scope. I should be able to easily generate a callback at 1 MHz but no matter what the timers (32 bit, A) will not callback any faster than 9-10 uS. Do I have to abandon RTOS to get adequate execution speed or is something else wrong? The callback is being used to time a multiplexed sampling circuit in the intended application, but is only being tested with a P3.0 direct port on/off write currently.

Appreciate any help,

Jonathan

  • Jonathan,
    I think this must be a limitation of the default settings somewhere in the RTOS. I was able to verify your results on that timerled example. I'll check with our RTOS support and see what other settings can be changed to get a more frequent callback than what you've been observing.
    Regards,
    Bob L.
  • Jonathan,
    One other thing. Assuming your MCLK is running at 48MHz, you're leaving very few cycles between interrupts/callbacks. For what you are trying to do, have you verified that you're not running into limitations based on cycle counts of the instructions involved? Have you been able to run a similar example without an RTOS to verify that you aren't CPU-limited?
    Regards,
    Bob
  • Hi Bob, 

    I was able to run it non-RTOS and get up to 10 MHz periods. From what I can gather there is either a significant latency in the RTOS that causes the 100 kHz timing or the timer settings are being defaulted in the RTOS. Since the latency for a GPIO write in the RTOS seems to be around 2 uS, I'm guessing that its a combination of both. I suppose the RTOS cannot be used for any mid-performance operations using the peripherals. If 100 kHz is the maximum execution rate for a single operation, then with pin writes your looking at a 30 kHz operation rate or so - or 1/4800 of the system clock rate. I was really hoping to utilize the portability of the RTOS but it seems to waste so much performance it's not feasible. I definitely do not need a GHz execution rate processor to run a 1 MS/s system.

    Best,

    Jonathan

  • Jonathan,

      The response back from the RTOS team matches your assumption. Namely, that for a 48MHz part, the register-save and dispatch to an ISR, plus the return from that ISR, will likely take enough instructions to bring down the maximum execution rate for the GPIO toggle to 10us. The timing benchmarks we have run show dispatcher takes 122 cycles, on entry and 223 on exit.  Doing the math on this (345 cycles) at 48MHz gives us a hard floor of ~7.2uS. So you're 10us is in the range of what's expected.

    We ship benchmarks in each kernel release, these can be found by clicking on “Timing and Size Benchmarks” in the SimpleLink MSP432P4 kernel release notes.  Within that benchmark document, look for the MSP432P401 device and click "Times", which will bring up this benchmark document.

    The relevant rows in the table to look at are:

    Benchmark Cycles
    Hwi dispatcher prolog 122
    Hwi dispatcher epilog 223

    Adding these two values gets us to the 345 cycles described above. Based on these benchmarks, it seems you are already seeing the max performance within TI-RTOS. If you want to toggle at higher rates, you will have to use a non-RTOS approach.

    ANOTHER OPTION (w/ RTOS)

    There’s a “zero latency” approach where you can set the ISR priority to highest priority and that ISR will take a short path w/o OS intervention.

    That ISR cannot make any OS calls.  It can, however, trigger a secondary interrupt (presumably on a less frequent or special-case basis) that can use the OS.

    You can find a description of "Zero Latency Interrupts" in the BIOS documentation here.

    Regards,

      Bob L.

**Attention** This is a public forum