https://nordicsemiconductor.github.io/asset-tracker-cloud-docs/v1.5.x/docs/aws/GettingStarted/Flashing.html

[Burt]

Hello, the directions indicate that it is possible to use Windows Subsystem for Linux, and you instruct us to use version 2 of WSL, but I have no access to the COM ports so I cannot flash from WSL -- a severe inconvenience. I read somewhere that only WSL 1 allows access to COM ports. What gives here?

[Markus Tacker (he/him)]

The System requirements are for getting the cloud components up and running.

Since you are on Windows, you can follow the instructions for flashing using nRF Connect for Desktop linked in section 3 here.

[Burt]

Thanks, Markus, but I am talking about section 2, just prior to the section 3 you refer to: naturally after having done all the work for getting the cloud components up and running (having used WSL per the instructions and those instructions link to Microsoft's recommendations to use WSL2), I want to provision the certificates using the CLI, like referenced on the page you pointed me to. Now, most of my previous work with the Nordic SDK I have done using a bash shell invoked from the nRF Connect Toolchain Manager. It seems to me, though I have not tested it, the best approach for getting the cloud components up and running would have been to do that in a bash shell, with the proviso that the direnv program will not work. That is a small negative compared to the positive of having access to the USB serial ports from the bash shell.

Can you verify my findings and if successful have the documentation for getting the cloud components up and running changed so that future users will have an easier time. In my case, I ended up provisioning the certs. the old fashioned way with LTE Link Monitor but that is more of a nuisance than a more automatic approach.

[Markus Tacker (he/him)]

I totally get that it would be nice to use one shell for everything.

Nevertheless, even for me (using Linux), I have to break out of this process for Upgrading the modem firmware.

The CLI flash command is really handy, but I have proposed to add a note there that specifically points out that this is not working on WSL 2: github.com/.../62

[Burt]

Thanks, Markus. One thing about the documentation -- the information about CLI flash not working in WSL 2 needs to be stated at the start when WSL is first mentioned -- by the time you get to flashing, a lot of time has been invested in WSL 2. I didn't read through your github change thoroughly to see whether you are making the statement early on.

Also, the truth is that I eventually went to my Linux desktop that I rarely use although it is much faster than my laptop. The CLI flash failed even though I had access to the serial port. But I figured that is a secondary issue -- primary is having access to USB serial. I figured maybe my DK board being older v0.9.0, maybe there is some software incompatibility. Maybe with the at_client. I may hack around with that later. I remember there was a python script I once used, similar idea to the CLI flash command, and it worked AOK but I always forget the name of it, etc, etc.

[Markus Tacker (he/him)]

Well, the good thing on the other hand is that WSL 2 worked for the whole other part: setting up the cloud components with Node.js etc. So I am reluctant right now to advice completely against WSL 2.