I've asked a previous question about ADC timing that hasn't been answered yet but maybe I should back up and make sure I'm understanding the foundation of how the timing for the system works when using the NXP Simulink Toolbox. Previously I've used Simulink Toolboxes from other companies that had a timing block that was rock solid and could be used with timing-critical safety applications without a second thought.
What I think is true:
Channel 0 of the LPIT (periodic interrupt timer) is used to control the Step Tick of the Simulink model.
Setting the priority to 0 ensures that the Step Tick will be the most prioritized function in order to maintain precise timing.
I have no idea what anything else in the Config Parameters section does.
What I'm unsure of:
How fast can the Step Tick be when using 8MHz crystal and 80MHz system clock?
How accurate is the LPIT when using the S32K144EVB?
Can LPIT be trusted with safety-critical timing?
Does temperature have a large effect on accuracy?
Why when I change from .01 to .001 step tick I get a speed increase of 10x but when I change from .001 to .0001 I get no change?
If anyone could get me moving in the right direction, I would appreciate it.
Thank you.
Hello sparkee,
So regarding the ADC question, my colleague mariuslucianandrei has prepared a model for you and will respond on that topic. As far as the questions regarding the LPIT, let me take them in order:
You are right, setting the priority to 0 will make the LPIT ISR the most prioritized interrupt (good for the IRQ handling the main loop timing).
When it comes to LPIT clocking, it uses as a source the SPLL (system PLL) - notably the SPLL div2. If you were to track the clocking schema we use (the default clocking you get in our toolbox - although you can use a custom clocking setup that you can generate using Processor Expert from the S32 Design Studio), the SPLL is set to 80MHz, so the LPIT will have it's clock source set to 40MHz (the functional clock). The module clock will be the BUS clock, also set at 40MHz. Having this in mind, you can get to LPIT events being triggered much faster than you can probably use (being periodically generated, you should execute code in between 2 such even triggers - if this window is very narrow, you can't run so many instructions); so you can't get to 25ns interrupt generation. You have to keep in mind that first of all you need some time for context switching (state saving code / state restoring code that is ran in the ISR epilogue / prologue). If that is not the only interrupt running, you should account for others as well. Furthermore, you should profile the code that is ran inside the ISR to get the minimum size of the window between 2 such interrupts - but make sure to use a value that is higher than this if you are also using other interrupts in your application.
I'm not sure how you tested your application, but a simple way to see how the step size is affecting the runtime, you can put a simple GPO (gpio output) block and toggle it in the main loop. Here are some screenshots of mariuslucianandrei's examples, with various periods used (note that the value you see in the measurement is double of the step size used, as the periodical signal is comprised of 2 states, so 2 PIT triggered events). That being said, you can see examples of 100us and 5us LPIT periods.
As for these questions:
Can LPIT be trusted with safety-critical timing?
Does temperature have a large effect on accuracy?
I'm not sure - you can either read the S32K144 datasheet and reference manual and if the data you find there is not compelling enough, you can open a ticket to NXP support specifically with these questions.
As far as the question with the 10x speedup, I think the problem was how the testing was done (which was unclear). If you do the simple test with a GPO block, you should find similar results to the ones posted above. If you were testing using the ADC (as in your other post) - that was used in hardware triggering mode, so it has no link to the LPIT controlling the main loop / step function. This is the reason why you were not seeing any difference. If you were testing in another way, it must have been something independent of the main loop triggering.
If you have questions about what I wrote here or any other questions, please do not hesitate to ask them. We are part of the development team and we try to answer you as quick as we can (although sometimes we get caught up in our daily work and can't reply the same day).
Kind regards,
Razvan.
