K22F flash memory speed

[jacquescharreyr]

Hello,

I have a strange behavior on my K22F custom board. I can not run flash memory at full speed.

Let me explain a little bit what we did :

     We have developped a test program thanks to the FRDM K22 dev board. It works OK with core @ 12OMHz bus @ 60 MHz and flash @ 24 Mhz (Divisor = 5)

     Then we switched to our production board :  We can only run the test program with core @ 12OMHz bus @ 60 MHz BUT flash at @ 17 Mhz.(Divisor = 7)

     (With the P&E debugger we saw corrupted memory readings)

We are still investigating our hardware layout (power, decoupling capacitor ...) but we are very close to the FRDMK22 design.

Does anyone encountered this strange issue before?

Thanks for your help.

Yours,

Jacques

[egoodii]

Are there any actual symptoms of 'does not run'?  Or is it JUST that the debugger has 'reading' trouble?  Is there a test sequence?  What happens if you just put some 'startup delay' in your code prior to setting your clock speed?  Where I am going is wondering if slowing the Flash clock inherently allows a delay you may need for 'some other reason'.

One thing I would particular look at is your hardware's startup sequence.  That is, left to its own devices, Kinetis will start running at something less than 1.8V.  If you have a clock source that is an oscillator, for instance, you might have to wait until your supplies are 'much closer to their final voltage' before you can switch-over.

[mjbcswitzerland]

Earl

I can add a little more information since I did some remote debugging on Jacque's board.

1. The problem is not related to powering on the board (voltages) - it is reproducible after every software reset with stable 3.3V bench power supply.

2. Two SW versions were tested - a blink LED program generated by PE (setting maxium clock speeds) and the uTasker loader (also setting the same clock speeds). In both cases the error behaviour is identical.

3. The same happens with or without debugger (in terms of overall board behaviour).

4. In both cases reducing the Flash clock (all others left the same) to 17.14MHz (divide set to 120MHz /7) allows both SW to run normally. That is, the RUN LED is seen flashing at the correct rate and it reliably continues to run for long periods of time.

5. In both cases the divides set to 120MHz / 5 = 24MHz Flash clock doesn't allow the board to run.

6. In both cases with the divide to to 120MHz / 6 = 20MHz the software starts but "crashes" after a short time - usually after several hundred ms or so there may be a few LED flashes and then it dies.

7. With the debugger attaxhed/used the behaviour is the same.

8. When testing the clock initialisation with the debugger the crystal and PLL lock as normal and the code can subsequently be stepped. With 17.14MHz Flash clock stepping works "forever" and the board can be left to run, paused with the debugger etc. with no issues.

9. Repeating 8 with the Flash clock set to 24MHz everything seems fine initially but if a run is allowed there will be a "random" error interrupt. It will show, for example, a hardware error interrupt at a line of code that is perfectly normal. When repeated 10 times the line that errors will always be a different one. The results are equivelent with both SW programs tested.

10. What is sometimes seen is that the disassember shows a stange value for instructions - eg. 0xfffffffe is displayed at a line of code. When refreshed, the instruction is correct again. This leads to the suspicion that the Flash is not read reliably and also prompted checking what happens with reduced Flash clock speed, which subsequently showed that it does solve the issue when set to 17.14MHz and 'improves' the situation at 20MHz, but it is still not fully reliable, whereby at 24MHz it is 'very' unreliable.

11. The same two SW run on the FRDM-K22F board at 24MHz Flash clock are reliable.

12. The K22 device on the custom board (and also in an adapter with only power supply and clock attached) can only be operated at 17.14MHz Flash clock speed (with both SW) although the MASK of the K22 is identical in each case.

The plan is to first test K22 from other batches (ordered from other sources) to try to identify whether it could be a problem with a few devices. If there are still issues there must be a problem with the hardware, although it seems that the power supply is solid and there are the normal decoupling capacitors close to the chip. Basically it is the same as the Freedom circuit.

Jacques: please could you run the uTasker loader code with the Flash divider set to 7? Then measure the exact frequency of the LED flashing - it should be exactly 5Hz (100ms on/100ms off).

If the frequency is faster it would mean that the PLL is in fact higher than expected, and thus also the Flash clock higher.

A possibility is that your crystal is oscillating faster than expected (eg. on a harmonic overtone) or is simply not the expected frequency.

Checking the bus speed (controlling the blink interrupt rate) is something that we didn't specifically do!

Regards

Mark

Kinetis: µTasker Kinetis support

K22: µTasker Kinetis FRDM-K22F support / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[Hui_Ma]

Hi,

That's really a strange issue. For the Flash clock up to 25MHz, How many boards/chips with that strange behavior?

And if customer could run it with default MCG clock mode, FEI mode, which internal core clock frequency is about 20.97MHz.

If the Flash works normally with the default clock mode?

Thank you for the attention.

Have a great day,
Ma Hui

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