TWR-K65F180M - Random Hard Fault

[benjaminsanda]

Hi,

We're developing a custom bootloader for the k65 using the TWR-K65F180M tower board for development. We're currently trying to get the platform up but are running into an issue where the board randomly hard faults. The following steps are performed:

- Disable watchdogs, MPU, and FPU 

- Bring up an initialize clocks based on external 16 MHz clock source. Enter PEE mode.

- Enable Port A for LED control and set pins/directions

- Update VTOR to point to ram vector table (aligned as indicated in the Cortex M-4 manual)

- Enter main

- Enter infinite loop that blinks an LED and counts each loop increment.

What we observe is that the loop runs for a bit, and then randomly we get a hard fault (0x3) and vector off to the handler. The count of the loop counter when we get the fault is always different, but it's always a hard fault, and the PC is always pointing to the instruction which would occur after the infinite loop (it shouldn't ever be reached), and it's misaligned to the next half word boundary. The CFSR register indicates the IACCVIOL fault but we can't seem to track anything down.

We're using the Seger J-Link pro to debug, in the single wire interface mode. We're using SW mode as there was something wrong with the TWR-K65F180M and JTAG mode according to some posts (you had to populate some 0 ohm resistors to get it to work). Could the debugger be causing this?

[ashesman]

Did you ever get this resolved?  I have a very similar problem on K24...

[BlackNight]

Just a thought: I had in the past some 'random' hard faults too. And the reason was an unstable power supply. Maybe worth to check.

[mjbcswitzerland]

Hi

If there are random hardware faults in a forever loop I would suspect that something is being run out of specification (Flash clock speed too high, CPU > 120MHz without setting HIGH SPEED RUN mode, etc.)

To save time with a boot loader you can also look at:
http://www.utasker.com/kinetis/TWR-K65F180M.html
which includes Ethernet, SD card, memory stick, USB FS and USB HS Kboot, MSD, CDC, UART loaders, a TWR-K65F180M and K65 (approx.) real-time simulator. The simulator will already detect errors in configurations and allows much faster and accurate development, modifications, extensions, debugging etc. compared to the traditional IDEs.

Regards

Mark

[benjaminsanda]

Mark,

Thank you for the suggestions. I looked at the uTasker code, and verified all our clock modes. We're running of an external 16 Mhz, which is sent to the PLL to generate 120 MHz, then divided out to the system clock at 120 MHz, bus and flex bus at 60 MHz, and flash clock at 24 Mhz. I've tried dividing things down further but we still get the same issue. We're developing our own bootloader as this has to be minimal and certified by the client to meet regulations so we can't easily use a pre-developed suite. 

[mjbcswitzerland]

Hi Ben

There is also the "Bare-Minimum" Loader in the project that occupies less that 2k of space:
http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf

It allows fail-safe remote uploads with authentication and optional encryption. With a 10 year track record on many platforms including Coldfires, LPCs, AVRs, Luminary and ST processors, as well as 5 years track record in many Kinetis based products it may still be a good option for your client since it is already documented and proven.

It is always tempting to say that starting a new design from scratch will result in a higher optimisation and improved reliability but that is also the downfall of many a developer too....;-)

Regards

Mark