MK22 - Changing between HSRUN and RUN disconnects USB

[dennis_frie]

I'm working on a project, where the MK22 is used in high-speed mode, as we need full processing power for data-processing. Unfortunately, we need to save some user-settings every now and then. As flash-write is not supported in high-speed mode, every flash-write means we have to:

- Change to RUN-mode
- Write to flash
- Change back to HSRUN mode

While everything seems to be working, any active USB-connection stops working every time the above is done. Disconnecting USB and connecting it again and everything is back to normal - so I guess we're close.

Is there something specific we should be aware of in terms of USB clocking?

The functions to change between RUN mode and HSRUN mode are attached. The only difference between the 2 functions, is the clock-divider .clkdiv1 in sim_clock_config_t and the runmode that's HSRUN and run

[dennis_frie · Accepted solution]

Thanks for your input guys.

The specific device in use is MK22FN128VLH10 - but the problem seems to be identical on all devices, where flash-write can't be done in HSRUN mode.

The USB should be running on the IRC48 MHz, the USB-clock is init'ed using;
CLOCK_EnableUsbfs0Clock(kCLOCK_UsbSrcIrc48M, 48000000U);

Running the MCU at full speed in RUN-mode might work, but as we're running the MCU near it's temperature-limit, it's not something I would be comfortable doing in general.

I did some more debugging with your comments in mind and found that;
- The USB problem problem is caused by calling CLOCK_SetSimConfig
- The function CLOCK_SetSimConfig calls SIM-CLKDIV1, CLOCK_SetEr32kClock and CLOCK_SetPllFllSelClock
- The function causing problems, is CLOCK_SetPllFllSelClock.
- For the fun of it, I tried changing to RUN mode when doing a flash-write (without actually changing clock-speed) causes a hardfault (VECTTBL - indicates a BusFault on a vector table)

In my case, the attached functions to change between HSRUN and RUN-mode seems to work and solves my USB-problem. Only CLKDIV1 is changed, as the other clocks are within RUN-mode specs

[mjbcswitzerland]

Hi

I would check two things:
1.
SIM->CLKDIV1 = 0x01030000;

If the PLL clock is 120MHz you are running the Flash clock at 30MHz, which is out-of-specification (max. 26.67MHz). This risks random read errors and resulting system crashes.

2.
SIM->CLKDIV1 = 0x11030000;

This intends to reduce the system clock to 60MHz but I don't think that this is possible. Try reading back the register after you have written it and I expect that you will find that the write has been ignored, meaning that the system clock is still at 120MHz in RUN mode.
This allows Flash operations but is running the core out of spec. - This "un-documented" restriction (not being able to change the OUTDIV1) is what causes the complication and without checking that the write works one has the feeling that all is well, when it is unfortunately overclocking the processor in RUN mode....which, as you point out, is an uncomfortable situation in a professional product.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

[dennis_frie]

Thanks Mark

1) This is only a 100 MHz device, so the PLL clock is set to 96 Mhz. This should give 24 MHz flash-clock, which is well below the maximum 26.67 MHz. However, really good catch, had it been the 120 MHz device.

2) Please see the attached screenshot. Reading back the register SIM->CLKDIV1 does indicate, that the clock-divider should be changed correctly. Admittedly, I have not verified that the clock is actually changed by outputting the clock to a pin, but I would expect it to be, considering the updated divider-value. From what I've seen, I don't see any indication that the CLKDIV1 can't be changed while running.

[mjbcswitzerland]

Hi

OK - that looks good. I was assuming a 120MHz part so your flash divider is correct for 96MHz PLL operation.

In addition the CLKDIV1 write limitation exists on the MK22FN512VLH12 part as used on the FRDM-K22F board but may not be the same for others - in fact there are quite a number of K22s versions that have quite different characteristics so your 100MHz part (with a completely different users manual) could well behave differently. Your check is adequate to show the RUN speed is correct.

Regards

Mark

[mjbcswitzerland]

Hi

Which clock do you use for USB?

If using MCGPLLCLK you could try changing it to IRC48M (crystal-less mode) instead to see whether it allows the change without glitches on the USB.

Note that you can in fact run the K22 at 120MHz in RUN mode (rather than HSRUN), where it then allows flash writes at full speed. This works practically but is is out-of-spec. and so may not remain reliable at temperature extremes.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or product development requirements

[myke_predko]

Hi @mjbcswitzerland 

I tried both of what you're suggesting (I think you may have suggested it to me).  

IRC48M didn't work well for me - out of the three FRDM-K22F's that I have, it only worked on one of them (the first one, of course, leading me to the conclusion that it would be fine).  There was some PC sensitivity, IIRC there was one of the FRDM-K22Fs that would only work with one laptop that we have.  

I NEVER got FRDM-K22F Flash writes working at full speed (120MHz) - I had good reliabiilty at 96MHz but successful writes trailed off after that.  

You and @ErichStyger were very patient with me, trying to get it through my thick head it wouldn't work here: Is It Possible to Write to MK22 Flash in HS Clock Mode?  The short answer is "no" unless you're running the MK22FN1M0Axxx or MK22FX512Axxx parts.  I have quite a bit of experience with the MK22FN1M0Axxx parts and writes seem to run fine at 120MHz, for the other MK22 parts, not so much.  

[mjbcswitzerland]

Hi Myke

I think that the main problem with this part is that it is not possible to change the system clock speed by writing to the OUTDIV1 value in SIM_CLKDIV1 when its input is connected to the PLL. This is not documented anywhere but practically I haven't been able to do it (it looks to be considered as an illegal write to the OUTDIV1 field, which also causes all values written to the register to be ignored (also OUTDIV2, OUTDIV3 and OUTDIV4 fields, which can otherwise be written as long as the OUTDIV1 is not changed in the long word write).

This means that the reference code being used to change state "looks" to always change the clock state between PEE to FEE, which will cause glitches if this is used as USB clock source. If just the system clock divide could be changed it would be easier and glitch free.

Out of interest I just built two USB-CDC device projects for the FRDM-K22F running at 120MHz in HSRUN mode and set the RUN mode  during flash writing and erasing.
One clocking the USB from MCGPLLCLK and the other using crystal-less mode from the IRC48M.

Both are attached as binary files and I have no problem with the USB when writing and erasing flash.

To test:
- connect USB and it enumerates as CDC (VCOM) with a command line interface.
- hit the enter key to get to the menu (same also works on UART VCOM but doesn't exercise the USB at the same time)
- go to the I/O menu (3)
- check that it is in HSRUN mode with the command
"md 4007e003 b 1" which will display 0x80 (this is the SMC_PMSTAT register which display the power mode that is currently active and 0x80 means HSRUN mode (0x01 would be RUN mode)
- now look at some flash memory with "md 50000 b 32" to display 32 bytes at the address 0x50000. Initially these will usually be all 0xff.
- Now change come with the command "sf 50000 l 55aaccee 4" which will write 4 long words to the flash (sf = storage fill)
- check they are there with "md 50000 b 32" - or md 50000 l 8" to see them as long words
- now erase the sector they are in with "se 50000" (se = storage erase - with no parameter for single sector; or "se 50000 3" to erase 3 sectors, etc.)
- again check memory with "md 50000 b 32" etc.

During all testing the USB device interface (with both clock sources) remains stable.

To check the results I also made a version that didn't move to the RUN mode on either the erase or write and these failed to modify flash (either a flash status error) when the HSRUN mode wasn't change to RUN but worked when it was changed.

However there is a problem in that although I change to the RUN mode I don't actually reduce the system clock speed but instead leave it at 120MHz. That means that RUN mode is run "out-of-spec" during the time that the flash operations are in progress. This works practically (as the versions show)  and also has the advantage that nothing is run out of spec when flash operations are not actually in progress.

Since I also have always avoided using HSRUN mode when flashing is needed (to avoid there various complications) I never tried reducing the speed during programming by switching between clock states (and the subsequent glitch problems for USB - at least when not run in crystal-less mode, which may still be reliable). If I find a few moments shortly i may have a go to see whether it causes both USB sources to glitch or not....

Regards

Mark

[myke_predko]

Hey @mjbcswitzerland 

Impressive work - I'll take your word that it works as I'm deep in trying to get some prototypes together for manufacturing (hopefully something to announce soon).  As I have a working solution (using the MK221M0Axxx) it's a distraction that I know will get me down in the weeds trying to understand how it works.  

I was aware that you can't change OUTDIV# in PEE mode (that's somewhat of an obvious approach to changing the System clock).  

I've been warned against using IRC48M by a couple of NXP (Freescale) FAEs over the years so I don't naturally consider it.  

Thanx for sharing!

myke

[myke_predko]

Hey @dennis_frie 

I ran into exactly your problem when prototyping for MK22FN1M0AVMD12 (which can do Flash writes with a clock speed of 120MHz) application but using the FRDM-K22F (MK22FN512VLH12 - which cannot do Flash writes above 60MHz).  I'm connecting to a host computer via USB and when I was updating Flash I wanted to change the clock speed to 60MHz, then when running the application, to make the prototyping as accurate as possible, I wanted to go to 120MHz.  

I was never able to do that successfully.  If you go back to around the start of this year, you can see the posts (with my frustration).  I ended up running my prototyping at 60MHz on the FRDM-K22F and am now porting it to the MK22FN1M0AVMD12 of my final product.  (Not a big deal because I'm writing a FreeRTOS application).  

I *think* if you want to run at 120MHz with Flash Writes at full speed, you're going to have to use the MK22FX512ALH12 to replace the MK22FN512VLH12.  Just did a quick search and the MK22FX512AVLH12 is quite a bit more expensive than the MK22FN512VLH12 - but at least you have that option.  

Good luck - let us know what happens,

myke