Kinetis KV5x maximum ambiguous clock frequency

[andreacanepa]

The technical specifications show that the maximum clock frequency for MKV58xxx is 240 MHz (HSRUN).

The maximum frequency for the Peripheral (Fast Peripheral Clock) is 120 MHz, with the requirement to have at least /2 the CPU frequency.

So if the CPU has the clock at 240 MHz you can get 120 MHz on the peripherals. And all right here.

Unfortunately in the documentation (https://www.nxp.com/docs/en/reference-manual/KV5XP144M240RM.pdf paragraph 8.7 page 132) it is written that the flash memory not be programmed or erased while operating in High Speed Run (HSRUN).

For this reason, you must set the maximum allowed frequency for "Normal Run" mode: 160 MHz. By reducing CPU frequency to this value, unfortunately we also get the frequency of peripherals to become 80 MHz, really poor.

I wonder: what is the point of having an MCU that can work at 240 MHz and then have to limit it to 160 MHz due to flash memory?

It is not permissible to switch mode from HSRUN to NORMAL RUN during Flash programming, because all peripherals would change their operating frequency. In the case of motor control everything is a problem. The frequency must be set at the start and that must be set for the whole time. We are not talking about a smartphone that needs to save the battery.

It may happen that my drive need to save parameters on the flash memory while the motor is running controlled by my inverter.

Does anyone tell me why this bad choice was made?

Regards

Andrea.

[chris_brown]

andreacanepa,

After reviewing this thread more carefully as well as the reference manual, datasheet, and discussing this with design, I do not see a problem with what you are trying to do.  The System (CPU) clock is restricted to 160 MHz in normal RUN mode but the Fast Peripheral clock and MCGPLLCLK are not restricted at all.  These two mentioned clocks are capable of operating up to 120MHz and 240MHz respectively, and these are the clocks necessary to run the Nano-edge module.  

So if you need to program Flash (and are using HSRUN), you need to simply change the System (CPU) clock to a frequency that is in an acceptable range for normal RUN, and then move from HSRUN to normal RUN for the Flash programming portion of your application.  There is no need to change the Fast Peripheral clock or the MCGPLLCLK to do this.  

Now, I see that you came to this conclusion yourself, so I congratulate you on finding a solution before I was able to respond.  This let's me know that the documentation is actually in pretty good shape. 

As to why the clock system architecture is the way it is, it allows us to maintain software compatibility with devices that came before KV5x.  It is very unlikely that anyone would want to clock the entire chip from the MCGIRCLK.  Marketing research showed us that most designs would want the accuracy of a crystal based system anyways, so resources were not used on a high accuracy internal clock source.  Furthermore, the internal clock sources are very useful if you need a low power source for a periodic timer, and that is their main use on this particular device.  

Now if I need to clarify anything further, please let me know and I'll be happy to help.  Otherwise, I wish you the best of luck on your project. 

Regards,

Chris 

[andreacanepa]

Chris Brown ha scritto:

Now, I see that you came to this conclusion yourself, so I congratulate you on finding a solution before I was able to respond.  This let's me know that the documentation is actually in pretty good shape.

I'm glad my trick might work. But there is some inconsistency:

1. As Mark has rightly pointed out, and as it is actually written in two different documents (see above) it is written that: "Thus the fast peripheral bus clock provides the nanoedge clock, and MCGPLLCLK provides the "2x Fast peripheral bus clock". Each of these clocks must be an integer divide or multiple of the System (CPU) clock.". Therefore, according to the documentation, it would not be possible to make my configuration in Normal Run mode and use the nanoEdge because System Clock is identical to Fast Peripheral clock.
2. Also in reference manual in paragraph 6.3 page 102 we find that "The Fast Peripheral clock frequency must be an integer divide or multiple of the System (CPU) clock, that is, x2, x3, x4, or divide by 2/4/8".
   

Where's the mistake?

Regards

Andrea.

[chris_brown]

andreacanepa‌

As in your points #1 and #2, the reference manual does state that the fast peripheral bus clock and the MCGPLLCLK must be integer divides OR MULTIPLE of the System (CPU) clock.  That statement in no way means that either of these clocks must be LESS than the System (CPU) clock. 

That statement means you can't do something like set OUTDIV1 to divide by 2 and OUTDIV2 to divide by 3.  In that situation, the fast peripheral bus clock (fed from OUTDIV2) would not be an even multiple or divide of the System (CPU) clock (fed from OUTDIV1).  But you could do something like set OUTDIV1 to divide by 4 and OUTDIV2 to divide by 2.  Or you could say set OUTDIV1 to divide by 3 and set OUTDIV2 to divide by 1.  In both of these cases, the fast peripheral clock would be an integer divide or multiple of the System (CPU) clock.  

I hope this clears up the confusion.  

Best regards,

Chris 

[andreacanepa]

Chris Brown ha scritto:

As in your points #1 and #2, the reference manual does state that the fast peripheral bus clock and the MCGPLLCLK must be integer divides OR MULTIPLE of the System (CPU) clock.  That statement in no way means that either of these clocks must be LESS than the System (CPU) clock.

So in my Normal Run configuration between System Clock (120 MHz) and Fast peripheral clock (120 MHz) we can consider that we have an /1 or x1 ratio, which means an integer, so it is acceptable. Thank you. Now I understand.

Instead, what can you say about what Mark had written:

From what is written in the data sheet if we want to use the microEdge we can not set the system clock equal to the fast peripheral clock: it must be half. So during Normal Run it would not be possible to use microEdge as both the two frequencies are 120 MHz.

Regards

Andrea.

[chris_brown]

andreacanepa‌

Ah, I missed that note the first time.  That is an error.  Instead of the system clock there, it should be the MCGPLLCLK. If I remember right, there was a previous devious with this module and that module did use the system clock for the Nano-edge 2x clock (but KV5x is not designed this way).  So that's probably a carry over from a previous device, which is a mistake.  I will make sure to get this updated in the next revision of our datasheet.  Thanks for pointing that out. 

Regards,

Chris 

[andreacanepa]

Good. So we can say that we have clarified everything, unless someone else has anything to add.

So we can say that we can circumvent the problem of Flash memory that can not work at 240 MHz, using the trick I've written just above. And so I can consider that the correct answer. Do you agree?

Andrea.

P.S.: Now I just have to wait on November 15 to download the new MCUXpresso and new Config Tools so I can try it all on the board.

[chris_brown]

andreacanepa‌

Firstly I would say that we have clarified everything.  

But I would argue that your method is not really a "trick".  It's just the way the device has to operate due to the design restrictions.  To program or erase the flash memory, you cannot be in HSRUN (which is not a clock mode but a power mode).  And when not in HSRUN (assuming normal RUN), the System (CPU) clock is limited to 160 MHz or less. There are no other clock limitations that I know of off of the top of my head. So your fast peripheral can be operating at 240 MHz.  

Regards,

Chris 

[andreacanepa]

Chris Brown ha scritto:

 So your fast peripheral can be operating at 240 MHz.  

Maybe! If this were true, I would be happy! It would be the right operating situation: cpu clock and peripheral clock at the same maximum frequency (which is the situation that some of your competitors make with ARM and that you do with the DSC).

Unfortunately I think what you wrote is a lapse: maybe you intended to write that the System Clock will work at 240 MHz (not the fast peripheral clock). :smileywink:

Andrea.

[mjbcswitzerland]

Andrea

Looks like you got lucky that the restriction was an error!

Looking at the clocking diagram:

one sees that the x2 nano-edge clock is indeed not the system clock but the MCGOUTCLK, which happens to be equal to the MCGPLLCLK in the general high speed case.
If this diagram is exact it is thus the MCGOUTCLK that needs to be twice the speed of the fast peripheral clock, which is always the case as long as OUTDIV is set to 2.

Regards

Mark

[andreacanepa · Accepted solution]

Maybe there's a trick to get around the problem.

I have made two configurations with "MCUXpresso Clock Config Tools" that allow you to switch from HSRUN to RUN without changing frequency to critical engine peripherals (PWM & FTM). This only changes the frequency of "Core Clock" and System Cpu Clock: the latter also affects the HSADC clock, but this should not cause problems as only a slower conversion time is obtained for some ms. However with this configuration you can also use nanoEdge without limitation.

The trick is to have the MCGOUTCLK clock at 240 MHz and to switch only the OUTDIV1 divider to change the core clock, while OUTDIV2 is always set to "/2".

For the most part of the time the MCU works in HSRUN with 240MHz CPU and 120MHz Fast Peripheral Clock (so at maximum performance) with this configuration:

When the MCU has to program or delete the Flash Memory, it switches from HSRUN to RUN (normal run), keeping all the fast peripherals at 120 MHz but only reducing the "System Clock" from 240 MHz to 120 MHz, changing the OUTDIV1 divider from / 1 to / 2: this way we respect the features of Normal Run:

Apparently (according to the MCUXpresso Config Tools) we should be able to have the Fast Peripheral Clock frequency equal to that of the System (CPU) Clock. However, reading the reference manual in paragraph 6.3 page 102 we find that "The Fast Peripheral clock frequency must be an integer divide or multiple of the System (CPU) clock, that is, x2, x3, x4, or divide by 2/4/8".

So who is right? :smileyshocked:

Andrea.

[mjbcswitzerland]

Andrea

From the data sheet:

This looks to be the hard restriction that needs to be considered.

One often finds some ambiguous waffle in the user manuals but the content of the data sheets is generally dead-serious...

Regards

Mark

[andreacanepa]

Yes you are right. In the data sheet, it is written.

This limitation (if true) is also found in the "Reference Manual Rev.4" (p.104):

So summarizing, these may be the points that would not allow me to do my trick:

1. If it is mandatory to have between the System clock and the Fast Peripheral Clock the ratio of /2, /4 or x2, x4.
2. If you use nanoEdge question is whether it is true the limitation that we wrote a little higher.

Small comment:

This MCU contains two internal clock generators: one at 4 MHz and the other at 32.768 KHz.

As PLL and FLL have been placed, it is impossible to use the 4 MHz internal clock to generate the MCGOUTCLK main clock at a frequency greater than 4 MHz. What is the point of this thing? Why should I run a 240 MHz CPU to 4 MHz? Maybe to reduce consumption? This is acceptable on battery applications, but not if we are talking about industrial engine control. Therefore, the 4 MHz internal clock is unusable.

Add all these limitations and rules to be observed between the various clocks of the system, to configure the clocks of this MCU is to go crazy.

This simple clock example to configure:

What problem could you create in KV5x if you made a simple clock configuration like this example?

I am aware that NXP can say to me: "If you do not like this product, do not use it and go elsewhere".

Instead my criticism wants to be constructive and improve the product. I work with Motorola / Freescale / Nxp products for 15 years, and I've always been fine.

Andrea Canepa.

[mjbcswitzerland]

Andrea

The internal RC clocks are used to start the processor and by applications that don't need speed and high precision, but do need lowest component count and low power.

KV5x parts don't really fall into the low power/low precision category and so, apart from starting the processor, the internal clocks are not that interesting.

Regards

Mark

[chris_brown]

Hi Andrea,

I would like to be able to give you an official response right now, however, I do need to ask some questions of the Design group first.  I just wanted to let you know that your request for an official response has been received and I will get back to you as soon as I have answers from the Design group.  

Best regards,

Chris Brown

NXP Semiconductors

MICR Systems and Applications

[andreacanepa]

Hi Chris,

well, I'm waiting.

These days I stopped the test on MKV58F because I'm waiting for the release of the new version of MCUXpresso Config Tools scheduled for the second half of November. So I can wait.

Regards

Andrea.

[xiangjun_rong]

Hi, Andrea,

As the section 8.7 in RM of KV58 says, the flash erasing/programming can NOT work in HSRUN and VLPR modes. Of course, it is a bad design, as you say that you can not write flash while you run the eFlexPWM module in 120mhz.

Mark gave several recommendation, it is good.

"8.7 Flash program restrictions
The flash memory on this device must not be programmed or erased while operating in
High Speed Run or VLPR power modes."
BR

Xiangjun Rong

[andreacanepa]

Xiangjun,

thank you for the confirmation.

But no one explains the reason for this wrong choice?

It would be interesting to understand if the NXP thought no one used this microcontroller in HSRUN, or whether they thought no one needed to program the flash during HSRUN operation.

Andrea

[mjbcswitzerland]

Andrea

If you need in-application flash programming it is correct that the HSRUN mode is best avoided.

You could choose 120MHz clock for both system and fast peripheral clocks as long as you don't need the nano-edge module, as a compromise - faster fast peripheral clock than system is allowed and (as far as I know) it is only the nano-edge module which restricts the 1/2 speed.

Regards

Mark

P.S. It is also possible to run at high speeds in RUN mode and thus program flash but this is over-clocking. Very popular in hobby projects where it is considered "cool" but of course risky if your are doing things professionally.

P.P.S. I also find that the HSRUN mode is a bit of a gag, although of course useful if its restrictions (mainly the Flash programming limitation) can be lived with. However I also think that Freescale/NXP needs to do it otherwise the speeds claimed by competitors (notably ST-Micro) would probably cause bigger marketing problems.
P.P.P.S It may have been an idea to add a second PLL in this device to make the speed relations a bit more flexibly.

[andreacanepa]

Mark, Thanks for your answers.

Mark Butcher ha scritto:

You could choose 120MHz clock for both system and fast peripheral clocks as long as you don't need the nano-edge module, as a compromise - faster fast peripheral clock than system is allowed and (as far as I know) it is only the nano-edge module which restricts the 1/2 speed.

This solution would be very restrictive, first of all because I would be obliged not to use nanoEDGE, then at this point it would not make sense to use this Microcontroller with 240 MHz performance to turn it to 120 MHz. So it would be best to use a 144 MHz microcontroller (for example XMC4700) that does not have all the limitations of MKV58 and the complication in setting all the various clocks: it is set to 144 MHz for the CPU and all peripherals.

Mark Butcher ha scritto:

It is also possible to run at high speeds in RUN mode and thus program flash but this is over-clocking. Very popular in hobby projects where it is considered "cool" but of course risky if your are doing things professionally.

Yes, I agree with you. It would be very dangerous in the professional field. I think if the flash memory could work in HSRUN then the NXP would not put this serious limitation.

Mark Butcher ha scritto:

I also find that the HSRUN mode is a bit of a gag, although of course useful if its restrictions (mainly the Flash programming limitation) can be lived with. However I also think that Freescale/NXP needs to do it otherwise the speeds claimed by competitors (notably ST-Micro) would probably cause bigger marketing problems.

Yes, it is likely. But if a manufacturer sells me an MCU that has 240 MHz performance I use at 240 MHz, otherwise it would not make sense to buy it, so it's worth taking a cheaper version that works at a lower frequency.

I mean that the MKV58 was made for high-level applications (not to only to run drones), so I'm expecting high performance (considering chip price and evaluation board price).

Mark Butcher ha scritto:

 It may have been an idea to add a second PLL in this device to make the speed relations a bit more flexibly.

Yes, that might be a solution. Or they could insert a frequency divider, among the many that are already present, to create a separate clock for flash memory.

However apart from all our theories and suppositions, it would be interesting to have an official response from NXP (Freescale).

Regards

Andrea.

[mjbcswitzerland]

Andrea

There are some 400 or so Cortex-M0+ and Cortex-M4 parts to choose from and these have been progressively tuned to user requirements over the space of 5 or 6 years.

There is about 1 Kinetis Cortex-M7 offered at the moment so I expect that more will gradually appear better tuned to what users want.

In the meantime there are many other similar parts that can be used (even if not from NXP). If the part doesn't match your requirements and you find a more suitable ones it is best to use it. You can always come back later to see what has changed if you need to do the same again in the future.

Regards

Mark