CW5.64 with CWNANO on windows

Hi, I have just got my CW setup… but unfortunately fallen at the first hurdle :frowning: Step 0 - upgrading the firmware on the CW Nano was a success.

But when trying to compile code in the “1 - Connecting to Hardware” tutorial, the compiler cannot be found:

cd ../hardware/victims/firmware/simpleserial-base/
make PLATFORM=CWNANO CRYPTO_TARGET=NONE

SS_VER set to SS_VER_1_1
Welcome to another exciting ChipWhisperer target build!! .././Makefile.inc:380: recipe for target 'gccversion' failed sh: 1: arm-none-eabi-gcc: not found make: *** [gccversion] Error 127

I have installed from ChipWhisperer5.5.2.Setup.64-bit.exe, and ticked the box for the compilers to be installed.

Investigating a bit more I find that the compiler is required to have the .exe extension applied to it.

If I run with the .exe extension:
arm-none-eabi-gcc.exe: fatal error: no input files
compilation terminated.
Without:
/bin/bash: line 1: arm-none-eabi-gcc: command not found

Is this a known problem with a workaround that I have been unable to find?

Thanks,
Martin

Hi Martin,

That’s really strange! At least on my system, there’s no difference. I’ll look more into this and see
if I can figure out if there’s some situation that can require git bash to require the .exe extension.

Alex

1 Like

New info - it works on another PC I have.

This is (in theory) the same config of bash/mingw/etc… If you have any suggestions of information I can attempt to extract, let me know :slight_smile:

OK, I have an older bash coming from somwhere (perhaps Windows Subsystem for Linux?):
Works:

GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)

Fails:

GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)

I will have to figure out where that is coming from, it appears to be on the path before the one from the CW install …

I am having the same issue.
Jupyter seems to be using the WSL Bash.
After installing the ARM compilier in WSL by running “sudo apt install gcc-arm-none-eabi”, the compilation works, but i would rather have it use the intended bash and compiler.

Can you check your Windows path and see if there’s anything about the WSL being on the path? Otherwise, you might just have to disable WSL entirely.

I doubt you’ll run into any issues compiling through WSL, though.

Alex

The WSL bash.exe is located in “C:\Windows\system32”, so it obviously is on the path.
I tried moving C:\Users<username>\ChipWhisperer5_64\cw\bin to the front of the path, but this doesn’t solve the issue.

When I start a shell with mintty and run bash --version, i get the correct bash:
GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)

Running python -c "import os; os.system('bash --version')" also uses the correct bash:
GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)

But running python -m jupyter notebook and then running the block
%%bash
bash --version
outputs
GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)

Seems like Jupyter is doing something strange?

I might just compile through WSL.

Thanks,
Thomas

I made a quick hack and just uninstalled WSL. This has fixed the problem for me, as I do not currently need WSL. I’m not sure what the solution would be for those who do still need to run WSL…

Yeah, Jupyter does some weird things with the environment. Out of curiosity, does

!bash --version

give the correct bash installation?

Alex

!bash --version outputs the correct version:
GNU bash, version 4.4.23(1)-release (x86_64-pc-msys)

Thomas