RTOS/TM4C1294NCPDT: Timer

Sorry I'm non wiser here.... I have used many internal perpherial for non RTOS from various MCU device. I'm on RTOS platform.

I have several timer perpherial in TMC4C which I going to use a lot for PWM purpose, it going to be managed by a semaphore to reconfigure the timer, suspend or run timer. My concern I do not have any idea what and which timer perpherial the RTOS reserved to.

The Cortex M4 documentation made clear there is only one timer within Cortex M4 which is called Timer or more commonly used Systick or NVIC Systick. Does RTOS actually use this or not?

infocenter.arm.com/.../index.jsp

If RTOS do not use any of the above then pray how it maintain accurate timer, I have looked many documentation and cdoc and oxygen and so on and there no clear black/white answer explaining which timer it actually use.

Why I'm asking this query, because I fear crashing the RTOS if I access to systick module or other timer (ie change number or reset). We have Clock and Timer from RTOS for Tiva based device.

"it manages a single timer that drives the timing mechanisms in the kernel" is too vague as it did not point to which internal hardware (or soft) timer it use.

I appericate more hard answer for this fundamental query.

After further experimenting with XCONG and found this but I cannot edit the setting as it all masked out.

Please tell me how to make use of this, is there example code. I like to arrange to have a continuous 100mSec event to a function in my code, it run forever. It linked to SYSTICK

By the way, what is PIOSC?

First let's get on the same page...

By default, the kernel does not use the SysTick. It uses a general purpose timer.

For your timing needs, you can do

1. Use the ti.sysbios.knl.Clock module to create Clock functions that are called for you. These functions can be periodic (and can be changed) or one-shot. There granularity is limited to the period of the Clock though which is defaulted to 1ms (so a period of 100ms is fine, but you cannot do 2.5ms). Some jitter can occur on the Clock since it can potentially do many things at each tick. So instead of an exact 100ms, it might be 100.12ms.

2. Use the ti.sysbios.hal.Timer module to create dedicated timer. You need to supply a function that is called and all the interrupt management is handled by the kernel.

3. Use the ti.sysbios.family.<device specific>.Timer module. The "hal" timer is a generic interface that meets most customer's needs. The "device specific" allow you to pick a specific timer (e.g. SysTick) and potentially use some features that are not exposed in the generic "hal" interface.

4. Use driverlib calls to set up the timer. Don't use the driverlib's interrupt module to plug the vector table though. This is not compatible with the kernel. You need to use the ti.sysbios.hal.Hwi module to plug the vector table (e.g. Hwi_create). You can look at any of the TI-RTOS drivers to see how they use the Hwi module to manage the interrupt.

Todd

richard payne said:

The Cortex M4 documentation made clear there is only one timer within Cortex M4 which is called Timer or more commonly used Systick or NVIC Systick. Does RTOS actually use this or not?

infocenter.arm.com/.../index.jsp

The above documentation is for the SysTick timer.  SYS/BIOS offers support for this but does not use it by default.  The user is free to use it for their own purposes.  The SYS/BIOS module ti.sysbios.family.arm.m3.Timer provides the implementation of it.  You would explicitly use that module in your .cfg:
    var SysTick = xdc.useModule('ti.sysbios.family.arm.m3.Timer');

The "generic" SYS/BIOS module ti.sysbios.hal.Timer maps to a Timer module that is specific to the part in use.  For TM4C1294NCPDT, it maps to ti.sysbios.family.arm.lm4.Timer, which manages the GP timers on the part.  There are 8 GP timers available.  To clear up any possible confusion of terminology, I'm talking about the timers where timer #0 has a base address of 0x40030000 (named Timer0 for SYS/BIOS), timer #1 has a base address of 0x40031000 (named Timer1 for SYS/BIOS), etc.  SYS/BIOS timer Timer6 skips to base addr 0x400E0000, and Timer7 is 0x400E1000.

The SYS/BIOS module ti.sysbios.knl.Clock uses one of the GP timers.  By default, it will use Timer_ANY and allow ti.sysbios.family.arm.lm4.Timer decide which one.  You can tell Clock to use an explicit Timer, by setting
    Clock.timerId = N;
where N=0-7.

I will provide further details in another post.

Regards,

- Rob

I have latest version CCS 8.0 including RTOS etc and use DelStyle extension under dark theme (dark as Darth Vader) added to it, it help my eye reading and working on code. When I click clock source list box it did not appears and I'm certain DelStyle has nothing to do with this.

richard payne said:

When I click clock source list box it did not appears and I'm certain DelStyle has nothing to do with this.

Can you check your Timer.xml file?

This file is in tirtos_tivac_2_16_00_08/products/bios_6_45_01_29/packages/ti/sysbios/family/arm/lm4.  It is a generated file.  Do you have the following content?:

<page name="Instance" title="Instance Settings" DPI="10">
<html><body><table>
  <tr>
    <td>
      <h1>Timers</h1>
      <table><tr>
        <td><control type="listbox" sort="true" id="master" text="value:this.$activeInstance" width="10" height="15" align="fill" labels="value:this"/></td>
        <td>
          <control type="pushbutton" label="Add ..." align="fill" link="action:New"/>
          <control type="pushbutton" label="Remove" align="fill" link="action:Delete" context="value:widget.master.selection"/>
        </td>
      </tr></table>
    </td>
    <td context="value:widget.master.selection">
      <h1>Required Settings</h1>

If not then the file must have been generated badly.

If you do have that (and I expect you do), then it seems that there's a rendering problem in your GUI.

Is this CCS for Windows or Linux?

What version is your OS?

Regards,

- Rob

richard payne said:

I have latest version CCS 8.0 including RTOS etc

I have just been informed of a GUI issue with XGCONF and CCS 8.x.  Please see this forum thread:

It suggests maximizing your window to work around the problem.

Regards,

- Rob

I'm on latest version Window 10 (with all updates).

Can you advise what additional items via XCONF editor to bypass the GUI issue for time being. I sure they would fix it in next CCS release.

Is there plan for next revision tirtos_tivac_2_16_00_08, TivaWare_C_Series-2.1.4.178 and bios_6_70_01_03, what significant change in context of TM4C device? (I hope they include ADC module :-) ).

Do u mean var SysTick = xdc.useModule('ti.sysbios.family.arm.lm4.Timer'); not arm.m3.Timer....?

The maximising does not fix the issue.

richard payne said:

Do u mean var SysTick = xdc.useModule('ti.sysbios.family.arm.lm4.Timer'); not arm.m3.Timer....?

No, ti.sysbios.family.arm.lm4.Timer supports the GP timers.  ti.sysbios.arm.m3.Timer supports the SysTick timer.

Regards,

- Rob

richard payne said:

The maximising does not fix the issue.

That's unfortunate.

XGCONF ultimately just writes XS code (essentially Javascipt) to the .cfg file.  So a workaround is to write the XS statements yourself into the .cfg file.  I could help with that if you let me know what parameters you want for your lm4 Timer instance.

Another option that you could do yourself - if you have an earlier 7.x CCS then you could use XGCONF there to create the lm4 Timer instance that you like (assuming the windows render properly) and take the resulting generated .cfg script code for the Timer instance from that and paste it into your CCS 8.0 project.  Most likely it will port forward just fine.

Regards,

- Rob

richard payne said:

I'm on latest version Window 10 (with all updates).

I don't think it's related to Windows version, it probably affects the latest Windows 10 too.

richard payne said:

Can you advise what additional items via XCONF editor to bypass the GUI issue for time being. I sure they would fix it in next CCS release.

Just the manual .cfg script editing that I mentioned in my previous post.

You're probably right that it will be fixed in the next CCS release, but it was only found last week and so it's too early to have been dispositioned into a release schedule.

richard payne said:

Is there plan for next revision tirtos_tivac_2_16_00_08, TivaWare_C_Series-2.1.4.178 and bios_6_70_01_03, what significant change in context of TM4C device? (I hope they include ADC module :-) ).

I don't think there will by any TI-RTOS 2.x revisions in the future.  TM4C support ended in TI-RTOS 2.x.  If you want to use later CoreSDKs (rename of TI-RTOS) 3.x then you will have to change to using the MSP432E4 device.

Regards,

- Rob

Robert Tivy said:

I don't think there will by any TI-RTOS 2.x revisions in the future.  TM4C support ended in TI-RTOS 2.x.  If you want to use later CoreSDKs (rename of TI-RTOS) 3.x then you will have to change to using the MSP432E4 device.

We have not officially stated that there will be no new TI-RTOS for TivaC releases. We reassess the need every couple months and, unfortunately, we've had higher priority items. We will continue to reevaluate doing a release. If we do a new release, it will be more of a patch release (e.g. bug fixes, new compiler tools, etc.). If there is a new release, it will most likely not have new feature development. As Rob stated, we are doing new software development on the SimpleLink devices. The CoreSDK is an internal name for the common SDK that all the SimpleLink SDKs are built on. CoreSDKs have their own versioning and are not externally available. It is for internal use only. 

MSP432E4 is a SimpleLink device that is similar device to TM4C129.

Todd

So in future prospect, The MSP432 is going to kill/replace TMC129 series, thus reducing support/update, etc. I wish I should choose MSP432 first place!. It does look very similar between MSP432 and TM4C, why replace it?