Hi,
Because of the chip shortage we had to switch from the MK26FN2M0VLQ18 to the MK24FN2M0VDC12. As we ported our software across we ended up with an incredibly odd problem whereby we get hard faults caused by an LDR instruction not executing properly (was able to pinpoint the address and behavior) and also other, more random, hard faults.
When reducing the flash clock from 24MHz to 20MHz, these problems stopped. ADC readings also seem to be significantly noisier than on the previous chip, now requiring averaging.
Is there anything logical that would explain this behavior? Or any way to confirm the flash clock was indeed running at 24MHz and not at a higher speed?
Thanks!
In order to have some sort of conclusion on this. After reducing the Kinetis flash clock to 20MHz (from 24Mhz, confirmed using an oscilloscope), the hard fault disappeared. After further investigation into another issue (noisy ADC readings) we believe the problem is actually the design of the chip's power supply lines. Instead of a 3V3 plane with decoupling capacitors close to the pins themselves, our design has a single trace running from all the 5 supply pins to the outside of the chip and then the decoupling capacitors are all placed in parallel there.
We're currently doing another design iteration to confirm that was indeed the problem. Will update this post when that happens. Thanks for your help!
Hi
fnClkout(FLASH_CLOCK_OUT);
will drive the flash clock onto the CLKOUT. On the K24 this is, by default, PTC3.
In case that is not suitable for the HW there is the alternative:
#define CLKOUT_ON_PTA will put it on PTA6 instead.
You can then directly measure the Flash clock to be 100% sure that the issue is not due to a mis-configuration.
Regards
Mark
Thanks for the tip! When the clock is set to 20MHz, it seems quite stable, with the occasional spike to 20.8 (highest I've seen). When set at 24Mhz (divider set to 5), I'm getting 23.3-24.2 with the occasional spike to 25 (and probably slightly above for a brief moment).