stm32-for-vscode: The warning(error) message in output is mixed up

First, thanks to your great work. It’s much better to work in VS code than CubeIDE.

Window 10 Pro 21H2, VScode 1.67.2 Shell is set as “Command Prompt”

When I build a project, if there were some warnings or errors, the output looks mixed with some other text.

"c:/Users/lq/AppData/Roaming/Code/User/globalStorage/bmd.stm32-for-vscode/@xpack-dev-tools/arm-none-eabi-gcc/11.3.1-1.1.2/.content/bin/arm-none-eabi-gcc" -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DSTM32H723xx -DSTM32_THREAD_SAFE_STRATEGY=4 -DUSE_HAL_DRIVER -ICore/Inc -IDrivers/CMSIS/Device/ST/STM32H7xx/Include -IDrivers/CMSIS/Include -ID ivers/STM32H7xx_HAL_Driver/Inc -MyWork/Src/MBI5040Spi.c:I rivers/STM In function '32H xx_HAL_Driver/Inc/LeSendCmdga y -IMidd':
lew reMyWork/Src/MBI5040Spi.c:251:26:s/ hi rd_P   y/FreeRTOS/Swarning: ou ce/CMSIS_RTOS_V2passing argument 1 of ' -I iddlewares/Third_SendDataP rty' from incompatible pointer type [/F eeRTOS/Source/include -IMiddle-Wincompatible-pointer-typeswa es/Third_Party/FreeRTOS/Source]
  251 |                 SendData(/p rtable/GCC/ARM_CM4F -IMyWork/Inc -Og -Wall -fdata-sections -ffuncti&sCommando -sections -g -gdwarf -ggdb, (int)cmd);
      |                           - MD -MP ^~~~~~~~~- F"bui
      |                          ld/  Printf.d" -Wa,-a,-ad,-alms=build|/ yPrintf.lst MyWork/Src/MyP
      |                          rin f.c -OSPI_RegularCmdTypeDef *o build/MyPrintf.o

MyWork/Src/MBI5040Spi.c:207:27: note: expected 'uint8_t *' {aka 'unsigned char *'} but argument is of type 'OSPI_RegularCmdTypeDef *'    
  207 | uint8_t SendData(uint8_t *_pBuf, int _len)
      |                  ~~~~~~~~~^~~~~
"c:/Users/lq/AppData/Roaming/Code/User/globalStorage bmd.stm32-for-vscode/@xpack-dev-tools/arm-none-eabi-gcc/11.3.1-1.1.2/.content/bin/arm-nMyWork/Src/MBI5040Spi.c:o e-eabi-gcc" -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DSTM32H723xx -DSTM32_THREAD_SAFE_STRATEGY=4 -DUSE_HAL_DRIVER -ICore/Inc - In function 'IDr vers/CMSISpiWriteS Device/ST/STM32H7xx/Include -IDrivers/CMSIS/Include -IDrivers/STM32H7':
xx_ AL_Driver/Inc -IDrivers/STM32H7xx_HAL_Driver/Inc/Legacy -IMiddMyWork/Src/MBI5040Spi.c:261:1:le ares/Third_Party/Free RT S/Source/CMSIS_RTOS_V2 -IMiddlewares/Third_Partywarning: / reeRTOS/Source/include -IMiddlewares/Third_Party/FreeRTOS/Source/portable/GCcontrol reaches end of non-void function [C/ RM_CM4F -IMyWork/Inc -Og -Wall -fdata-sections -ffunction-secti-Wreturn-typeo s -g -gdwarf ]
  261 | -g db -MMD -MP -MF"build/RingBuffer.d" -}Wa -a,-ad,-alms=build/
      | Ri gBuffer.lst MyWork/Src/RingBu^ff r.c -o build/RingBuffer.o

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 16 (8 by maintainers)

Commits related to this issue

Most upvoted comments

Great to hear that this solves the issue. I will tackle this by adding the option to add make flags. As this feature is only supported for make 4.0 which is not the default for most OSX and Linux installations it could potentially break a lot of builds if it was not added as a default. For the coloring of the output. I think this is more by accident because of the output mixing than anything else as as far as I know arm-none-eabi-gcc does not color its output.