• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 551 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/EK-TM4C1294XL: Clock mode to 'Dynamic' results in MCU crash.

Johnathan Sutter
Prodigy 30 points
Part Number: EK-TM4C1294XL

Tool/software: TI-RTOS

Hello,

My application's primary goal is to read a group of SPI sensors at a high sampling rate for a few milliseconds and make a decision on this data.

I've implemented this in a task posted by a hardware interrupt and in general my sensor read loop runs at ~15uSec per scan.

As my overall sensor read duration (10mS) is longer than my clock tick period, the clock module interrupts which adds ~35uS (every clock tick or 1mS by default)


If I set the Tick mode to 'Unnecessary time ticks will be suppressed' my application works briefly, but the MCU stops working after a short time.

-I don't see a stack overflows in HWI or TASK

-No exceptions to any HWIs

-HeapTrack didn't show any issues

Execution analysis shows that the program dives off into 'unknown'. The closest hint I've seen is a pause of the program where a semaphore count overflow looked to have happened, the semaphore counts are at 0 or 1 in ROV. Sometimes in the ROV window the BIOS tab 'Scan for errors' will show, 
    'Caught exception in view init code: "C:/ti/tirtos_tivac_2_16_00_08/products/uia_2_00_05_50/packages/ti/uia/loggers/LoggerStopMode.xs", line 231: Cannot read property "enabled" from null'.

How should I troubleshoot this sort of error? Sys/Bios for MSP430 processor/wiki has the most info on clock tick suppression I've found and seems to indicate that the longest a tick could be suppressed is < 1 tick duration? This issue happens in the 'empty' TI-RTOS new project if I set the clock tick mode to dynamic there as well.

Using 'Clock_tickStop();' and 'Clock_tickStart();' didn't work when I first tried, but with a reinstall of CCS they seem to do the trick now. Are there caveats to their use? Is there a limit to ticks ignored, if so is it cumulative?  Should I be trying to increase my tick duration and only capture data between ticks, or am I fundamentally off in my approach in another way?

I apologize for stupid questions and other newbie mistakes, thank you for your time.

RTOS: 2.16.0.08
XDCtools: 3.32.0.06

  • 0
    TI__Expert 4440 points
    Hi Johnathan,

    I am working to reproduce your issue locally using the "empty" example from TIRTOS 2.16.00.08. I will follow up as I debug the issue.

    Derrick
  • 0 in reply to Darius Williams
    Prodigy 30 points

    Thank you Derrick,
      Forgot to include that in the 'empty' RTOS example it seems the MCU stops running the heartbeat function at roughly the same time as 2^32 of the CPU (120MHz clock) periods. Or ~35.8 seconds.
    Johnathan

  • 0 in reply to Johnathan Sutter
    TI__Expert 4440 points
    Johnathan,

    It turns out that the Dynamic Tick Mode is not supported on the TIVA platform.

    Are the clock ticks occurring during your 10mS sensor read period affecting the validity of your data (ie you have a hard deadline)?

    Derrick
  • 0 in reply to Darius Williams
    Prodigy 30 points
    Thank you Derrick,
    Yes the additional timing of the clock tick won't work in our application. As I see it our options would be;

    1) Set a clock tick period >10mS and ensure our read period is contained between ticks. This wouldn't significantly detract from this project, but would make it harder to sell the system internally for other projects.

    2) Keep using the 'Clock_tickStop();' and 'Clock_tickStart();' at the beginning and end of the read period, I am unsure if this is recommended or robust at this point.

    3) Try to use a zero latency interrupts (this scares us to mix and match).

    4) Abandon the RTOS.

    We are also using the NDK for communications that are non time critical. The RTOS has been awesome and we would prefer to continue with this path. Could you comment on option 2 specifically, and any other suggestions are welcome and appreciated.

    Thank you again,
    Johnathan

    P.S. Low priority, but when the clock_tick mode dynamic error occurred, is there a way I could have better troubleshot the error?
  • 0 in reply to Johnathan Sutter
    TI__Guru* 96960 points
    Hi Johnathan,

    How are you accessing the SPI peripheral for your multiple ms read? Are you using TI-RTOS drivers or just using driverlib? If you are using driverlib, are you using interrupts or just polling the SPI peripheral?

    If you are just polling, another thought would to just disable interrupts. It's a little heavy handed, but easy and fast. I think the clock tick will self correct (e.g. if you delay 3 ticks, the timer peripheral will run 3 times immediately after you enable interrupts). This is all just thinking out loud and needs some more thought though...I'll leave it to Derrick :)

    Todd
  • 0 in reply to Johnathan Sutter
    TI__Expert 4440 points
    Johnathan,

    Before moving forward with option [2], I was interested in your response to Todd's latest comment. I think his suggestion of disabling interrupts would be best. You can achieve this using the Hwi module. (Hwi_disable() and Hwi_restore() functions).

    If that is not an option for you, I think we should investigate starting and stopping the clock tick.

    Derrick
  • 0 in reply to Darius Williams
    TI__Guru* 96960 points
    Johnathan,

    Can I mark this thread as resolved?

    Todd