Is It Possible to Write to MK22 Flash in HS Clock Mode?

[myke_predko]

I'm having trouble writing to Flash on an MK22 running in HS clock mode (120MHz).  I'm following the code in the pflash and I am consistently failing with an ACCERR error.  

in doing some research, I found this post NXP MKV30F128xxx10 芯片RAM运行工程 擦除FLASH 扇区不 in which Sabina Bruce indicates that the MKV30 cannot update it's Flash in HS mode.  Sabina provids a reference in the MKV30 RM which states that this is not possible:

Attempts to launch a flash command in VLP mode will be ignored. Attempts to launch a flash command in HSRUN mode will be trapped with the ACCERR flag being set.

This note is not present in the MK22 RM (I have found the corresponding section) although the message "Attemps to launch an FTFE command in VLP mode will be ignored" is still there.  

So, is this the case with the MK22?  If it is, is there a work-around for doing Flash operations in HS mode?  

So, what can I do?  Changing the clock operation for a write is not practical as my product is connected to a host computer via USB during this operation.

Thanx!

[ErichStyger]

Hi Mike,

Indeed, I have found out (https://community.nxp.com/thread/377633) that it is not possible to do flash programming in HS mode on the K22. I'm running it at 120 MHz and during flash programming I switch back RUN mode, see

mcuoneclipse/nvmc.c at master · ErichStyger/mcuoneclipse · GitHub 

One extra note is that I had to add a short delay after switching the mode, otherwise flash programming still fails.

As for USB: I'm currently not doing this in that project, but that should be possible imho if you change the USB clocking accordingly.

I hope this helps,

Erich

[myke_predko]

Hi Erich,

Thank you for replying and thank you for the link - I guess I should have kept on my search to see that link but I focused on the past year.  

Regardless the link provides some hints but I'm running the following features while the Flash operations are taking place:

• USB, as noted, probably the most critical and requires the contstant 48MHz clock.  
• UART, I will have to change the baud rate divisors which shouldn't be a big deal as I would do it as a call to the UART task.  
• SPI, same comment as the UART although I may not have to - I need to do some experimenting here.  
• FTM (All three being used), same comment as the UART.
• I2C, a lower clock rate should not be an issue.  

In the link you referenced, there is code for changing the clock out of HS Mode - any suggestions on how to keep the USB clock at a constant 48MHz?  I'm playing around a bit with the Clocks tool and I think I can get a standard run going at 120 MHz (with a 48MHz USB Clock) - and then change OUTDIV1 to 2x (normally 1x) for the Flash Write.  Is this a possible solution?  

Is there a good Kinetis clock reference document and explains the MCUXpresso clock tool?  The RM is overwhelming in the minutia and I haven't been able to find anything that really explains the clock tool and how things are selected - I get that if in your selection you end up with something that is an error or warning it is bad and look to fix it, but if you don't get an error are you good to go?  

Thanx.  

myke

[mjbcswitzerland]

Myke

HSRUN mode is available on some K22 parts [notable the SF8 types] (there are other K22 parts that don't have this and can operate to 120MHz without any restrictions). The user's manual has a section which lists the restrictions in HSRUN mode, including the fact that flash programing and erasure is not supported.

One simple workaround is to operate at 80MHz instead of 120MHz, if you don't have anything that is really super time critical or your application is already loading the processor close to 70%. This then allows operation without restrictions and without complications of keeping all communication and timing interfaces synchronised.

Although not advisable for any professional work it is usually possible to run the same K22s at 120MHz without switching to HSRUN mode. It is presumably overclocking and so out of spec but it always worked for me (for fun).
These are the parts that I have used which require HSRUN mode:
#if defined KINETIS_K02 || defined KINETIS_K22_SF8 || (defined KINETIS_K22 && !defined KINETIS_FLEX && ((SIZE_OF_FLASH >= (128 * 1024)) && (SIZE_OF_FLASH <= (512 * 1024)))) || defined KINETIS_K80 || defined KINETIS_K26 || defined KINETIS_K27 || defined KINETIS_K28 || defined KINETIS_K65 || defined KINETIS_K66 || defined KINETIS_KL28 || defined KINETIS_KL82 || defined KINETIS_KE14 || defined KINETIS_KE15 || defined KINETIS_KV40 || defined KINETIS_KV50 || defined KINETIS_KS

and until now I have simply used RUN mode in such designs to avoid complications if I needed to be able to program flash during full operation.

If you are using USB device you will be able to clock directly for the IRC48M with crystal-less operation so USB is not an issue. See also https://www.utasker.com/kinetis/MCG.html

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[myke_predko]

Hi Mark,

In the current version of the product, I'm running an MK20 at 96MHz in "Run Mode" without any issues - I think the prudent thing would be go back to that.  

It's disappointing because I have a data processing/execution task that I was looking forward to running 25% faster.  

Just out of curiosity, what is the maximum recommended clock speed that is "recomended" for Run Mode?

Thanx,

myke

[mjbcswitzerland]

Myke

The limitations are defined in the exact part's data sheet but the following in the user's manual also gives the clocking limits:

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[myke_predko]

Hmmm...  

Not the values I was expecting (or hoping for).  

Can I ask what document you're referencing above?  I can't find a "users manual" for the K22 devices - my primary source of information is the datasheet and reference manual for a part.  Should I be looking somewhere else?  

I'm asking because when I look for "Internal Clocking Requirements" in the RM for the MK22 I get:

The MK22 documentation that I have (which is the latest available on the website) doesn't reference the "HS Mode" at all.  I'm going by what I'm reading here and what's on MCUXpresso.  

Is the simplest solution to call "BOARD_BootClockRUN", which puts the processor into RUN Mode before the write takes place and then call "BOARD_BootClockHSRUN" when the Flash write is complete?  I know that I have the other clocked peripherals to deal with, but I would like to experiment with this now. 

Comments? 

[mjbcswitzerland · Accepted solution]

Myke

There are 12 different user's manuals for K22 parts - you need to use the one that matches your exact part. If you have a part with HSRUN mode but you don't have it in the document it can only mean the document is not for your exact part.

Look at the very first page of the user's manual to see the parts that it can be used with - for example here is the first page of the K22P121M120SF7RM which is one that does have HSRUN mode:

compared to one that doesn't (K22P121SF5V2RM):

The K22s can be somewhat confusing since different K22 parts can be quite different and incompatible, matching more closely to other differently names parts types.

Since I don't use the SDK (I use the uTasker project as optimised solution) I can't say which routines to use for the SDK but I can show these:

1. The HSRUN mode prevails over warm resets so in order to ensure RUN mode when HSRUN is not wanted after a reset I use this:
    if (SMC_PMSTAT == SMC_PMSTAT_HSRUN) {                                // if in high speed run mode we switch back to run mode
        SMC_PMCTRL = (SMC_PMCTRL_STOPM_NORMAL | SMC_PMCTRL_RUNM_NORMAL);
    }

2. When HSRUN is used the following is set before moving to the higher speed clock settings:
    SMC_PMCTRL = SMC_PMCTRL_RUNM_HSRUN;                                  // set high speed run mode (restrictions apply) so that the clock speeds can be obtained  

Therefore, essentially to switch back to RUN mode you need to first reduce speeds to within RUN mode specs then do an equivalent to 1.
To step back up you need to do the equivalent of 2. and then set the clocks back to the higher settings again.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[myke_predko]

Hi Mark,

Okay, I have the demo FRDM-K22F (with the MK22FN512VLH12) operating in RUN Mode at 60 MHz with the USB and flash write working.  It's interesting to see how much slower the SPI operations are at 60 MHz.  

I spent a few minutes with the clock tool and came up with my own 120 MHz clock configuration with USB interface and the product seems to be running fine.  

Thanx for your help and patience with me.  

myke

[myke_predko]

I feel like I've been kicked in the head.  

I apologize for not reading your earlier posts more clearly.  I honestly didn't pick up on what you were saying in the third sentence of your comment:

Although not advisable for any professional work it is usually possible to run the same K22s at 120MHz without switching to HSRUN mode. It is presumably overclocking and so out of spec but it always worked for me (for fun).
These are the parts that I have used which require HSRUN mode:

My excuse is that on my product (which has an MK22FN1M0AVMD12), I'm using the "clock_config.c/.h" and USB code from the TWR-K21F120M USB CDC device demo (SDK 2.3.1) because I had issues with getting clocking to work on my part but copying in the files meant things worked fine.  For the next version of the product, I am attaching an SPI device to the next version of the product and, before wasting time and money on a prototype board, I wanted to validate the wiring and software (which requires the Flash write capability) and decided to use the FRDM-K22F not realizing there was the clock differences which affected Flash write.  Because I never dived into the MK22FN1M0AVMD12 clocking, I never realized (or would have thought) it was different from the MK22FN512LH12 used in the FRDM-K22F board - I thought running at 120MHz on both part numbers was identical.  

Well, I understand Kinetis K22 clocking a lot better after the past two days and I probably won't make that mistake again.  

The good news is that I will run the FRDM-K22F at RUN Mode with a 60 MHz clock to validate the SPI device and its software and I don't have to play around with the operating modes of MK22VN1M0AVMD12 on the processor.  

Thanx for your patience with me.  I'll change the FRDM-K22F clocking as well as specify the Product clocking (rather than copying the TWR-K21F120M clock_config.c/.h files) and let you know how I make out.  

[ErichStyger]

Hi myke,

as for a tutorial I came up with this: Tutorial: Maximum Clock Frequency for Kinetis using MCUXpresso Clock Tools | MCU on Eclipse 

I think it should be doable to get the 48 MHz clock for the USB independent of RUN or HSRUN mode (did not check/implement this in my applications). As for the other things: because flash programming is pretty disruptive and mostly disables all interrupts anyway (at least on some devices), I think it would be best to stop everything else instead of changing the clocks? Just a thought.

Erich

[myke_predko]

Hi Erich,

Yes I did see that - my issue is that I want to use USB and I wasn't sure how to enable it.  

I'm going to copy the project and try running at 96MHz in Run mode rather than HS Mode.  See my comment below to Mark.  

Thanx,

myke