Forum Replies Created
-
Posts
-
Looks like there is a library problem regarding FPU support :
VisualGDB (GCC 7.2.0 GDB 8.0.1 rev 2) link against “1>attempt to open c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/lib/thumb/fpu/cortex_m4\libc.a succeeded” but fail at starting up.
While AC6 (GCC 6.3.1 GDB 7.10.1.20160923-cvs) link against “1>attempt to open c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.15.0.201708311556/tools/compiler/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard\libc.a succeeded” which works fine.
Obviously the supplied BSP falls short on hardware FPU support, even though allowing to select one specifically in the project’s ‘Property Pages / ARM Settings’.
OK, that’s it, returning to ‘arm-eabi-‘ makes the ‘HardFault_Handler’ to be invoked, even though it compiles just fine.
Reverting to AC’s toolchain.
Btw if you could stop adding ‘Device-secific files\startup_stm32l476xx.c’ each time I switch from one BSP to another, that would be super fine.
OK, with a great of patience I got it to work using the AC6 compiler (GCC 6.3.1 arm-none-eabi- / GDB 7.10.1.20160923-cvs).
Here’s the setting files to unzip into “c:\Ac6\SystemWorkbench\plugins\fr.ac6.mcu.externaltools.arm-none.win32_1.15.0.201708311556\tools\compiler\”
Now trying to revert back to VisualGDB supplied (arm-eabi-) toolchain to test if it still fails.
I selected AC6’s compiler as third-party toolchain, it switched to it by creating a new toolchain identified with a $(ToolchainID), adding the default BSP’s startup file to my project (without me asking for, since I already provide one), but removed $(ToolchainDir) macro. Any way to get the current toolchain folder which was asked when locating the ‘gdb.exe’ file ?
I changed some settings and it shows that the VisualBSP startup file is embedded without me wanting to :
1>VisualGDB/Debug/mcu__impl_stm32l4.o: In function `Reset_Handler’:
1>e:\…\mcu__impl_stm32l4.c(335): error : multiple definition of `Reset_Handler’
1>VisualGDB/Debug/startup_stm32l476xx.o:C:/Users/me/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32L4xxxx/StartupFiles/startup_stm32l476xx.c:945: first defined here
1>VisualGDB/Debug/mcu__impl_stm32l4__irq.o: In function `Default_Handler’:
1>e:\…\mcu__impl_stm32l4__irq.c(74): error : multiple definition of `Default_Handler’
1>VisualGDB/Debug/startup_stm32l476xx.o:C:/Users/me/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32L4xxxx/StartupFiles/startup_stm32l476xx.c:958: first defined hereBtw, the Eclipse BSP provides the “arm-none-eabi-x” GCC suite, while the VisualGDB provides the “arm-eabi-x” suite. That might perhaps explain something.
Also, when I want a MAP file to be generated, it is put inside the project folder, could it be possible to place it into the $(OutDir) like in Eclipse ?
When I ass the “-save-temps” flags into the “Command Line / Additional Options”, I get I and S files inside the project folder, could it be possible to place them into the $(OutDir) like in Eclipse ?
Since those are per build generated files, I don’t see the point of having them inside the project folder.
OK, tried replacing the VisualGDB generated ELF file (2.15MB) with the one from Eclipse (5.98MB) and it works indeed.
Starting debug using F5, Visual asks me if I want to rebuild, I select ‘No’, and it starts like expected into ‘Reset_Handler’.
Obviously symbols are read from the ELF file because Visual had no trouble remapping the imported ELF from Eclipse.
It appears that debugging the Eclipse ELF doesn’t trigger reading at weird addresses, hence this is the reason of the ‘HardFault_Handler’ being invoked.
Now I have to understand why the size difference (symbols lacking in the VisualGDB build ?) and the reason of reading at weird addresses.
Thanks for the reply.
1- different toolchain : I can understand a difference, but if that’s the reason of the bug, like file order, that’s getting tricky and not that much robust. Is there a way to change file order for compilation ?
2- switching ELF files : I’ll do that, but since the mapping is different, I bet I have to put my breakpoints a bit randomly to catch the right ‘Reset_Handler’. If that doesn’t work either, how should I modify the debug settings ?
3- weird memory location : I specified a STM32L476RC which memory is at 0x20000000 and length is 0x18000. With that information, there should be some kind of barrier to avoid the debugger accessing memory outside the valid range.
4- adding commands : cannot these commands be added to the debug UI of VisualGDB, much like the STLink or JLink debug interface under Eclipse ? If I have to add commands, is there a complete list and where to add it ?
Btw, is there a way to request VisualGDB for verifying download, init regs on start, stop reading at weird memory location like 0x1FFEFFFC (which in fact cause the ‘HardFault_Handler’ to be called) before any of my code to be executed ? See the logs…
In ‘Visual Studio/VisualGDB’, I am not using ‘OpenOCD’ but the ‘Segger JLink’ directly, I hope their STM32L4 driver to be up to date. To discard an issue out from ‘OpenOCD’, I copied the ‘AC6/OpenOCD’ into the ‘VisualGDB/OpenOCD’ and I get the same faulty behavior, so it is not an ‘OpenOCD’ problem.
I will check my ‘VisualGDB’ compilation options that might differ a bit from the ‘Eclipse’ compilation options.
Is there a way to import an ‘Eclipse’ project to ensure not forgetting any compilation option ?
Made a little video to show you what happens when I first try on Eclipse, then Visual in one shot, same target and same probe attached. Eclipse works, Visual not.
