lpc4370 hard fault in SystemCoreClockUpdate()

[smarty760]

Hi, 

I am trying to use the M0APP with multicore programming on the LPC4370. The M4 project activates the M0APP project as expected but I am now getting a hard fault SystemCoreClockUpdate() function. I debugged and saw the problem specifically happens inside the Chip_Clock_FindBaseClock() function. 

Does anyone have any suggestions to solve this problem?

Is there a guide to understanding hard faults?

[Alice_Yang]

Hello @smarty760 

About "Hard Fault", you can have a look at:

https://www.keil.com/appnotes/files/apnt209.pdf  

https://mcuoneclipse.com/2012/11/24/debugging-hard-faults-on-arm-cortex-m/  

It seems the issue on your case is clock, recommend you check clock configuration, and also test demo under LPCopen first.

BR

Alice

[smarty760]

Hi, 

I am using MCUXpresso IDE and I went to Clocks Tool to try to check the clock configuration. I then got a "The selected project is not based on MCUXpresso SDK" error. I am not sure what this means.

I have tried the "multicore_blinky_m4", "multicore_blinky_m0app" and other similar similar examples posted on the forums and I never got a clock problem. I would insert my code into the example and after I try to debug this, the clock becomes an issue. 

[Alice_Yang]

Hello @smarty760 

1) Yes,  Clocks Tool  doesn't support legacy products lpc43xx.

2) "I tried commenting out the code in the Chip_Clock_GetRate() but, when debugging with stepping line by line, the function is still being debugged as if it was not commented out."

->> There is issue in your project. Delete .metadata folder under MCUXpresso IDE workspace,  then re-compile and debug your project again.  Also can create a new project or development based on example under LPCopen.

BR

Alice

[frank_m]

While the interface is AFAIK standardized in CMSIS, the actual implementation is MCU specific, and usually provided by the vendor.
These are usually the functions SystemInit() and SystemCoreClockUpdate(), provided in system_<MCU name>.c., at least for all Cortex M MCU families I use to work with.

So obviously, the code must match the MCU (or MCU family). Pulling said file from another project for the same MCU should work.
Though I would check the source code. Often it contains several specific code sections, enabled/disabled by MCU-specific type #defines. I would suggest to single-step through the code, and check that only relevent/proper code is executed.

By the way, when I happen to have such a problem, the code usually already fails in SystemInit(), which is called from the startup code before main().

[smarty760]

Hi,

The SystemCoreClockUpdate() is in the first line of code in the main. Even if I commented this out the Chip_Clock_GetRate() within the SystemCoreClockUpdate() code is called in other parts of the code. Maybe it is worth mentioning that the code im trying to copy worked on the lpc43S67 instead of the lpc4370 I am working on now. However, I am not sure how the first line of code in the main would be affected by the code that is used after it in the debug session. 

I tried commenting out the code in the Chip_Clock_GetRate() but, when debugging with stepping line by line, the function is still being debugged as if it was not commented out.

[frank_m]

First I must say that I have no actual experience with the LPC43S67 nor the LPC4370 MCUs.

> I tried commenting out the code in the Chip_Clock_GetRate() but, when debugging with stepping line by line, the function is still being debugged as if it was not commented out.

This is usually a sign that your project setup or debug setup is incorrect or corrupted.
Perhaps it is just out of sync, and a clean/rebuild helps. Because Eclipse projects tend to be somewhat opaque and messy, I often end up creating a fresh project.

Try a simple test here: insert a line containing "#error <some text>" in the source file, and rebuild.
If it doesn't throw an error, you probably have multiple copies in your project.

Onother example of a negative experience I made with Eclipse :
Files (*.c/*.h) are implicitely included in the build and compiled/linked, even if they are only added to a folder a project happens to be located in, and are not explicitely added to the project. This might also happen when you copy a folder from one project to another.
I consider this a critical bug, and one of the reasons I switched to Segger Embedded Studio for my private projects.

> Maybe it is worth mentioning that the code im trying to copy worked on the lpc43S67 instead of the lpc4370 I am working on now.

I don't know if these two MCUs are compatible on that level.
A simple way to check would be to fetch a SDK example for both of them, and compare the implementations of said functions.