Hard fault on STM32L053

Sysprogs forums › Forums › VisualGDB › Hard fault on STM32L053

Log In Register Lost Password
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • October 6, 2019 at 18:37 #26051
    Johanan
    Participant

    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.
    October 7, 2019 at 04:23 #26055
    support
    Keymaster

    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.
    October 7, 2019 at 18:09 #26064
    Johanan
    Participant

    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.

    October 7, 2019 at 18:15 #26065
    support
    Keymaster

    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.

    October 7, 2019 at 19:35 #26067
    Johanan
    Participant

    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.
    October 7, 2019 at 19:55 #26070
    Johanan
    Participant

    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.
    October 7, 2019 at 20:20 #26072
    support
    Keymaster

    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.

    October 7, 2019 at 21:05 #26073
    Johanan
    Participant

    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

    October 7, 2019 at 22:17 #26076
    support
    Keymaster

    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
Log In Register Lost Password
Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.