MSP432-RTOS: Timestamp_get64 flows over unexpectedly when using clock module's timer

Hi,

Sven Probst said:

Unfortunately, this is only correct if you don't check the "Use Clock's timer" checkbox. If you check this box, the timestamp uses the system clock's timer and the system tick over flow counter, which is uint32_t.

TI-RTOS uses the hardware Timer1 module to generate the ticks for RTOS's Clock Module but uses Timer 2 for Timestamp functions.  I believe when you click "User Clock's Timer" it will combine both services. I think when combined, it only uses Timer1 for both Clock and Timestamp functions. To use the timestamp for 64-bit, I think you should use the Timer2 that is separate from primary Clock Module service.

Below is a description pertaining to C28x MCU but the idea will be the mechanism will be the same for MSP432E. 

TI-RTOS Kernel – Timer and Clock Usage
Shown below is a table noting each timer that is used for each service by default for each architecture as well as other options you have as the user.
Listed down the first column are the services and options you have. Let’s take the C28x as an example:
• Timer 1 is used, by default, for the Clock Module service
• Timer 2 is used, by default, for the Timestamp service
• These two timers are NOT combined by default – so if you add both services to your app.cfg file, you will be consuming two hardware timers
• Users can combine both services on one timer if needed – but note that the Timestamp APIs will take longer to execute in this combined mode

Sven Probst said:

By the way, could you provide a link to the documentation of Timestamp_get64 and its configuration options specifically for the MSP432E implementation

https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/6_76_04_02/exports/bios_6_76_04_02/docs/cdoc/xdc/runtime/Timestamp.html

Hi Charles,

Charles Tsai said:

TI-RTOS uses the hardware Timer1 module to generate the ticks for RTOS's Clock Module but uses Timer 2 for Timestamp functions.  I believe when you click "User Clock's Timer" it will combine both services. I think when combined, it only uses Timer1 for both Clock and Timestamp functions. To use the timestamp for 64-bit, I think you should use the Timer2 that is separate from primary Clock Module service.

sorry, that was not my point (by the way, in my humble opinion, with MSP432E indexing starts at 0, so Timer0 and Timer1).
I just wanted to point out that there is no information anywhere that Timestamp_get64 behaves so differently (4874 years vs. 49 days) when you check "Use Clock's timer".
It would be fair to either change the implementation so that the behavior is almost the same, or at least provide a hint about the different behavior.
Could you forward this request to the engeneering team?

Charles Tsai said:

software-dl.ti.com/.../quote]

I think, this is the general description, but not MSP432E specific. In the installation directory I found some more specific information in the meantime:
file:///C:/ti/simplelink_msp432e4_sdk_4_20_00_12/docs/tirtos/sysbios/docs/cdoc/ti/sysbios/family/arm/msp432/TimestampProvider.html
However, this information still lacks implementation details.

Hi,

Sven Probst said:

sorry, that was not my point (by the way, in my humble opinion, with MSP432E indexing starts at 0, so Timer0 and Timer1).

Ok, you may be right. I just open a CCS register browser window while running a very basic MSP432E RTOS example and Timer0 module is used for generating RTOS ticks. The timer load value is about 120000 which is 1ms by default. 

Sven Probst said:

It would be fair to either change the implementation so that the behavior is almost the same, or at least provide a hint about the different behavior.
Could you forward this request to the engeneering team?

Sorry, TI-RTOS is in long term maintenance. There is no plan for any update to TI-RTOS. 

Hi Charles,

Charles Tsai said:

There is no plan for any update to TI-RTOS. 

What does this mean? Is TI-RTOS becoming obsolete?

What is TI's recommendation for new projects?

Kind regards,

Sven Probst.