I am working with a RAK4631-based system using Platform IO on WIndows 11.
Until last Thursday everything was fine, then suddenly after one compile of the software the serial connection stopped working. I thought I had done something wrong in a recent change to the software, but couldn’t figure out what.
I had another device with an older version on it and it worked fine.
So, as a test, I recompiled that older version and the serial output stopped working for that as well - so it wasn’t my code change.
When the device is running it performs normally in terms of its output over LoRa etc, but there is no COM device visible on Windows. If I make a change and want to reload the device I have to double-press reset before I can load the new binary from PlatformIO - this was never the case before Thursday. The COM device being used for this gets dropped as soon as the load has finished.
Seems to be a problem with Windows.
I have two RAK4631 that, same as happened to you, suddenly are not detected as COM ports anymore after flashing a new firmware.
Weird thing, if I force bootloader mode, it is detected and I can upload code. Both RAK4631 are working just fine.
And even weirder, if I flash the RAK4631 with our RUI3 bootloader and flash a RUI3 code, they are working normal and are detected as COM ports and I get debug output.
I tried reflashing the Bootloader, but that didn’t help either.
I went Google search up and down, but so far I could not find a solution. If you find a way, please post it here.
Hi Bernd,
Thanks for the quick confirmation that there is a problem.
There was an automated Windows update middle of last week, which is very likely to have triggered the problem.
Presumably, then, there is some difference in the way that the RU13 code handles the serial interface from the standard 4631 code?
I hate working blind!
I may try reverting back to Linux from Windows if I can’t sort it out.
I still have no idea what triggered it. I am on Windows 10 and have updates disabled.
The weird thing is that most of my RAK4631 are still working, only 2 have stopped to be detected.
RUI3 and Arduino bootloader use different VID/PID, but all RAK4631 with Arduino use the same VID/PID’s so that cannot be the problem either. I am guessing there is some mess-up in the registry, because I can still see the originally assigned COM ports there. But I cannot delete them, there is an error message about “insufficient rights”
I don’t think it can be Windows itself if you’re using 10 and l’m using 11.
I believe something changed in the compiling environment middle of last week. Devices loaded with code compiled before then work fine. If I recompile the same code their serial connection stops working.
Alan
I am compiling on PlatformIO as well and I didn’t update the BSP’s or PIO itself. I can still flash other modules and they work normal over the USB and are detected.
I did a test.
I took a RAk4631 that was no longer detected as USB port and flashed it with Arduino IDE. And it was detected again.
Then I flashed it again, this time from PlatformIO and the device is still working and detected.
I used the same code for both Arduino IDE and PIO.
@beegee
How bizarre.
I had to install the IDE, which took me a while.
I uploaded the sample sketch and it worked.
I went back to PIO and uploaded my software and that now works.
There must be some persistent state within the 4631 that the Arduino IDI is setting correctly and PIO basically ignores (maybe)???
Thanks for finding this.
I wonder how long before I have to do it again?
Cheers
Alan
I’ve seen this as well with Ubuntu (Linux). My flash tool of choice has been Segger JFlashLite along with Ozone as a debugger, which generally works. But at times I have the seen same no serial indication. (and had seen it with just plain PlatformIO out of the blue as you indicated).
I’ve also been mucking with bootloaders trying to get another NRF52840 platform (Seeed Xiao) working with the Adafruit Arduino runtime. Flashing this one, that one, Nordic’s, the Wisblock file onto the Seeed, the Seeed version onto the Wisblock, generally making a mess of things.
It’s been tricky recovering the Wisblock (and I suspect the Seeed as well).
Seems the use “Arduino IDE to flash any app” seems to clear it up for me as well. At times I have had to use the combination of JFlashLite to flash the Wisblock bootloader, then use the Arduino IDE to flash an app before all gets restored. Much (but not all) of my occurrences is probably due to my mucking with bootloaders and debugging.
You might copy off the nrfjprog commands that Arduino uses, from the IDE output, and run those to see if it clears up without needing the Arduino IDE itself.
I “think” the following gives me better success at restoring the proper bootloader than using JFlashLite.
In my case mucking, with bootloaders, it looks like at least the interrupt table adresses at 0x20000000 and 0x20000004 are not always getting updated correctly. Either that or Ozone is not being truthful, which apparently has happended.
I’ll just add that I get the exact same port disappearing behavior when flashing via platformio in debian - so it is not Windows specific.
Very annoying, and I wasted a lot of time trying to figure it out, instead of actually working on my applications (still having an issue with Wisblock API devices locking up/stopping communicating after a few hours - but that has nothing to do with this port issue).
I haven’t tried just flashing from Arduino IDE, but I’ll do that next I guess.
Hi Jason,
I was thinking of switching to Linux - glad I didn’t expend the energy- based on your experience.
Flashing from Arduino IDE just once sorted it for me. @beegee Is this something your engineers might want to think about??
@Botched1 @Alangward
As this problem started when a new PIO version came out while we (RAK) didn’t change bootloader nor BSP, I don’t think we can do anything to stop it from happening.
It is caused by PIO and they have to figure it out.
Hi Bernd,
I wasn’t suggesting that there was any fault with the RAK hardware or software - sorry if I gave that impression.
I was just thinking that the engineers might be able to pinpoint what PIO is doing wrong - we can then (somehow) raise a bug with them. At the moment they may not be aware of our problem.
Thanks
Alan
Hi Alan,
no offense taken.
I will ask our R&D team, but they are very busy (as usual), so I am not sure when they can look into it. Specially because it is difficult to the problem.
Apologies for reviving an old thread. But I’m running into the exact same issue, and reflashing from Arduino fixes the issue when running that code, but as soon as I push from PIO, the com port is gone.
