AnsweredAssumed Answered

LPC824 project hard faults in clock_config.c

Question asked by Ben Burch on Jul 3, 2019
Latest reply on Aug 9, 2019 by Ben Burch

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

Outcomes