• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 1556 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.

RTOS/TM4C1294NCPDT: Swi posted, but not running

Milan Milinkovic
Prodigy 50 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL, SYSBIOS

Tool/software: TI-RTOS

Dear All,

I have simple configuration where one GPIO interrupt occurs when all three SPI ADCs (connected to three different SSIs) have their data ready. The GPIO interrupt is handled via Hwi which reads the data from the ADCs and then posts a Swi. There is also a small Clock function (3us) called every 50ms. The project is based on TI-RTOS Examples >> EK-TM4C1294XL Evaluation Kit >> Driver Examples >> TI Driver Examples >> Empty Examples >> Empty Project.

The Swi is properly posted and executed every time for a few seconds and then it just stops executing, while the ROV always shows it was posted (never shows idle after the fault). That is one scenario. The other is, it runs for a few seconds and then crashes:

ti.sysbios.family.arm.m3.Hwi: line 1095: E_hardFault: FORCED
ti.sysbios.family.arm.m3.Hwi: line 1207: E_usageFault: INVPC: Invalid PC
Exception occurred in background thread at PC = 0x00000000.
Core 0: Exception occurred in ThreadType_Task.
Task name: {unknown-instance-name}, handle: 0x20002bf4.
Task stack base: 0x20003000.
Task stack size: 0x800.

If I don't use the Clock functions the first scenario never happens, only the second one (in other words, it crashes every time).

The system stack is 1024, so I believe, there is no overflow.

Idle stack is 2048, far above the peak stack usage (I checked in Hwi section of ROV).

LoggerStopMode reports no address (address N/A). Maybe that tells me something...

One interesting thing is that when I post the Swi from the Clock function (which is semantically incorrect), everything works fine. The Swi only blocks when posted from the Hwi, but Hwi continues to run as usual.

I would appreciate any help.

Thanks in advance,

Milan

  • 0
    TI__Guru**** 191486 points

    Hi,

     I have some questions and comments.

    • What is your clock tick rate? Is it 3uS or 50mS? I'm not clear as to what you meant about the 3uS. 
    • You said 'The GPIO interrupt is handled via Hwi which reads the data from the ADCs and then posts a Swi' .Did you try to process the ADC data within the GPIO Hwi? Or in the GPIO Hwi you will post Swi to process the ADC data. The recommended way will be to post the Swi from the Hwi and let the Swi process the ADC data. Please note that Hwi will have higher priority than Swi and if you spend too much time in the Hwi then the Swi will not have a chance to be processed especially if the GPIO interrupt comes very fast. 
    • How fast if your GPIO interrupt?
    • Your statement seems to suggest that you process the ADC data in the Hwi and then post a Swi. What does this Swi do?
    • The clock function is also a Swi event. Depending on the priority you setup then it may preempt the Swi that you called in the GPIO Hwi. So check your Swi priority. 

      I feel that the problem you are having has something to do with the priority of the Swi and how long and what you are doing inside the Hwi. 

  • 0 in reply to Charles Tsai
    Prodigy 50 points
    Hi, Charles,
    Thanks for reply.

    - Thick rate is 1ms and Clock function which lasts 3us is called every 50ms (with 50ms initial delay). Priority 14.
    - If I process everything inside the Hwi it works, but I believe that's not the point. As I learned from the Eric's online workshop and as you also suggested I just read all the samples within the Hwi (which takes about 20us, priority 15) and then process it in Swi (priority 15) (which takes about 60us). My sample rate is 5kHz (I also tried with lower values), so there is enough time to process everything. I tried with different (lower) priorities for the Hwi and Swi, but there was no effect.
    So, I could put everything inside the Hwi and get away with it, but this is so essential (posting a swi from inside the hwi)...
    I'm not sure if it helps, but the following modules are enabled (without instances): Defaults, Diags, Error, Idle, Log, LoggingSetup, Main, Memory, Program, SysMin, System, Task, Text. With instances: CLock, Hwi, Swi.

    Regards,
    Milan
  • 0 in reply to Milan Milinkovic
    Prodigy 50 points
    I also tried different compilers. I get the same result (BIOS exits or Swi posted but not executed), but I don't get these warnings with all compilers:
    "warning "112-D: statement is unreachable" (ti_rtos_pem4f.c file). I get this message with the compiler v17.9.0.STS, but not with v15.9.0.STS, v5.2.6 or v5.2.5.
    My TI-RTOS for TivaC version is 2.16.1.14 and XDC version is 3.32.0.06_core.
  • 0 in reply to Milan Milinkovic
    TI__Guru* 96960 points
    Hi Milan,

    Take a look at this presentation: training.ti.com/debugging-common-application-issues-ti-rtos Hopefully it will give you some clues on what is happening.

    Take a look at ROV->Hwi->Basic and Module to confirm you did not make a zero-latency interrupt by accident. Zero-latency interrupts cannot call kernel APIs (e.g. Swi_post).

    For the case where the Swi is posted but does not run...what is running?

    Todd
  • 0 in reply to ToddMullanix
    Prodigy 50 points
    Dear Todd,

    That was it! My Hwi was type of Zero Latency and the priority value of 14 (which I set) shouldn’t be allowed anyway. But... I don't understand why is any priority number other than -1 treated as Zero Latency. In Eric's workshop (21:20) he says he uses priority group 7 (for Tiva M4) which is the same as setting the priority value to -1. This doesn’t seem to be right, because when I set the priority to 7 it's still Zero Latency and only -1 sets the Hwi to be the type of Dispatched. This also implies that there is no Hwi nesting supported by BIOS (if every Dispatched Hwi has the same priority) which certainly shouldn’t be true... There is also a guide how to set non-BIOS interrupts (TI_RTOS_Kernel_Workshop_Student_Guide_rev4.00, page 5-15) and it says (for Tiva users) I have to put both keyword interrupt and Interrupt priority to zero in order to achive this from configuration GUI. So, I guess there is some other setting I missed? I would appreciate some further clarification on this topic.

    Thank you for your support!
    Best regards,
    Milan
  • 0 in reply to Milan Milinkovic
    Prodigy 50 points
    OK, now it's all clear. I took a closer look at the lecture and I realized I shouldn't have written number 7 in Interrupt priority field (Hwi instace configuration), but 7<<5 (or 0xE0 or 224). Now it's Dispatched again.

    Regards,
    Milan
  • 0 in reply to Milan Milinkovic
    TI__Guru**** 191486 points
    Yes, the priority needs to be left-justified with the 8 bit field. 0x0-0x1F are considered zero latency.