RTOS/MSP432P401R: Confused by Timer Module using SYSTICK

Julian,

In your config script, I see that you have enabled logging. The logger requires a timestamp; so, it pulls in this module. The timestamp module requires a timestamp provider. By default, it will use the one from the ti.sysbios.family.arm.m3 package. Finally, the timestamp provider needs a timer; it uses the timer from the same package which uses the SysTick peripheral.

LoggingSetup                    (ti.uia.sysbios)
+-- LoggerStopMode              (ti.uia.loggers)
    +-- Timestamp               (xdc.runtime)
        +-- TimestampProvider   (ti.sysbios.family.arm.m3)
            +-- Timer           (ti.sysbios.family.arm.m3)
                +-- SysTick     (peripheral)

However, if you configure the timestamp provider yourself, then it will be used in preference. There are two ways to do this. You can tell the timestamp provider to use the same timer used by the BIOS Clock module, or you can use a dedicated timer.

/* use same timer as BIOS Clock */
var Timestamp = xdc.useModule('xdc.runtime.Timestamp');
var TimestampProvider = xdc.useModule('ti.sysbios.family.arm.msp432.TimestampProvider');

TimestampProvider.useClockTimer = true;
Timestamp.SupportProxy = TimestampProvider;

The bummer here is that this timer runs slow; 32768Hz. You will notice that your timestamp in the log events ticks slowly. But you can use a dedicated timer and driver it with the SMCLK which runs at 12MHz to get a high-resolution timestamp.

If you take this approach, you must be careful not to use a timer which is reserved by the TI-RTOS drivers. For example, I used the PWM driver example to debug this issue. In the board file (MSP_EXP432P401R.c) of this example, it is using Timer_A1. You must remove this timer from the available timer mask.

/* PWM is using Timer_A1, remove it from the available timers mask */
var ti_sysbios_family_arm_msp432_Timer = xdc.useModule('ti.sysbios.family.arm.msp432.Timer');
ti_sysbios_family_arm_msp432_Timer.anyMask = 0xd;

/* use a dedicated timer with 12MHz input clock */
var Timestamp = xdc.useModule('xdc.runtime.Timestamp');
var TimestampProvider = xdc.useModule('ti.sysbios.family.arm.msp432.TimestampProvider');

TimestampProvider.useClockTimer = false;
TimestampProvider.clockSource = TimestampProvider.Source_SMCLK;
Timestamp.SupportProxy = TimestampProvider;

Now you have a high-resolution timestamp in your log events. But the bummer here is that the timer, which has only a 16-bit counter, will roll over every 5.5 ms. This causes an interrupt to fire. This could have a negative impact on battery life.

It might be possible to slow down the timer to minimize power consumption. You would use the Timer module to create an instance and specify the input divider: Timer.ID_8. This would increase the rollover period to about 44 ms. Specify the actual timer ID in your timestamp provider. I've not tried this.

I have attached my project which is using your config script. Change the if-statement to switch between the two timers. Look at the end of the config script (Julian.cfg).

4011.pwmled_logging.zip

BTW, when using ROV to inspect the Timer module, the Device Name is incorrect. Use the Device Id and the Device Address to cross reference the actual timer. I have reported this issue.

~Ramsey

Julian,

You are correct. In the XGCONF editor, there is no indicator of how the logger, timestamp, and timestamp provider modules are connected. This is unfortunate and unlikely to improve. The configuration model is very rich in features, and it is very difficult to express this in a GUI. In these situations, you will have to use the script text editor and ROV to fully configure the model.

Here are some tips which might help.

In ROV, select the Clock module. Click on the Module tab. Note the timerHandle value, 0x20001b80 in my case. This does not tell you which timer module it is using, but the handle will always be unique at the system level. If you inspect the two timer modules, you will see the above address is owned by the ti.sysbios.family.arm.msp432.Timer module. Use the address column.

You can also look at the Clock's Raw tab. Open up the following property:

Clock > Raw
Configuration > TimerProxy
$name = ti.sysbios.family.arm.msp432.Timer

This confirms that the Clock module is using the MSP432 Timer module.

A similar technique can be used to track down the timestamp source. Start by looking at the Timestamp module.

xdc.runtime.Timestamp > Raw
Configuration > SupportProxy
$name = ti.sysbios.family.arm.m3.TimestampProvider

If you happen to have more than one TimestampProvider in your system, this will tell you which one is actually being used.

Now inspect the TimestampProvider to determine which tick source is in use.

ti.sysbios.family.arm.m3.TimestampProvider > Raw
Module State
timer = 0x20001d28

Use the timer address to determine which module owns it. In my example, it is the ti.sysbios.family.arm.m3.Timer module. Inspecting this module indicates that the actual timer source is the SysTick peripheral.

ti.sysbios.family.arm.m3.Timer > Device
device = SysTick
devAddr = 0xe000e010

So, in this example, the SysTick is used for the logging timestamp and Timer_A0 is used for the BIOS Clock. I realize this requires knowledge of how the modules are implemented. I would not expect the community members to know this. But its the best I can offer at this time.

~Ramsey