• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 124 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.

TMS320F28075: Dynamic Timer SYS/BIOS not reliable on timing

Robert
Prodigy 80 points
Part Number: TMS320F28075
Other Parts Discussed in Thread: SYSBIOS

Tool/software:

Dear All

We are using the TMS320F28075S and we have detected some timing issues. However, we are investigating the ISR duration by just toggling some GPIO's and measure these using a Logic Analyzer.

We detected several issues, which would take too long to describe all, I only list the most important one's :-)

We are using SYS/BIOS (6.83.0.18) and create a Timer Interrupt dynamically (not in the .cfg file) and post a Swi in the HW ISR, so the main workload is done in SWI context and not in HWI context.

However, we are facing the issue, that the Timer HWI does not get called as implemented below. It only occurs, when the ECAN0INTB_ISR HWI gets called.

The Timer_create functions is based on a peripheral from the c2000 MCU family and is called within a Hardware interrupt context. On which peripheral is it based on? one of the CPU timers or a PWM ? The first parameter of Timer_create is the logical id. What is this useful for?
Which priority from the PIE table would it have then?

We are suprised, because the CAN SWI has nothing in common with the Timer ISR.

Would you suggest it is good practice to post SWI within a HWI. As far as I understood the SYS/BIOS manual, it is recommended like this. However, it creates more context switches and therefore reduction of efficiency.

How do we know the priority if we use some Timer or Clocks creation in the .cfg file?
There are some interrupts for the TI RTOS. How do we know, when and how long are they called?

White: XINT HWI ISR (Priority 120)

Red: XINT SWI ISR (posted by White)

Yellow: Timer SWI (posted by Green)

Green Timer HWI ISR (Priority: no idea / see question above)

Blue: CAN HWI (Priority: 102)

Purple: CAN SWI ISR (posted by Blue)

Timer_Params timerParams;
Error_Block errBlock;
Error_init(&errBlock);
Timer_Params_init(&timerParams);
timerParams.period = 200U;
timerParams.periodType = Timer_PeriodType_MICROSECS;
timerParams.arg = 1;
Timer_Handle timer1 = Timer_create(1, TIMER1INT_ISR, &timerParams, &errBlock);

Timer_start(timer1); // might be pseudo-code.... :-)

Thank you and best regards

Robert

  • 0
    TI__Guru 53105 points

    Hi Robert,

    Thanks for your patience. Were you able to make any progress debugging this issue?

    Robert said:
    The Timer_create functions is based on a peripheral from the c2000 MCU family and is called within a Hardware interrupt context. On which peripheral is it based on? one of the CPU timers or a PWM ? The first parameter of Timer_create is the logical id. What is this useful for?
    Which priority from the PIE table would it have then?

    Timer uses the CPU Timer hardware. The id parameter corresponds to which CPU Timer instance (0, 1, or 2), so interrupt-wise it's INT1 (PIE INT1.7) INT13, or INT14 respectively.

    Robert said:
    Would you suggest it is good practice to post SWI within a HWI.

    I think it depends on what priority you want it to have. Swis are lower priority than all Hwis but higher priority than Tasks, so it's useful for things you want to always be interruptible by your Hwis and where a short interrupt latency isn't important. Their priorities are also more meaningful than the Hwi priorities since interrupts on F28x devices are aren't configurable in hardware and by default don't support nesting.The priority field in the Hwi_Params structure isn't supported. You need to use the masking settings instead.

    Robert said:
    There are some interrupts for the TI RTOS. How do we know, when and how long are they called?

    RTOSINT is named that way for legacy reasons, but isn't actually used by SYS/BIOS for anything. I believe INT14 is highlighted for TIRTOS use because CPU Timer 2 is the default CPU Timer used by SYS/BIOS for its Clock Timer. However, the Clock module does allow you to specify a different Timer id if you want it to use one of the other CPU Timers. The Clock module also works by posting a Swi from the Timer interrupt and the Swi priority is configurable (looks like it's 15 by default)

    You can use ROV Classic in CCS to look at the Hwis running on the system. The Clock module's timer interrupt is the most likely one. I think Timestamp may also use a Timer interrupt if you have it enabled.

    Whitney

  • 0
    Prodigy 80 points

    Hi Whiteny, thank you for your reply.

    This helped a lot.

    We measured a delay of 1.5us when posting a SWI within a HWI. I assume, that this time is required for the scheduler to wake up, checking all tasks and check their priorities plus storing variables and additional time. How can we check, how much time the scheduler does require?
    it is definitely dependent on the number of tasks and how much ISR's get triggered.

    Best regards

    Robert

  • +1 in reply to Robert
    TI__Guru 53105 points

    The SYSBIOS documentation provides some benchmarks where you can get an idea of how long dispatcher execution, context switches, etc...are expected to take:

    https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_83_00_18/exports/bios_6_83_00_18/packages/ti/sysbios/benchmarks/doc-files/TI_C28_float_ti_platforms_tms320x28_TMS320F280049M_time.html

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 80 points

    Thanks, I did not know that, that there is a benchmark for SYS/BIOS