Internal vs. External Timers

[andrewweiss]

Hello!   I'm attempting to execute some basic code using the S32k (s32k142 variant) internal timer, instead of the external.   The prototype custom board I'm working with is not populated with an 8MHz or 40MHz external timer crystal, and the software configuration is not an option to 'deselect' either option (8 or 40).  

Is there a way to execute the application software without using the XTAL pins?  

Thanks for the help, 

Andy

[constantinrazva]

Hello andrewweiss‌,

Firstly, please download our latest release (S32K14x 2018.R1) - available here .

Secondly, regarding the clock options - in the new toolbox you will find them in the main configuration block - MBDTBX_EC_S32K14, under the MCU tab. As you can see in the image below, you have 2 options available: Clock Frequency and XTAL Frequency.

I will briefly present the 2 options: 

• XTAL Frequency - the one that you were having issues with - I must mention that we only use the Internal oscillator for OSC. There might be some ambiguity with the word "External" before the frequency. Let me try and make it a bit more clear:

Starting from the beginning - the internal oscillator (XTAL) has 2 options available: 8MHz and 40MHz. We have EREFS set to 1 (hard-coded), so the System OSC is always XTAL - basically 8MHz or 40MHz set in XTAL Frequency option. As we go further, this SOSC is used as input in the System PLL - so this makes it an External Reference Clock for the PLL. This is why we use the word "external" in the option itself - we'll discuss if we'll keep it this way or not for our future releases. 

• As for the Clock Frequency option - we're using System PLL to drive the Core clock - so when you set this to 80MHz or 112MHz we set appropriate values to some dividers and multipliers to get the desired value out. 

As for the peripherals, we're dynamically checking the system/core clocks and setting the appropriate values for each peripheral - so this should not be an issue when selecting another option than the default one for either clock settings.

Please let us know if you are still having issues with any model after installing our latest toolbox (2018.R1). Feel free to attach a model that you have issues with - this way we can check hands-on.

Hope this helps,

Razvan.

[andyknitt]

Razvan,

Is it correct to say that even when using the 'internal' oscillator for SOSC, an external crystal oscillator is still required, as shown in the Eval Board schematic below?

From this app note: 

“The SOSC can source from either a signal driven into the EXTAL pin or a crystal oscillator connected to the XTAL and EXTAL pins (henceforth referred as simply “XTAL”). EXTAL can support up to 50 MHz, while there are two ranges that are allowed for the XTAL depending on configuration: 4-8 MHz or 8-40 MHz”

Regards,

Andy K.

[constantinrazva]

Hello andyknitt‌,

I am not an expert in clocks, but after a little more reading I can say that yes, you still need that - but we can just switch from using SPLL for SYSCLK, BUS CLOCK , CORE CLOCK etc. to using FIRC which is the fast internal reference clock. It is my understanding that for FIRC no external oscillator is needed. We can edit the clock configuration file if you need this switch.

Kind regards,

Razvan.

[andyknitt]

Thanks, that makes sense.  Does the accuracy/stability of the FIRC present any problems for asynchronous communication peripherals like CAN or UART?

Andy

[constantinrazva]

Hello andyknitt‌,

We didn't face any problems in our tests; but we don't have stress or heavy traffic tests implemented for CAN; so for this issue I can only say that we've not tested extensively the asynchronous comms with FIRC to confirm or not if the stability of the internal clock affects the signals. I'm not sure who'd know the answer to this, but I'll get back with a mention on this post after I find out.

Kind regards,

Razvan.

[andyknitt]

Thanks Razvan.  I have tried modifying s32k_clock_init.c as shown in the attached example.  I have changed all references to _SYS_PLL to _FIRC instead, but it appears that the SPLL/external crystal are still needed (if I short out the external crystal the application runs incorrectly).  If I set .spllConfig .initialize to false in s32k_clock_init.c, the application also fails to run.  Can you provide an example of s32k_clock_init.c that configures the system to not use the external crystal at all?  Alternatively, can you provide instructions on how to generate this file using the ProcessorExpert?  I have found the GUI for the clock options but am unsure of how to use this to generate the file apart from a full project (I only need this one file to use with Simulink).

Also, the default s32k_clock_init.c configuration appears to use FIRC if CORE_CLK_FREQ = 80 MHz and RUN mode (as opposed to HSRUN) is used.  I tried to force this configuration in Simulink as shown below.  Again, while this runs, it is dependent on the external crystal (shorting it causes the application to run incorrectly).  

Any assistance you can provide in getting a configuration that does not use the external crystal at all would be appreciated.

Thanks,

Andy K.

[constantinrazva]

Hello andyknitt‌,

For you to generate code for anything with Processor Expert, after selecting all the options that you need in the UI, click on Project -> Generate Processor Expert Code. Once this process ends, you'll have a folder Generated_Code. There you'll have all the files that were generated by PEX. You'll find the code for clock in clockMan1.c file.

I'll take a look at your model and your clock_init function and will get back to you with details.

Kind regards,

Razvan.

[constantinrazva]

Hello again andyknitt‌,

Sorry for the delay, I read your clock_init function and I have 1 mention to make:

in .clockModeConfig, in .rccrConfig, you'll have to set .src = SCG_SYSTEM_CLOCK_SRC_FIRC

In what you have sent me, you have the PLL selected.

I have attached a file with this modification. Can you try this one and get back if you have anymore issues with it?

Kind regards,

Razvan.

[andyknitt]

Razvan,

My mistake, I uploaded the file after I had changed it back to the original configuration.  I did actually try it with .clockModeConfig -> .rccrConfig -> .src set to SCG_SYSTEM_CLOCK_SRC_FIRC.  I also had .clockModeConfig -> .hccrConfig -> .src set to SCG_SYSTEM_CLOCK_SRC_FIRC rather than SYS_PLL (you can see those lines commented out in my file).

When I do that (and when I use the file you provided) the application runs, but when I short out the external crystal oscillator it stops executing.  This makes me think that it's still dependent on the external crystal oscillator even with those settings.  Would shorting out the external crystal cause a problem even if the processor is running on the FIRC?

Thanks,

Andy

[constantinrazva]

Hello andyknitt‌,

I must be missing some configuration parameter, as this is for sure possible - it's stated as such in the reference manual (page 537 in the revision I have, under Chapter 26, System Clock Generator -> Introduction -> Features):

I'll start doing some tests today to find out what I've been missing and get back to you.

Kind regards,

Razvan.

[constantinrazva]

Hello andyknitt‌,

I found what I was missing - the reason why the application stops once you short the XTAL is due to the way our applications work:

We use a timer (LPIT) to call the main loop (step function) and that timer is using the PLL as a clock source.

Please replace mbdtargetmainlibs32k14.tlc file found in

C:\git_ccr\mbdt_ccr_demo\S32K\src\mbdtbx_s32k14x\mbdtbx_s32k14x

with the one that i attached here. This worked on my side.

Note: we'll have to make some adjustments so that when you set the fixed discrete step to 1s, the timer will call the main loop at exactly 1s. I did not mind this changes at this point, as the purpose was to see if it works without an external crystal.

Note2: There are some other peripherals that use PLL as their clock source, so if you are using those, the application will not work. If you want I can make changes and select FIRC for all of them and attach them here.

Kind regards,

Razvan.

[constantinrazva]

As a side-note, you can make custom clock configurations, if you need to. For this, you can edit the following file:

{Install_dir}\mbdtbx_s32k14x\src\c_library\s32k_clock_init.c

If you don't want to read all the clocking chapter from S32K RM, you can download S32 Design Studio for ARM (found here) if you don't already use it. From Design Studio you can use Processor Expert to generate the clock configuration you want - it has a GUI that let's you select clock configuration options and then generates the configuration structure for it. You can copy&paste the configuration structure from there into s32k_clock_init.c. 

Hope this helps,

Razvan.

[andrewweiss]

When I select the last button to ‘verify’, Matlab indicates busy and continues this… no exit. I have to force shutdown Matlab to exit after many minutes.

Andy Weiss

[Daniel_Popa]

Hi Andrew, 

You have probably installed many version of the same toolbox and now MATLAB takes a lot of time to check them all.

Just go in the ...\Documents\MATLAB\Add-Ons\Toolboxes folder and delete all NXP_MBDToolbox_S32K1xx folders that you might have there. 

Additionally you can use MATLAB Set Path menu button to clear up the MATLAB paths to defaults (to eliminate the duplicated S32K toolboxes).

Then you should be able to install the toolbox. If you wish to use the installer guide fine, otherwise since you have the main mltbx file you can install it directly and just copy the license file manually into: ..\Documents\MATLAB\Add-Ons\Toolboxes\NXP_MBDToolbox_S32K1xx\code\lic

Hope this will resolve your issue.

Best regards,

Daniel

[andrewweiss]

Hi Razvan,

Thank you for this investigation.

I’m struggling to install the R2018a version of the NXP toolbox. It seems to have installed and I can see the add-on from Mathworks side, but can’t verify the installation. Also, the toolbox isn’t shown within the Simulink browser – no NXP blocks shown.

I have tried several times to follow the sequence.

Let me know how to proceed!

Thanks,

Andy

Andy Weiss

[Daniel_Popa]

Hi andrewweiss‌

Please give us some time to investigate the impact. The clock initialization is kept in a C-file but it is tightly coupled with all the other chip peripherals initialization. Changing the clock may be easy but making sure all the other peripherals are still working as expected might be more complicated.

We will investigate and we will let you know about our findings.

Best regards,

Daniel