K24f random hard faults!

[ashesman]

Hi,

I have an odd problem!  I have migrated a project from K22 to K24 on custom hardware.  For some reason the K24 has a hard fault for no apparent reason sometimes during startup (C startup and initialisation before main is called).  Sometimes it makes it past this and breaks at the start of main.  If I run the code from there it may or may not run continuously, or it will have the same hard fault.  If it does make it to main, then I single step through all off my initialisation code then let it run continuously in the main loop it will not trap!

This has me buggered!  I thought clock setup but after a reset it is back to default settings.  It is not due to my code I don't think as it traps during the C init sometimes.  Before my code is called and with default clock setup.

I did notice during debugging that sometimes the clock setup registers are not written to correctly and when read back for clock rate determination they give the wrong values!  But again, this is only after it has made it past startup code!

The trap it has is UNDEFINSTR.  This occurs intermittently say 60% of the time. But the code path followed during startup is identical each time!

Any ideas appreciated...

Cheers

Ashley

[ashesman]

SOLVED:  Problem was that the JLink debugger was still set for the K22F.  Changed to K24 and all my problems (well the hard fault ones!) went away!!!

[mjbcswitzerland]

Hi

Two things come to mind:

1. You enable a peripheral and immediately use it although it may take a short time to actually become ready. This means that after the hard fault the code manages to continue since it is then ready. My feeling is that this is probably not that likely in your case though.

2. You are setting up clock sources and the main clock dividers in the wrong order. For example the clock dividers are as out of reset (eg. system clock, flash clock and flexbus dividers at 1). You then set up the PLL to run the clock at a high speed and "then" you set the bus dividers.
This gives a short period of time where the flash (for example) is running out of specification.
When the flash speed is out of spec it is a bit random (although even slightly too high will quite quickly lead to a random value being read and thus random behavior, including weird instructions and subsequent faults).
A short period of running a clock out of spec. may be survived but (especially the Flash clock) not always....

Regards

Mark

[ashesman]

Hi Mark,

This problem occurs while the clocks are still in reset state.  It happens during the C startup code before even my main function is called (where I setup clocks using MCUxpresso generated clock init code).  In fact, I have disabled all clock changes completely now and just run in reset state all the time until I solve this problem.

Oh, and another side note, I loaded the exact same code (without even changing target type etc) onto a K64 dev kit and it runs perfectly and never has a hard fault!

So, that suggests to me something is not configured correctly in the startup code (although I don't see any configuration code, just memory initialization) OR there is something dicky about our hardware.  The micro seems to be correct and has good power and ground etc on all the right pins!

Thanks

Ashley

[mjbcswitzerland]

Ashley

Two years ago I was involved with a K22 based product that has some unreliabilities - I was remotely supporting the SW so never saw the board physically.

I did however once do remote debugging and found that if I didn't allow the Flash clock to be set higher than about 21MHz it ran OK but as soon as it was set to run at more than that (but still within spec.) it would randomly hard fault with "wild" reasons.

They ordered new prototypes from a different manufacturer (they did say they were not convinced by the manufacturing quality) and then the problems were also gone. No idea what the difference was though.....

Maybe you could divide the Flash clock (it is probably running around 20.97MHz out of reset) immediately to see whether this changes anything?????

Regards

Mark

[ashesman]

Good suggestion.  I will look into that.  I am still having the same problem.  this morning it was exactly every second time I started debugging that it trapped!  I run the flash clock at 20MHz after I set the clocks but was not sure of the init speed.  Not hard to change the OUTDIV4 divider right at the beginning of startup and see what happens.  I will give it a go later and see how I get on.