Startup File not Compiling/Linking Correctly

[smadeux]

I’m trying to port a C++ project from IAR to GCC. I’m using VisualGDB with Visual Studio 2022 and arm-eabi GCC 10.3.1. This project is for an STM32h743II.

My bootloader was not finding the application, so after some debugging, I found out that the spot in the application hex file where the startup file code should be is filled with 0x4770BEFF. All of the address where, according to the map file, the interrupt handlers should be are filled with this. (See attachment)

I made a couple of changes to the startup_stm32h743xx.c file because of some errors I was getting. I’ve attached the file below. The changes I made were:

• replacing ‘&’ with ‘(void *)’ on lines 1363-1527
• adding ‘extern “C”‘ on lines 10 &1531

I don’t get any compilation errors now, so I’m wondering if there are any ideas as to why this might be happening or how to debug the problem.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Porting the project from IAR to GCC could be indeed non-trivial due to the differences between the compilers. If you are not familiar with the GCC/IAR internals, we can gladly walk you through the necessary steps via our consulting service. Feel free to contact our sales to get a quote.

If you would like to tackle the problem yourself, we would advise checking the memory layout in the Embedded Memory Explorer (and map files), disassembling the entire images via arm-none-eabi-objdump, or configuring VisualGDB to stop at the entry point (VisualGDB Project Properties -> Embedded Debug Tweaking) and stepping through the startup code step-by-step

[smadeux]

I managed to figure out the problem. I turns out that the parts of the hex file that are filled with 0x4770BEFF are not actually junk like I thought they were. They’re actually just the default interrupt handlers. My program was hitting some of the handlers and I hadn’t added any thing to tell it where the real handlers were. The solution was just to add the handler names with ‘extern “C”‘ at the top of the file so that the program knew not to use the default interrupt handlers.

[support]

Good to know it works. Indeed, a missing extern “C” is a common cause for hard-to-track errors when using C and C++ code together. In case anyone else runs into similar issues, we have a detailed tutorial explaining it here: https://visualgdb.com/tutorials/tips/externc/

[Author]

Posts