search

bmd-studio / stm32-for-vscode

STM32 extension for working with STM32 and CubeMX in VSCode
MIT License
195 stars 27 forks source link

The warning(error) message in output is mixed up #119

Closed char990 closed 1 year ago

char990 commented 1 year ago

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
jortbmd commented 1 year ago

Hi thanks for opening up an issue. It looks like it is dropping characters from the output. It might be that the integrated terminal can't keep up. Could you check if a diferent settings for the Gpu acceleration setting for the integrated terminal resolves the issue? It can be found in Settings>Features>Terminal>Integrated:Gpu Acceleration. On top of this could you also check if you have the same issue while usingh windows cmd or terminal? If you open the terminal in you project folder and type: make -j 16 -f STM32Make.make it should start the compilation and give the same kind of output. This helps me determine if it is something that needs to be resolved in VSCode or if this is something that is because of the way the generated makefile is formatted.

char990 commented 1 year ago

In vscode-Terminal setting, I have tried GPU : ON/OFF: same Detect Locale : ON/OFF : same Powershell/command: same

Open cmd from explorer, run C:\Users\lq\AppData\Roaming\Code\User\globalStorage\bmd.stm32-for-vscode\@xpack-dev-tools\windows-build-tools\4.3.0-1.1.content\bin\make -j 16 -f STM32Make.make same

"c:/Users/lq/AppData/Roaming/Code/User/ lobalStorage/bmd.stm32-for-vscode/@xpack-dev-tools/arm-none-eabi-gcc/11.3.1-1.1.2/.content/bin/arm-none-eabi-gcc" -x assembler-with-cpp -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DSTM32H723xx -DSTMyWork/Src/SerialPort.c:M3 _T In function 'HRE D_SAFE_SDCache_HAL_UART_Transmit_DMAT AT':
EGY 4 MyWork/Src/SerialPort.c:45:29:- US E_ ALwarning: _ RIVER -Ipassing argument 1 of 'Co e/SCB_CleanDCache_by_AddrI c -IDrivers/CMSIS/Device/ST/S' from incompatible pointer type [TM3 H7xx/Include -IDrivers/CMSIS/Include -IDrivers/STM32H7xx_HAL_Driver/Inc -IDrivers/STM32H7xx_HAL_Driver/Inc/Legacy -IMiddlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2 -IM-Wincompatible-pointer-typesi dlewares/Third_Party/FreeRTOS/Source/include -IMiddlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F -IMyWork/Inc -Og -Wall -fdata-sections -ffunction-sections -g -gdwar]
   45 |     SCB_CleanDCache_by_Addr(f  ggdb -MMpDataD -M, DMA_BUF_SIZE);
      |                             P  MF"^~~~~b il
      |                             d/ tar|tu _s
      |                             tm 2h723xxuint8_t * {aka unsigned char *}. " startup_stm32h723xx.s -o build/startup_stm32h723xx.o
jortbmd commented 1 year ago

Thanks for investigating. I don't think I will have a short term solution for this. However I will look into this. It might be a bit hard to reproduce this bug for me so when I have a possible solution I might need your help in testing it and I will let you know.

loicgillioz commented 1 year ago

Hello, I also do have the same issue on my side. Running make --file=STM32Make.make allows getting a clean output in the terminal. I am available if you need some help with troubleshooting.

jortbmd commented 1 year ago

Thanks for the offer! Could you tell me which OS, which version of VSCode and what you use as your integrated terminal?

char990 commented 1 year ago

Good news. I found the issue. Open "cmd.exe", then Ran "make -j 16 -f STM32Make.make", the output is not good, many issues. If I ran with "-j 4", the output is better than "16" , but there is a missing. Ran with "-j 1", the output is correct.

I tried the "make.exe" in STM32CubeIde, version: GNU Make 4.2.1_st_20200221-0903_longpath Built for x86_64-w64-mingw32

Same issue.

loicgillioz commented 1 year ago

Thanks for the offer! Could you tell me which OS, which version of VSCode and what you use as your integrated terminal?

image powershell for integrated terminal

jortbmd commented 1 year ago

Good news. I found the issue. Open "cmd.exe", then Ran "make -j 16 -f STM32Make.make", the output is not good, many issues. If I ran with "-j 4", the output is better than "16" , but there is a missing. Ran with "-j 1", the output is correct.

I tried the "make.exe" in STM32CubeIde, version: GNU Make 4.2.1_st_20200221-0903_longpath Built for x86_64-w64-mingw32

Same issue.

This makes sense. It is definitely a bug which stems from building the application in parallel. Will start to look into it.

Thanks for the offer! Could you tell me which OS, which version of VSCode and what you use as your integrated terminal?

image powershell for integrated terminal

Thank you I will start looking into it.

jortbmd commented 1 year ago

Found a possible solution. Could you try the following command to see if it still produces the same errors? make -j 16 -O -f STM32Make.make make -j 16 --output-sync=target -f STM32Make.make

loicgillioz commented 1 year ago

Weird, your options are not found on my installation. the -O is not found, i had to run : make -j 16 -f STM32Make.make result ⬇️ image

And the other command with --output-sync=target is also not valid, got 

PS C:\Users\loicg\Documents\Repositories\dryc_v2> make -j 16 --output-sync=target -f STM32Make.make
C:\Program Files (x86)\GnuWin32\bin\make: unrecognized option `--output-sync=target'
Usage: make [options] [target] ...
Options:
  -b, -m                      Ignored for compatibility.
  -B, --always-make           Unconditionally make all targets.
  -C DIRECTORY, --directory=DIRECTORY
                              Change to DIRECTORY before doing anything.
  -d                          Print lots of debugging information.
  --debug[=FLAGS]             Print various types of debugging information.
  -e, --environment-overrides
                              Environment variables override makefiles.
  -f FILE, --file=FILE, --makefile=FILE
                              Read FILE as a makefile.
  -h, --help                  Print this message and exit.
  -i, --ignore-errors         Ignore errors from commands.
  -I DIRECTORY, --include-dir=DIRECTORY
                              Search DIRECTORY for included makefiles.
  -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.
  -k, --keep-going            Keep going when some targets can't be made.
  -l [N], --load-average[=N], --max-load[=N]
                              Don't start multiple jobs unless load is below N.
  -L, --check-symlink-times   Use the latest mtime between symlinks and target.
  -n, --just-print, --dry-run, --recon
                              Don't actually run any commands; just print them.
  -o FILE, --old-file=FILE, --assume-old=FILE
                              Consider FILE to be very old and don't remake it.
  -p, --print-data-base       Print make's internal database.
  -q, --question              Run no commands; exit status says if up to date.
  -r, --no-builtin-rules      Disable the built-in implicit rules.
  -R, --no-builtin-variables  Disable the built-in variable settings.
  -s, --silent, --quiet       Don't echo commands.
  -S, --no-keep-going, --stop
                              Turns off -k.
  -t, --touch                 Touch targets instead of remaking them.
  -v, --version               Print the version number of make and exit.
  -w, --print-directory       Print the current directory.
  --no-print-directory        Turn off -w, even if it was turned on implicitly.
  -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
                              Consider FILE to be infinitely new.
  --warn-undefined-variables  Warn when an undefined variable is referenced.

This program built for i386-pc-mingw32
Report bugs to <bug-make@gnu.org>

EDIT

PS C:\Users\loicg\Documents\Repositories\dryc_v2> make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.

i am now changing my make path to your make version path

loicgillioz commented 1 year ago

Ok now coming back with the latest results:

So changed my make version to match yours, 4.3.90

running make -j 16 -O -f STM32Make.make, extract of result seems fine :

In file included from common/utils/ringbuf/ringbuf.c:8:
common/utils/ringbuf/ringbuf.h:229:53: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  229 | size_t ringbuf_max_contiguous_write(const ringbuf_t const rb);
      |                                                     ^~~~~
common/utils/ringbuf/ringbuf.c:336:44: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  336 | bool ringbuf_is_contiguous(const ringbuf_t const rb, size_t length_to_read)
      |                                            ^~~~~
common/utils/ringbuf/ringbuf.c:341:52: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  341 | size_t ringbuf_max_contiguous_read(const ringbuf_t const rb)
      |                                                    ^~~~~
common/utils/ringbuf/ringbuf.c:348:53: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  348 | size_t ringbuf_max_contiguous_write(const ringbuf_t const rb)
      |                                                     ^~~~~
fcntl(): Bad file descriptor
"c:/Users/loicg/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-m0plus -mthumb   -DSTM32L051xx -DUSE_HAL_DRIVER -I. -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/CMSIS/Device/ST/STM32L0xx/Include -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/CMSIS/Include -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/STM32L0xx_HAL_Driver/Inc -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/STM32L0xx_HAL_Driver/Inc/Legacy -Icommon -Og -Wall -fdata-sections -ffunction-sections -g -gdwarf -ggdb -MMD -MP -MF"build/re.d" -Wa,-a,-ad,-alms=build/re.lst common/utils/regex/re.c -o build/re.o
fcntl(): Bad file descriptor

running make -j 16 --output-sync=target -f STM32Make.make, extract of result is the same :

In file included from common/utils/ringbuf/ringbuf.c:8:
common/utils/ringbuf/ringbuf.h:229:53: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  229 | size_t ringbuf_max_contiguous_write(const ringbuf_t const rb);
      |                                                     ^~~~~
common/utils/ringbuf/ringbuf.c:336:44: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  336 | bool ringbuf_is_contiguous(const ringbuf_t const rb, size_t length_to_read)
      |                                            ^~~~~
common/utils/ringbuf/ringbuf.c:341:52: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  341 | size_t ringbuf_max_contiguous_read(const ringbuf_t const rb)
      |                                                    ^~~~~
common/utils/ringbuf/ringbuf.c:348:53: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier]
  348 | size_t ringbuf_max_contiguous_write(const ringbuf_t const rb)
      |                                                     ^~~~~
fcntl(): Bad file descriptor
"c:/Users/loicg/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-m0plus -mthumb   -DSTM32L051xx -DUSE_HAL_DRIVER -I. -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/CMSIS/Device/ST/STM32L0xx/Include -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/CMSIS/Include -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/STM32L0xx_HAL_Driver/Inc -IC:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/STM32L0xx_HAL_Driver/Inc/Legacy -Icommon -Og -Wall -fdata-sections -ffunction-sections -g -gdwarf -ggdb -MMD -MP -MF"build/stm32l0xx_hal_uart.d" -Wa,-a,-ad,-alms=build/stm32l0xx_hal_uart.lst C:/Users/loicg/STM32Cube/Repository/STM32Cube_FW_L0_V1.12.1/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_uart.c -o build/stm32l0xx_hal_uart.o
fcntl(): Bad file descriptor

So, kind of weird output with some fcntl(): Bad file descriptor popping. Overall the build process runs fine. Also not sure why it's not showing up in color in my vs code terminal. The output from the extension task is coloured but mixed up ⬇️ image

loicgillioz commented 1 year ago

I could isolate the error of mixed up output, by addind or removing the option -O it makes the whole difference

make -j16 -O -f STM32Make.make produces clean but uncoloured output

make -j16 -f STM32Make.make produces mixed up but coloured output

loicgillioz commented 1 year ago

Regarding fcntl(): Bad file descriptor issue : https://savannah.gnu.org/bugs/?59585 https://savannah.gnu.org/bugs/?52922 image

jortbmd commented 1 year ago

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.

jortbmd commented 1 year ago

I have created a quick version for this which will probably pushed to production later this week. If you want to test and resolve it now it can be found here: https://github.com/bmd-studio/stm32-for-vscode/releases/tag/v3.2.2-%23101-%23116-%23119 and you can use the attached .vsix file to install it by pressing CMD/CTRL+shift+P and by typing and selecting Extensions: Install from VSIX.

Then add: 

makeFlags:
 - -O

to your STM32-for-VSCode.config.yaml

jortbmd commented 1 year ago

The new version has been released so this fix should work. If you have any further issues feel free to re-open this issue or create a new one.