STM32CubeMX for Nucleo-L476-RG base project

[albertobiancalana9]

Posted on March 15, 2016 at 14:58

Dear All.

I�ve recently installed STM32Cube MX 4.13.0 on both Ubuntu 14 and Windows 10, with the purpose of generating base code for my 

Nucleo-L476-RG equipped with MEMS sensors daughterboards.

I use SW4STM32 fully updated (Luna Build 20150219-0600) and example applications provided with STM32Cube and MEMS extension already compile and Run/Debug fine, with and without FreeRTOS.

I�having the following problem with STM32CubeMx on both Linux and Windows.

I create a new project and simply select Nucleo-L476-RG in the Board selector, with no middlewares (it�s ok for me a simple main loop to start) and I get the attached pinout view.

Then I configure the code generation settings for SW4STM32 and I get my project, which SW4STM32 imports and compiles correctly.

But when I start the project debug I never get to the main because the MCU is running on the infinite loop of line 134 of the startup code (STM32l476xx.s), probably something was wrong in the startup code or I forgot something. You can see the two attached images of SW4STM32 Debug window.

I expected that the STM32CUbeMX configuration for the Nucleo board was ready to run without need of adjustment. Is there anything I had to do before or is this a bug?

Thanks. any hint is appreciated, I really need to start quicly with STM32 for a new (of course very urgent) project.

Thanks in advance

White

#- #je-ne-l'aime-cube

[Tesla DeLorean]

Posted on March 15, 2016 at 16:13

This is the dumping ground for all unhandled interrupts. It is indicative that one or more IRQs has been enabled but there is not a matching IRQHandler.

If you are you using CPP, make sure you don't have a name mangling issue. Review the .MAP and compare to the IRQHandlers you have provided, and that they make it into the Vector Table

[albertobiancalana9]

Posted on March 15, 2016 at 19:57

Thanks for your help clive1.

I didn't supply irq handlers, my intention was to simply run the code produced by STM32CodeMx for the prebuilt

Nucleo-L476-RG base configuration, with the only main loop and without any SW and hw modification.

It is not easy for me go in such deep detail and understand where is the problem in vector table and compare .map file.

Anyway looking around here i found this thread that seems to be almost identical problem:

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Java%2FSTM32CubeMX%20V4%2E13%2E0%20problems&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&currentviews=405#{4DB18139-5388-4C4...

And as in that thread I was able to trace execution of system_stm32l4xx.c in stepping mode and verify that the system goes infinite loop just after instruction 114 bl __libc_init_array executes, as you can see in the attachment.

Is it possible it is the same type of bug?

Thanks

White

________________ Attachments : Debug4.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htb1&d=%2Fa%2F0X0000000aS4%2F9ohn_d48H0TrHgPl9Xv.jbUThwGqMEsOPCSzdu5YCkw&asPdf=false

[stm32cube-t]

Posted on March 16, 2016 at 11:10

Dear user,

Could you please confirm your problem is fixed after updating your ld file as follows: RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 96K Thanks

[albertobiancalana9]

Posted on March 16, 2016 at 14:00

Unfortunately the behaviour is the same.

xPSR register says that it is an hardfault (code 3).

I don't know how to find HFSR register in SW4STM32 to understand if it is a bus fault on vector table, can you suggest me where to find HFSR is DW4STM32, or what else I can do for help?

Thanks

[albertobiancalana9]

Posted on March 16, 2016 at 21:38

I confirm that the problem is an hardfault.

Based on a Hardfault diagnostic example that I found I implemented this hardfault handler which is called and (should) put the offending address in R1, giving 0xfffffff9 as a result.

void HardFault_Handler(void)

{

  __asm volatile (

    '' movs r0,#4       \n''

    '' movs r1, lr      \n''

    '' tst r0, r1       \n''

    '' beq _MSP         \n''

    '' mrs r0, psp      \n''

    '' b _HALT          \n''

  ''_MSP:               \n''

    '' mrs r0, msp      \n''

  ''_HALT:              \n''

    '' ldr r1,[r0,#20]  \n''

    '' bkpt #0          \n''

  );

}

Now the problem still exixts, where this problem come from, what can I do for help?

Thanks

White

[albertobiancalana9]

Posted on March 16, 2016 at 22:11

Sorry that was wrong I just deleted it

[stm32cube-t]

Posted on March 18, 2016 at 09:00

Dear user,

Unfortunately SW4STM32 IDE does not support yet the HFSR register. This is a limitation that we're working on solving. Best regards

[TarekB-ST]

Posted on March 22, 2016 at 16:20

Dear user, 

This is a CubeMx bug, you need to change RAM size as specified (96K instead of 128K) and change _estack value (0x18000 instead of 0x20000)

[stm32cube-t]

Posted on March 22, 2016 at 19:02

Please note STM32CubeMX 4.14 implements a workaround to the linker script issue on RAM descriptions: only RAM1 will be listed with 96k size. In a next release, both RAMs will be made available in the linker script.

Best regards