LPC824 project hard faults in clock_config.c

[bburch]

Hi!

I am having a very odd problem, and I am hoping somebody has seen this one before.

I am doing a bare metal project on an LPC824.

We recently moved the project from the dev board to the prototype.  In doing so we changed some clock settings to derive the clock from the 16MHz crystal.

After doing so, we then rebuilt, loaded our code onto the target with a J-Link box, and proceeded from the start breakpoint.

We then hard fault in BOARD_BootClockRUN from clock_config.h

The offending code; 

    CLOCK_Select(kCLKOUT_From_Irc);                         /*!< select IRC for CLKOUT */

If we breakpoint just before this call, and then do a step over, we immediately fault.

If we step through the call, however we do not fault!

That call is immediately preceded by turning on the main clock;

    CLOCK_SetMainClkSrc(kCLOCK_MainClkSrcSysPll);         /*!< select syspll for main clock */

If I comment out the SetMainClkSrc call, keeping the default internal rc clock everything is fine also.

I've seen issues on other micro controllers where a change in the clock mode caused a bad instruction fetch, but since we were halted at a breakpoint right after the SetMainClkSrc, the clock should have been stable.

And also oddly, this seems to work OK on one of our development computers but not on another.

The one it works on is a Windows 10 Laptop.  The one that has problems (my machine of course) is a MacBook.

I have tried this on the MacBook both in MacOS and in Parallels Windows 10, and both have the same failure mode.

For the test under parallels, I re-installed MCUXpresso v11 and re-downloaded the SDK and installed it.#

We are mystified by this.  Any ideas?  

Thanks SO MUCH!

-Ben Burch

BTW Controls

[bburch]

OK, so, bumping this - has anybody else seen this problem?  I suspect some sort of hardware bug here.

[xiangjun_rong]

Hi, Ben,

Currently, I think the main problem is to locate which line leads to the hardfault,     CLOCK_Select(kCLKOUT_From_Irc);   or   CLOCK_SetMainClkSrc(kCLOCK_MainClkSrcSysPll);    ?

I suppose that the PLL configuration is incorrect which leads to the issue, if you select for example IRC as the main clock, is there issue?

BR

XiangJun Rong

[bburch]

Any thoughts on this?

Thanks!

-BenB

[bburch]

I'll set that condition up and report back later this morning.  Thank you for the suggestion!

-Ben Burch

BTR Controls

[bburch]

OK, actually I got right to that.  When I set the clock from kCLOCK_MainClkSrcIrc it does not fail, though of course all of my multipliers are wrong.

I also find that if I remove the CLOCK_SetMainClkSrc to the END of BOARD_BootClockRUN, and use the kCLOCK_MainClkSrcSysPll there, then everything works and it comes up with all the dividers set correctly.

So that is a work-around for now, but I am very reluctant to accept this as a long term fix as the clock_config.c file is a generated file, and so could be accidentally changed in maintenance activities in the future.

Also, the fact that this works differently on different development hardware is a worry and appears to be some species of timing-based issue.

Any thoughts on this?

Thanks so much!

-Ben Burch

BTR Controls