Hard fault on STM32L053

[Johanan]

I try to start a new project with STM32 L053 board (STM32 Nucleo).

Just a simple blink project for STM32L053R8  gangrened by VisualGDB.

I get hard fault at the startup code

__libc_init_array();

the disassembly:

SystemInit();
0x080005e8 bl 0x80003d4 <SystemInit>
__libc_init_array();
0x080005ec bl 0x80002b4 <__libc_init_array>

as soon as the bl 0x80003b4 is executed it jump to hard fault handler.

it looks like some compiler wrong setting, if I comment out this line the it happens elsewhere.

Maybe thumb mode is needed?

How to fix?

Thanks.

• This topic was modified 5 years, 1 month ago by Johanan.

[support]

Hi,

It’s hard to say for sure what is causing it, but we can suggest a few possible causes:

• Please double-check whether the code and stack location (evaluate $pc and $sp in the watch window) make sense (i.e. fit into FLASH and RAM of the device respectively). Please try locating the exact device name printed on the chip and double-check its datasheet. Accidentally selecting a different device while creating the project would lead to this type of error.
• Please try creating a “Blinking LED” project with the correct port settings (of an actual on-board LED), program it, verify the FLASH memory contents and try plugging the board into another power source to see whether the LED starts blinking. Sometimes unreliable JTAG/SWD connection, or unreliable power cause weird behavior similar to what you have described.

[Johanan]

Well, I connected an external 3.3V power to the board, same result.

In order to check I used MXCube and generated a Blink project for Keil.

Build the project with Keil (limited to 32K, but more then enough for this blinking LED), works without problems.

Now I started a new project in VisualGDB, and imported that working Keil project. Build it and try to run.

same Hard fault, at the same __libc_init_array();

I think the conclusion is clear, something bad in the toolchain for this STM32L053R8  (64K Flash).

Any Ideas?

Thanks.

[support]

As we have previously suggested, please double-check the values of $pc and $sp against the values shown in datasheet (or the values used by the Keil project). If they turn our incorrect, we should be able to easily fix it.

[Johanan]

Well, I think the SP is the  problem.

In Keil it is initialized to RAMBASE+0x408.

With GDB it is initialized to RAMBASE + 0x2000

Whoever the chip ram is only 8Kbyte, and max adr should be RAMBASE+0X1FFF  for the stack pointer. not 0x2000.

So the first call to a function creates the fault signal.

Can I just add

LDR R13 0x1FFF

somewhere  ? (I am not familiar with arm assembly)

Thanks

 

Attachments:

You must be logged in to view attached files.

[Johanan]

I tried to add these 2 lines:

asm(“ldr r0, =0x20001FFF”);
asm(“mov sp,r0”);

which changed the SP to 0x20001FFF, but it did not fix the problem.

I even tried 0x20000FFF, same problem.

So If the SP is decreased before anything is written, then 0x20002000 should be OK, and this is not the reason for the problem.

 

Johanan

• This reply was modified 5 years, 1 month ago by Johanan.

[support]

Thanks for checking the $sp value, it helped us factor out the most probable cause of this issue. RAMBASE + 0x2000 is actually correct (on ARM devices, $sp is decremented before pushing the value into the memory so that it will point at the latest value pushed in the stack, so pointing at exactly the end of RAM is correct).

We have done some further comparisons on our side and identified the problem. It turns out, the development branch of VisualGDB that included experimental support for the IAR compiler was incorrectly passing target-specific flags to the linker, so the linker chose an incorrect version of __libc_init_array().

We have fixed it in the following build: VisualGDB-5.5.1.3292.msi

Please rebuild your project after installing it.

[Johanan]

Yes  it is working now.

One of the longest blinking led project I ever did 🙂

Thanks for your support, that’s one more reason why I like VisualGDB so much.

Regards

Johanan

[support]

No worries. Unlike the stable v5.4 release, the development branch of VisualGDB (v5.5) is indeed less stable, some of new/changed functionality has been fully tested yet. That said, as long as we receive sufficient details in order to pinpoint/reproduce the issues, we are usually able to release fixes relatively fast.

[Author]

Posts