MCU HardFault if not erased first

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MCU HardFault if not erased first

Jump to solution
1,434 Views
guitardenver
Contributor IV

I have the LPCXpresso54608 OM13092 evaluation board. 

I created a custom PCB with the LPC54605J256 MCU.

If I take a simple demo application such as the lpcxpresso54608_hello_world from the SDK 2.5.0, it works great on the eval board. But not on my custom PCB.

On the custom PCB the demo app runs just fine the first time around. I can load code and step through it like normal. Semihosting is working, it repeats everything I send to it like the demo is is supposed to do.

Then I use the terminate button to stop debugging (The red square button). Then in the Quickstart window I hit "Debug" in the "Debug your project" section. I then choose my JLink Ultra+ debugger and hit debug, it programs like normal, but then it goes straight to the HardFault handler. In this case the semihosting hardfault handler since I have that included.

I do instruction stepping mode to go through the assembly code that is in the hardfault handler. And it gets stuck on this line. No matter how many times I hit step, it stays here:

pastedImage_1.png

Debugging:

If I put a break point at the "ResetISR" in startup_lpc54608.c and start assembly stepping. It calls the CMSIS SystemInit() and this line causes a hardfault: With the image below, if I hit step one more time it causes the fault. 

pastedImage_2.png

One solution:
I found that if I erase the MCU first on the CUSTOM PCB, then debug, it works every time. If I use the following to erase:
pastedImage_3.png

Then debug, it works. 

I only need to do this on my custom PCB. I do NOT have to do this on the eval board. The eval board just works whenever I hit debug. Power cycling the custom PCB does not work either.

The only difference between my PCB and the eval board is that my PCB has the LPC54605J256 MCU instead of the LPC54608J512. I edited the memory regions to have the correct 256k flash and 136k RAM for my target and that did not fix it either.

Any ideas of what might be going on here?

MCUXpresso IDE v10.2.1 [Build 795] [2018-07-25] 

0 Kudos
1 Solution
1,187 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

I checked the bus fault access address at 0x20021FFC, which is SRAM3 location.

In fact, LPC54605J256 total SRAM size is 136KB, which includes SRAMX(32KB), SRAM0(64KB), SRAM1(32KB) and USB RAM(8KB), does not include SRAM2 & SRAM3.

pastedImage_1.png

Please check the project linker file and remove SRAM2 and SRAM3 memory range from system memory map.

Wish it helps.


Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
4 Replies
1,187 Views
guitardenver
Contributor IV

That was it. 

I changed the SRAM_0_1_2_3 to 136kB but forgot to subtract the SRAMX and USB RAM. I generated new linker file and did a clean build and it works now.

Thanks,

Matt

0 Kudos
1,187 Views
guitardenver
Contributor IV

Here are the hard fault status registers for Cortex M4 when the hardfault occurs.

pastedImage_1.png
pastedImage_2.png

I have to use the memory viewer because I can't access RAM with my code.

Here is a link to the CFSR @ 0xE000ED28 bit definitions. It looks like there is only a Bus Fault, so the BFSR applies

Cortex-M3 Devices Generic User Guide: 4.3.10. Configurable Fault Status Register 

It does say it is a BusFault. 

pastedImage_2.png

0 Kudos
1,188 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

I checked the bus fault access address at 0x20021FFC, which is SRAM3 location.

In fact, LPC54605J256 total SRAM size is 136KB, which includes SRAMX(32KB), SRAM0(64KB), SRAM1(32KB) and USB RAM(8KB), does not include SRAM2 & SRAM3.

pastedImage_1.png

Please check the project linker file and remove SRAM2 and SRAM3 memory range from system memory map.

Wish it helps.


Have a great day,
Mike

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,187 Views
guitardenver
Contributor IV

It seems like the hard fault occurs the first time RAM is accessed. It's like the SRAM clock never start or it's somehow protected.

I put in dummy code to test this in the ResetISR. I do a bunch of NOP instructions and it goes through all of those just fine. But then the first line that accesses RAM, the hardfault occurs.

pastedImage_1.png

You can see the line that causes it.

Why would erasing the MCU fix this and why does programming the chip a second time break it?


0 Kudos