RT1064, Systick configuration. - Page 1
Forum section: electronics / general

author: luiHS
author_rank: Frequent Contributor
timestamp: December 14, 2022, 03:25:41 am
content: Hello.I'm migrating projects from Kinetis MK66 to RT1064, one of the things I need to use is the Systick to count times in my own millis() routine, configuring the Systick for a 1ms interrupt.I've opened some of the sample programs that MCUXpresso comes with, which use Systick, and are theoretically set to 1ms. The problem is that the calculation that the source code does doesn't seem right to me.Here the Systick configuration:/* Set systick reload value to generate 1ms interrupt */SysTick_Config(SystemCoreClock / 1000U);The problem is that if I look at the value ofSystemCoreClock, it points to theDEFAULT_SYSTEM_CLOCKconstant, and this constant has an assigned value of528000000#define DEFAULT_SYSTEM_CLOCK 528000000UL /* Default System clock value */uint32_t SystemCoreClock = DEFAULT_SYSTEM_CLOCK;The microcontroller works at 600Mhz, the project is built for that oscillator frequency, I have checked. So I don't understandwhy we get 1ms by dividing 528000000 by 1000, I think the correct thing would be to divide 600000000 by 1000 to get 1ms in the Systick interrupt. I've checked several sample MCUXpresso sources, the ones that use Systick for the RT1064 on the eval board and they're all the same. This evaluation board installs a 600Mhz RT1064 with a 24Mhz crystal.

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 14, 2022, 04:07:57 am
content: It's just the initialization value, that variable will be updated by SystemCoreClockUpdate() function when the clock is configured at runtime, you can see that by debuging the code, watching the variable before/after the clock setup.

author: bson
author_rank: Unknown
timestamp: December 21, 2022, 04:10:24 pm
content: Another reason not to use these libraries. You know what clock you're going to run at, it's not going to change, it's entirely constant, and should be configured up front, once, using constant values. All this silly dynamic clock changing and global variable business needs to be designed such that it all gets inlined and optimized to a few store instructions. All this configuration complexity offers nothing of value but adds a ridiculous amount of stuff that can mysteriously fail.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 21, 2022, 08:01:30 pm
content: Quote from: bson on December 21, 2022, 04:10:24 pmPretty opinionated.Changing the clock dynamically at run-time can actually be pretty useful, if just to save power depending on conditions, or for some other reason.Clock is not going to change, and 640KB ought to be enough for anybody. Right?

author: bson
author_rank: Unknown
timestamp: December 25, 2022, 01:34:55 am
content: Quote from: SiliconWizard on December 21, 2022, 08:01:30 pmYou could still change clock. Only it will be between multiple well-known quantities, each of which will inline and optimize to a few instructions.

author: DavidAlfa
author_rank: Super Contributor
timestamp: December 25, 2022, 02:20:45 am
content: Quote from: bson on December 21, 2022, 04:10:24 pmLib-less projects is ok with simple MCUs like AVR or PIC, rest is just old dog barking.Doing so with those extremely complex ARM devices is up to you, but will take weeks...months to fully develop, and you'll be mostly reinventing the wheel, introducing bugs, or skipping workarounds for erratas you're not aware of.Might not be as fast as baremetal solution, but answer is simple, do you really need it?Perhabs it's mostly you want it to take it to take ages to maintain your monthly income?Otherwise it's just the same over-engineering madness seen everywhere."Hell, that will take 5 us longer than my custom code!"(Which I'll need to modify again for any other project because it's extremely application-specific).

author: cgroen
author_rank: Unknown
timestamp: December 25, 2022, 06:09:03 pm
content: Quote from: DavidAlfa on December 25, 2022, 02:20:45 amOh yes, compltely agreeI would love to see someone do the complete implementation of the peripherals of the RT106x (or the RT117x for the brave) from scratch

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 25, 2022, 07:47:48 pm
content: Quote from: cgroen on December 25, 2022, 06:09:03 pmI'd be curious to see that as well.

author: mblinov
author_rank: Contributor
timestamp: February 02, 2023, 10:20:50 am
content: I'm not sure if this is exactly the same thing, but I experienced similar confusion regarding system clocks with the NXP software:https://www.eevblog.com/forum/microcontrollers/nxp-rt1020-corrupted-swo-printf-output-(mcuxpresso-j-link)/msg3938800/#msg3938800