cancel
Showing results for 
Search instead for 
Did you mean: 

Trouble Setting Up STM32 Development with VS Code on Zorin OS

akoluacik
Senior

I’m trying to set up STM32 development on Zorin OS using Visual Studio Code, but I’ve encountered some issues. Here's an overview of my setup and the problem I'm facing:

System Information:

  • OS: Zorin OS 17.2 Core(based on Ubuntu)
  • IDE: Visual Studio Code
  • Toolchain: ARM GCC (installed through apt)
  • Debugging Tool: OpenOCD
  • STM32CubeMX for project generation

I choose Makefile in Cubemx and it creates a project folder. I am opening it in VS Code, and open a terminal in it, write make and it yields:

 

 

~/Codes/ST/blinkyy/blinkyy$ make
arm-none-eabi-gcc build/main.o build/stm32f4xx_it.o build/stm32f4xx_hal_msp.o build/stm32f4xx_hal_tim.o build/stm32f4xx_hal_tim_ex.o build/stm32f4xx_hal_rcc.o build/stm32f4xx_hal_rcc_ex.o build/stm32f4xx_hal_flash.o build/stm32f4xx_hal_flash_ex.o build/stm32f4xx_hal_flash_ramfunc.o build/stm32f4xx_hal_gpio.o build/stm32f4xx_hal_dma_ex.o build/stm32f4xx_hal_dma.o build/stm32f4xx_hal_pwr.o build/stm32f4xx_hal_pwr_ex.o build/stm32f4xx_hal_cortex.o build/stm32f4xx_hal.o build/stm32f4xx_hal_exti.o build/system_stm32f4xx.o build/sysmem.o build/syscalls.o build/startup_stm32f411xe.o  -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -specs=nano.specs -TSTM32F411RETx_FLASH.ld  -lc -lm -lnosys  -Wl,-Map=build/blinkyy.map,--cref -Wl,--gc-sections -o build/blinkyy.elf
/opt/st/stm32cubeclt_1.16.0/GNU-tools-for-STM32/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld:STM32F411RETx_FLASH.ld:56: syntax error
collect2: error: ld returned 1 exit status
make: *** [Makefile:176: build/blinkyy.elf] Error 1

 

It seems this is because STM32F411RETx_FLASH.ld file. I do not understand how it is generated and what to do solve.

Due to the character limitation in a post and restriction of uploading files, I can neither upload my STM32F411RETx_FLASH.ld and Makefile files nor put them here. But if you want, I can upload it via Gist or any other way.

Please feel free notify if something is missing, or you cannot understand something. Any replies is welcomed to solve this problem since it is important for me.

Thanks for your replies.

3 REPLIES 3
Pavel A.
Evangelist III

> ld:STM32F411RETx_FLASH.ld:56: syntax error

It can be because of a known bug in generation of ld files. Until ST fixes it, check the ld file and correct the error manually. Generation of CodeIDE projects does not have this bug. You can generate for CubeIDE and take the ld file from there.

 

To address the issue you're encountering with the STM32 development setup on Zorin OS using Visual Studio Code, we need to focus on the linker script file STM32F411RETx_FLASH.ld and the Makefile. The error message indicates a syntax error in the linker script file, which suggests that there might be a problem with its content.

Here are some steps to troubleshoot and resolve the issue:

1. Verify the Linker Script File

First, let's check the STM32F411RETx_FLASH.ld file for any syntax errors. Since you mentioned that you cannot share the file directly here, you can upload it to a service like GitHub Gist and share the link. However, I can provide some general guidance on what to look for.

A typical linker script file for STM32 might look like this:

 
 
.ld
/* Entry Point */
ENTRY(Reset_Handler)

/* Define the memory regions */
MEMORY
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
  RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

/* Define the sections */
SECTIONS
{
  .isr_vector :
  {
    KEEP(*(.isr_vector))
  } >FLASH

  .text :
  {
    *(.text)
    *(.text*)
    *(.rodata)
    *(.rodata*)
    *(.glue_7)
    *(.glue_7t)
  } >FLASH

  .ARM.extab :
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } >FLASH

  .ARM :
  {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } >FLASH

  .preinit_array :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH

  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH

  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  .data :
  {
    _sdata = .;
    *(.data)
    *(.data*)
    _edata = .;
  } >RAM AT> FLASH

  .bss :
  {
    _sbss = .;
    *(.bss)
    *(.bss*)
    *(COMMON)
    _ebss = .;
  } >RAM

  . = ALIGN(4);
  _end = .;
}

2. Check for Specific Syntax Errors

Look for common syntax errors such as missing semicolons, unmatched braces, or incorrect memory region definitions. If you can share the specific line (line 56) where the error occurs, that would be helpful.

3. Validate the Makefile

Ensure that the Makefile is correctly referencing the linker script and that all paths are correct. The relevant part of the Makefile might look like this:

 

makefile
LDSCRIPT = STM32F411RETx_FLASH.ld

# Linker flags
LDFLAGS = -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -specs=nano.specs -T$(LDSCRIPT) -lc -lm -lnosys -Wl,-Map=$(BUILD_DIR)/$(TARGET).map,--cref -Wl,--gc-sections

# Link the object files
$(BUILD_DIR)/$(TARGET).elf: $(OBJECTS)
    $(CC) $(OBJECTS) $(LDFLAGS) -o $@

4. Re-generate the Project

If the issue persists, try re-generating the project files using STM32CubeMX. Ensure that you select the correct options for the linker script and Makefile generation.

5. Update Toolchain

Ensure that you have the latest version of the ARM GCC toolchain and OpenOCD. Sometimes, updating the toolchain can resolve compatibility issues.

Hello @Nawres GHARBI , thank you for your answer.

I first had tried @Pavel A. 's answer, and it worked fine. Then today, I have made a quick comparison between the .ld files generated by CubeMX and CubeIDE, and notice that RAM sections didn't specified. Then I have made a research and saw lots of people had this problem on 6.12.1 version.

Therefore, I have made an update and now everything is OK now.

Lastly, @Pavel A. thank you for your answer, too.