• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 1865 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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/MSP432P401R: Changing Clock Source for User Timer (Easy Way?) in TI-RTOS on MSP432

Chris Yorkey
Genius 15295 points

Part Number: MSP432P401R

Tool/software: TI-RTOS

MSP/RTOS Team,

Our customer is seeing a timing inaccuracy with the MSP432 and the TI-RTOS.  (Posting in this Forum since the TI-RTOS Forum is READ ONLY)

It looks like based on digging through the TI-RTOS docs ,that the 32KHz clock is being setup with a period of 32 for the tick timer.  However when I create a clock on top of that that fires ever 100 ticks.  I get a routine delay of 97.5 ms.  When I set the timer to 1000 ticks I get a delay of 974 ms.  So it looks like the clocks are not being setup properly, although it looks like they are, but the system is not keeping time properly. 

Per Scott, what we are observing is a limitation of trying to get a clean 1 msec tick from a clock source running at 32768Hz.  To get a precise 1 msec tick would require programming the timer to generate an interrupt on every 32.768 counts.  But the timer only supports programming integer counts so the 32.768 gets truncated to 32.  (By convention, if we can’t get the precise tick rate we will interrupt early rather than late.)  So every tick will occur at 32/32768 = 0.9765625 msec.    So for 100 consecutive ticks the overall delay will be ~97.7 msec;  for 1000 it will be 977 msec, etc.  The numbers we report above don’t match exactly but this may have to do with measurement accuracy.  We suggested other ways to handle this;  reducing the tick rate, using a different timer such as SYSTICK, calculating the total # of ticks to wait a particular delay and/or using a suppression feature which might be a little more complicated.

However, much to no avail, we need further insight.  There does not appear to be anything to change the clock source directly.  Everything seems to direct to create a user based timer and call Clock_tick by the user.  However that isn’t working either because when it is configured to use a user timer according to instructions - a build error results that ti_sysbios_family_arm_msp432_ClockFreqs_setFrequency_E is missing or uninitialized.

 ti_sysbios_family_arm_msp432_ClockFreqs_setFrequency_E --- can’t figure out where this is referenced, or get an idea of what it should be set to.  We find it hard to believe that you can’t change the clock source for the tick timer somewhere.  Probably just not finding it readily available.  Finding references that it is not possible and to do it another way.  Which apparently is blocked or not clearly enough documented to figure it out quickly.

When using SMCLK for a timer that is created, it should be 12 MHz according to the spec.  which should have a nice easy division to a 1ms timing but it results in ~994 usec.  Which doesn’t make sense if the system is running off the 48 MHz crystal divided down.  It seems to have some slop too so the worry is that it is off a PLL from the 32KHz crystal.  Which would not be the desire for the system configured--- but I can’t figure out where that is configured either.  It is buried so deep in indirect links within the BIOS it seems tough to get there.

 Any help you can provide would be appreciated.  Thanks team.

TY,
CY

  • 0
    TI__Mastermind 26780 points

    Chris Yorkey said:

    Everything seems to direct to create a user based timer and call Clock_tick by the user.  However that isn’t working either because when it is configured to use a user timer according to instructions - a build error results that ti_sysbios_family_arm_msp432_ClockFreqs_setFrequency_E is missing or uninitialized.

    Can you describe what you did to get this error?

    Chris Yorkey said:

    When using SMCLK for a timer that is created, it should be 12 MHz according to the spec.  which should have a nice easy division to a 1ms timing but it results in ~994 usec.  Which doesn’t make sense if the system is running off the 48 MHz crystal divided down.  It seems to have some slop too so the worry is that it is off a PLL from the 32KHz crystal.  Which would not be the desire for the system configured--- but I can’t figure out where that is configured either.

    How have you configured SMCLK? With custom code, maybe in main()? Or are you letting the Boot module configure this, or are you using the Power driver? The defaults for the Boot module and Power driver are to source SMCLK off of the DCO. So if you are using these defaults then the rate won’t be as accurate versus a high frequency crystal.

    Can you clarify if you are using TI-RTOS, or just the kernel, and which versions?

    Thanks,
    Scott

  • 0 in reply to ScottG
    TI__Genius 15295 points

    Scott,

    They get that error code after they change the settings for the clock module for the application code to call Clock_tick as was instructed in several WIKI on the TI website to get a more stable clock.

    SMCLK is configured by the defaults of the boot power module.  But they have not made any changes, nor can find documentation to figure out where to make changes.  There are a lot of buttons for configuration items that don’t seem to go anywhere.  It has been somewhat frustrating for them.

    As for the TI-RTOS version....they started with the uartlogging example project for the msp432 inside of the Simplelink_msp432p4_sdk_2_20_00_12 which was the latest version they could find.  It is what is listed under the Resource Explorer.  There is no independent TI-RTOS download for the MSP432P4111 Launchpad like there is for the SensorTag.  

    As near as can be told, there does not appear to be any commonality or clarity to what resources are provided for each launchpad, or even labeled.  For example SensorTag had an empty example TI-RTOS project which is a good place to start.  This one did not, so the user started with the only UART project could find because they actually wanted to use a UART to send some data.  Unfortunately it turned out to be a kernel logging project and not a UART communication project.  So they had to disable the logging in the cfg file then could use the UART.  So even I am no sure what the root version is.  It is also using the xdctools version 3.50.07.20 according to the project settings.

    Any help you can provide would be appreciated.  Thanks again.

    TY,
    CY

  • 0 in reply to Chris Yorkey
    TI__Mastermind 26780 points

    Chris,

    Where did you get that screen shot of the Clock module configuration?  It mismatches what I would expect for the SDK you indicate.  Is that from a wiki page or are you seeing this in your install?  I tried to recreate the build error reported but am still not clear on what exact steps led to this.  It would help if you can send me the .cfg file for the case where the ClockFreqs build error was thrown.

    Also, are you using MSP432P4111 as implied in your latest post, or MSP432P401R as in the thread subject?  I ask because the Boot module for MSP432P4111 does not have support for initializing clocks at boot. (The Boot module for MSP432P401R does.  There are reasons for this difference that I won’t detail now.)  For MSP432P4111 there is support for configuring clocks in the Power driver.  If you want to use the Power driver to configure this you will need to create a custom performance level.  

    You can find some documentation for creating custom performance levels by opening the Driver API descriptions: open tidriverAPIs.html, it should be in the install at this location: C:\ti\simplelink_msp432p4_sdk_2_20_00_12\docs\tidrivers\tidriverAPIs.html.   Click on the PowerMSP432.h header file, then on the PowerMSP432_PerfLevel structure.  The page this opens describes the elements of a performance level structure, and shows an example of defining a couple of custom perf level structures to the board file.  To have SMCLK source off of the HF crystal you need to specify  “.SELS = CS_HFXTCLK_SELECT” as shown in myPerfLevels[0].  

    Here is another E2E post that describes creating a custom perf level, and selecting it as the default on boot: e2e.ti.com/.../2220428

    As far as available TI-RTOS examples, there should be an empty example here: C:\ti\simplelink_msp432p4_sdk_2_20_00_12\examples\rtos\MSP_EXP432P4111\drivers  There is also a uartecho example in this same directory that is probably a better starting place.  I think maybe you were looking under the ‘sysbios’ example directory: C:\ti\simplelink_msp432p4_sdk_2_20_00_12\examples\rtos\MSP_EXP432P4111\sysbios  where the uartlogging example is.

    Regards,
    Scott

  • 0 in reply to ScottG
    TI__Guru 57566 points
    Please feel free to add more comments/replies/questions if this is not resolved.

    Chris
  • 0 in reply to Chris Sterzik
    TI__Genius 15295 points
    Hi Chris,
    Thanks for that offer. We are at an acceptable status right now with this customer. In the end, it was partly new-user, combined with the complex nature of RTOS and kernels and such. We did make an offer to provide a follow-up continued conversation, once the customer is ready. For now they are good to go but they might take us up on that at some point in the near future. Stay tuned & thanks for everyone's support.

    -Chris

**Attention** This is a public forum