Clock configuration with KDS3.0/KSDK1.2.0

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Clock configuration with KDS3.0/KSDK1.2.0

Jump to solution
1,949 Views
matthias
Contributor III

Hello,

 

I have converted a larger project from KDS2.0/KSDK1.1.0 to KDS3.0/KSDK1.2.0. In KDS3.0/KSDK1.2.0 the clock configuration in ProcessorExpert has been moved from the CPU component to the fsl_clock_manager component. My problem is that all the settings I make in the clock configuration are ignored and my application runs with some default internal clock configuration.

I see that with KDS2.0/KSDK1.1.0 there was a file "system_MK64F12.c" in the SDK folder. The folder structure has changed slightly in KDS3.0/KSDK1.2.0 but it seems that this file has disappeared. As it seems that the initial clock configuration is done in this file, I suspect that this has something to do with my problem.

KDS2.0/KSDK1.1.0:

32429_32429.pngpastedImage_0.png

KDS3.0/KSDK1.2.0:

32430_32430.pngpastedImage_1.png

Any hints on how to set the clock configuration during startup using Processor Expert are appreciated!

 

Regards

Matthias

Labels (1)
1 Solution
954 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello matthias:

Your understanding is partially correct, but let me add more info:

-> Your statement is true, when selecting startup in library mode, the CMSIS startup source code (system_<device>.c) takes the macros from a default header file system_<device>.h installed with KSDK (e.g. in "...\KSDK_1.2.0\platform\devices\<device>\startup"). So you have 2 options:

1) Use the default header but add the macro #define CLOCK_SETUP (0/1/...) so the CMSIS startup code knows which configuration to apply.

2) Generate code with PE and make sure the startup library project uses the generated header file system_<device>.h inside of "Generated_Code -> SDK -> platform -> devices -> MK64F12 -> startup" instead of the default header from KSDK installation. For this you can edit the compiler search paths.

Honestly I see no reason to select startup library mode, since Processor Expert can take care of the init code and you avoid these issues.

-> Even if selecting startup library mode your PE clock settings are not useless. You can still use those with the clock_manager APIs (CLOCK_SYS_Init(), CLOCK_SYS_SetConfiguration(), CLOCK_SYS_UpdateConfiguration(), etc).

I hope this helps to clarify.

Regards!

Jorge Gonzalez

View solution in original post

0 Kudos
8 Replies
954 Views
vfilip
NXP Employee
NXP Employee

Hi,

this is how it should look like in 1.2.0, it is for different processor but general structure is the same. Did you click on generate code button in your 1.2.0 PE project?

pastedImage_0.png

PEx will update the project content based on selected path to SDK and ksdk_manifest.xml file in root of SDK. However PEx do not adds system_<DEVICE>.h file from SDK. This file is generated into following location by clock_manager_component (this component also generates structure for the driver).

pastedImage_5.png

Best regards

Vojtech Filip

0 Kudos
954 Views
matthias
Contributor III

Hello Vojtech,

as I wrote in my last answer to you and Jorge, the file "system_MK64F12.c" was back in the startup folder when I started the project from scratch. However, when I made some changes in Processor Expert components (changed the OS from BareMetal to MQX), a message appeared that this file is no longer needed and will be removed. Now the file is gone again. The project is still compiling but the problem of my original post, that the clock settings defined in the clock manager are not applied when the application is running, is back.

Pressing the generate code button does not thelp. However, when I manually copy "system_MK64F12.c" from the KSDK source, the application runs with the correct clock again.

Am I doing something wrong or is there a bug in the ProcessorExpert file generation/ file copying?

Regards

Matthias

P.S.: I have another simple project using KSDK/MQX and here, "system_MK64F12.c" comes back automatically if I remove it and press the generate code button. So I wonder if there is a setting that I am not aware of. Do you have any hints here?

0 Kudos
954 Views
matthias
Contributor III

Hello again,

well, I found the reason why the file disappeared. The project uses Processor Expert library modes for platform_lib and startup_lib. But this means still that if I use library mode and do not copy back "system_MK64F12.c", the clock initialization is wrong.

How is the clock initialization meant to be done with libraries? Do I have to compile the libraries in a different way?

Regards

Matthias

0 Kudos
955 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello matthias:

Sorry for the delay.

You need to import, build and link the startup library project. Please give a check to this other thread about library modes with Processor Expert:

Re: KSDK Library mode

About the clock configurations, I will reply to your new post in a moment.


Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

955 Views
matthias
Contributor III

Hello Jorge,

thank you for the link to the other post. I think I begin to understand how this is meant to work. I already biult and linked the startup library but that was exactly the problem. As I understand I cannot use the startup library if I do not know/define the initial clock setup when building the library because all the clock setup is done with macros and my settings in Processor Expert are ignored.

Regards

Matthias

0 Kudos
955 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello matthias:

Your understanding is partially correct, but let me add more info:

-> Your statement is true, when selecting startup in library mode, the CMSIS startup source code (system_<device>.c) takes the macros from a default header file system_<device>.h installed with KSDK (e.g. in "...\KSDK_1.2.0\platform\devices\<device>\startup"). So you have 2 options:

1) Use the default header but add the macro #define CLOCK_SETUP (0/1/...) so the CMSIS startup code knows which configuration to apply.

2) Generate code with PE and make sure the startup library project uses the generated header file system_<device>.h inside of "Generated_Code -> SDK -> platform -> devices -> MK64F12 -> startup" instead of the default header from KSDK installation. For this you can edit the compiler search paths.

Honestly I see no reason to select startup library mode, since Processor Expert can take care of the init code and you avoid these issues.

-> Even if selecting startup library mode your PE clock settings are not useless. You can still use those with the clock_manager APIs (CLOCK_SYS_Init(), CLOCK_SYS_SetConfiguration(), CLOCK_SYS_UpdateConfiguration(), etc).

I hope this helps to clarify.

Regards!

Jorge Gonzalez

0 Kudos
955 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello matthias:

Just to complement on Vojtech Filip's good answer, you need to have predefined clock configurations and then select one of them for initialization in Processor Expert.

Below is an example of the configurations you get when creating a project for FRDM-K64F. In this case there are 6 predefined clock configurations from which Configuration 1 is selected for initialization:

K64_Clock_configs.png

Also your configurations will be available in the generated file clockMan1.h (default name) for you to use them using the system layer API CLOCK_SYS_SetConfiguration().


Regards!,
Jorge Gonzalez

955 Views
matthias
Contributor III

Hello Vojtech, hello Jorge,

thank you for your hints. It seems that my project didn't survive the migration from KDS 2.0 to KDS 3.0. I started now with a new project from scratch in KDS 3.0/KSDK1.2 and now the missing file "system_MK64F12.c" is back in the SDK folder and at least the initial clock settings are correctly applied by Processor Expert.

However, I still have some questions regarding how to switch between clock configurations: When I use CLOCK_SYS_SetConfiguration() as you recommend, I can apply a new clock setting, but then all timers, uart, etc., do not work properly any more because they get not informed that the clocks have changed. In the reference manual I see that the function CLOCK_SYS_UpdateConfiguration() should be the right one to use because it can notify all drivers that the clock has changed. However, it seems that I manually have to implement callback functions for all component drivers that should be notified. Is there a way that Processor Expert takes care of notifying all affected drivers automatically when the clock configuration changes?

Regards

Matthias

0 Kudos