[Kenzi]

That was it.  I had to restart Visual Studio.  Then regenerating worked.

Thanks.

[Kenzi]

As a workaround, please try moving the BSP into a directory with a shorter path (e.g. c:\NordicBSP) and then create a .bsplink file instead of the original directory (e.g. %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x.bsplink) that will contain the full path to the new short directory.

I did this, and it cleared up the issue mostly.  Under VisualGDB Project Properties -> Embedded Project, the Shared files location now shows C:\NordicBSP.  However, the files generated under my project’s Device-specific files still all point to C:\Users\kenzi\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\.  It builds fine (somehow?), but CLang is totally broken now.

I have tried a few things, but I just can’t convince VisualGDB to generate solution files that point to the proper location.  Any ideas?

 

[Kenzi]

Never paid much attention.  It’s what was installed with VisualGDB.. but now “ARM” isn’t even in the VisualGDB package list… does this mean I should install it as an extern toolchain?

(edit: oops I didn’t see who made that last reply)

• This reply was modified 6 years ago by Kenzi.

[Kenzi]

VisualGDB is acting strange as far as the ARM toolchain install/uninstall.

No ARM toolchains appear in the “Manage VisualGDB Packages” list unless I check “Show old packages.”  Still, the current toolchain I’m using (GCC 2.7.0 GDB 8.0.1) isn’t in the package list.  This toolchain does show up in the MSBuild settings -> Toolchain dropdown.  I’ve uninstalled and reinstalled using that dropdown.  The reinstall seemed to mostly work, but it still only builds only if I have a <32KB command line.

 

• This reply was modified 6 years ago by Kenzi.

[Kenzi]

Okay, I hope I did this right – it was installed with VisualGDB, so I unstalled it and VisualGDB prompted me to reinstall it.

Executing this command:

S:\Git\odysseus_firmware\Nordic\tdoa_anchor>c:arm-eabi-gcc.exe -v @VisualGDB\Debug\scheduler.gcc.rsp

Yielded basically the same result.  I’m not sure how to capture it all, but it started with this:

S:\Git\odysseus_firmware\Nordic\tdoa_anchor>c:arm-eabi-gcc.exe -v @VisualGDB\Debug\scheduler.gcc.rsp > s:\output.log
Using built-in specs.
COLLECT_GCC=c:arm-eabi-gcc.exe
Target: arm-eabi
Configured with: ../gcc-7.2.0/configure --target arm-eabi --enable-win32-registry=SysGCC-arm-eabi-7.2.0 --enable-languages=c,c++ --disable-nls --without-libiconv-prefix --prefix /f/gnu/auto/bu-2.29+gcc-7.2.0+gmp-4.3.2+mpfr-3.1.6+mpc-1.0.3+newlib-2.5.0-arm-eabi/ --host i686-w64-mingw32 --disable-shared --with-newlib --with-headers=../newlib-2.5.0/newlib/libc/include --enable-interwork --enable-multilib --with-float=soft
Thread model: single
gcc version 7.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mthumb' '-mfloat-abi=hard' '-mfpu=fpv4-sp-d16' '-mcpu=cortex-m4' '-I' 'src' '-I' 'S:/Git/odysseus_firmware/Nordic/tdoa_anchor/' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/components/softdevice/S132/headers' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/components/softdevice/S132/headers/nrf52' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/modules/nrfx' '-I' 'C:/Users/kenzi/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.nordic.nrf5x/nRF5x/modules/nrfx/hal' '-I' 'C:/Users/kenzi/AppData/Local

That last line was probably about 32KB long.

And it ended like this:

c:arm-eabi-gcc.exe: error: CreateProcess: No such file or directory

So it looks like gcc itself is struggling with the long line?

[Kenzi]

The command line is being shown because I set msbuild output to Detailed.  I will upload to the support form.

 

[Kenzi]

I thought I was using MSBuild, unless I’m misunderstanding these settings.

Attachments:

You must be logged in to view attached files.

[Author]

Posts