FTM Timestamp and Steptick

[Sam_ECU]

Hello @mariuslucianand 

I have a FTM within my application and until now the model was set to run using one step size.  Due to the model requirements it as been converted to operate with multitasking.  This change has altered the values within the generated timestamp which I can't explain.

Could you or a colleague please help.  Attached are the models which generate the conflicting data.

When the model operates with multitasking and the FTM-Block is polled at either 0.0001 or 0.00001s, it generates the data below:

When the model is operating in single task operation at 0.0001:

And in single task operation at 0.00001:

Analysis has shown that the generated signal for the FTM is correct.  The timing between the output and the FTM-Timestamp align, but the values don't correlate.

[Sam_ECU]

As an additional point, I'm expecting to measure ~875 Ticks:

[mariuslucianand]

Hello @Sam_ECU,

I had a look at your model, and I have some comments.

First of all, I strongly suggest you have a look at the below threads, touching on some subjects related to both profiling and how the generated code works.

https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/MBDT-blocks-for-measuring-Idle-Time-or-... 

https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/S32k144-Simulation-Time/m-p/1196373#M54... 

As a note here, the actual frequency of the timer used by the Profiler is 20MHz (PLL/4) for the main clock of 80 MHz. To translate the output into seconds, you have to multiply with 1/20M.

If you measure a delay in your generated signals for tooth outputt, for example, 0.4ms instead of 0.2ms, then this means that the step function takes more than you set as the "Sample time". If you have a task executing 0.1ms and the fundamental sample time is 0.01ms, then every 10 steps it will execute that task. The second link above touches also on this subject.

What might relate to that is the fact that in both of the models, the core clock in the Config block is 112MHz. Actually, this makes the MCU run in HSRUN power mode, which of course boosts the frequency, but also comes with some limitations detailed in the Reference Manual. But, next to the config block, there is PMC block, which sets the core back to RUN mode, so the entire time, the MCU is running at 80 MHz. So my suggestion is to remove the PMC block, and also select the 80Mhz clock value in the Config block. Please do so, and redo the tests.

Hope this helps,
Marius

[Sam_ECU]

Hello @mariuslucianand ,

Sorry for the slow reply.  Your input was extremely helpful, especially the post from " constantinrazva".  Unfortunately I'm limited to profiling the code as I have more then 15 Triggered Subsystems in the project (limited by the number of profile blocks).

I found that a profile block at the base level and then reviewing the loads against the timing from the triggered subsystem worked best.

The PMC block was the original issue.  I was using it after reviewing the PMC-Example in MBDT.  Within the example HSRUN was being "triggered" by the Run-Mode and my assumption was, that it was therefore being defined in the S32 Config Block.  Something to consider for a future update.

Regards,

Sam