Sysprogs forums › Forums › VisualGDB › ARM project creation
- This topic has 7 replies, 2 voices, and was last updated 5 years, 11 months ago by support.
-
AuthorPosts
-
December 12, 2018 at 21:21 #23034MystikReasonsParticipant
When I create a program with VisualGDB for the ARM toolchain it isn’t creating every file I needed.
My example: I created a default blink project with HAL with the microcontroller: STM32F411RE
It comes with the device-specific files (HAL*.h*), stm32.props, stm32f4xx_hal_conf.h, device_specific_file (HAL*.c*), LEDBlink.c and the system_stm32f4xx.c
If I now try to initialize my own I2C HAL and start the debugger it jumps into the startup_stm32f11xe.c on line 23 and the comment in the function (see screenshot #1): //If you hit the breakpoint below, one of the interrupts was unhandled in your code.
//Define the following function in your code to handle it:
// extern “C” void HardFault_Handler();If I now create the same project with the same parameters in uVision5 I get more files: stm32f4xx_it.c & stm32f4xx_hal_msp.c (see screenshot #2 – I didnt include my own i2c and bm280 files so don’t worry about them not showing up)
In the stm32f4xx_it.c are many handlers defined also the HardFault_Handler in which I get stuck in my VisualGDB project cause its not existing.
Is this a bug that this file isn’t being created in VisualGDB?
And if this is a bug are there other files which are also not being created and are also other microcontroller affected by this “bug”?
Attachments:
You must be logged in to view attached files.December 12, 2018 at 21:28 #23037MystikReasonsParticipantUpdate: Tried to add stm32f4xx_it.c e and got two errors: main.h and stm32f4xx_it.h are also missing (VisualGDB is also not creating this file)
- This reply was modified 5 years, 11 months ago by MystikReasons.
December 12, 2018 at 22:15 #23044supportKeymasterHi,
Are you using the GCC ARM toolchain or the Keil ARM toolchain (that is supported since v5.4 Preview 10)?
December 12, 2018 at 23:44 #23045MystikReasonsParticipantI’m using the GCC ARM toolchain
Question on the side: What does the adress mean in the “Inline GDB Stub Output” window?
And is there an option to see whats in the adress?
Example: halted: PC: 0xffffffffe
- This reply was modified 5 years, 11 months ago by MystikReasons.
December 13, 2018 at 00:05 #23047supportKeymasterHi,
The files you mentioned are generated by the STM32CubeMX tool and can be imported into VisualGDB as shown in this tutorial. They are indeed not a part of the basic project templates.
The “Inline GDB Stub Output” window contains text sent to the gdb session by the gdb stub (e.g. OpenOCD or Segger J-Link) and typically contains error and warning messages (sometimes repeating the regular stub output).
You can use the Memory window to view the memory contents at a specific address.
December 14, 2018 at 10:17 #23058MystikReasonsParticipantHello,
Thank you for the link for the tutorial now they are being created and I dont have the error anymore.
Why aren’t they part of the basic project templates? Aren’t they necessary files?
And thank you for the explanation about the function of the “Inline GDB Stub Output” window.
December 14, 2018 at 14:18 #23060MystikReasonsParticipantMy problem right now is that I cant create a C++ project with STM32CubeMX but with VisualGDB I can.
So I always have to add the missing files manually
December 14, 2018 at 19:22 #23062supportKeymasterHi,
VisualGDB-generated projects contain all necessary code inside the main .c or .cpp file, hence they do not need separate _it.c and main.h files.
If you get errors due to missing _it.c file, most likely you have replaced the main source file with the main file from another project that also includes the _it.c and main.h files. If this is the case, please ensure you copy ALL the relevant files from the project you are trying to import.
-
AuthorPosts
- You must be logged in to reply to this topic.