For the last few decades when things don't work well on Windows I load up my Ubuntu machines, however at the moment things seems to be working fine on Windows but my Ubuntu machine is so flaky with the Regular Arduino IDE, The Pro IDE and the online cloud. The problem for me seems to revolve around the auto identification of the USB port. in my case /dev/ttyACM0.
I am not really a beginner and have tried lots of times setting groups and permissions and killing old processes. Hopefully a Ubuntu expert can help out here.
The two threads already have been kind of solved for me by simply loading the program with "sudo" in front.
I have tested this with ubuntu 18.04 and then I upgraded to 20.04 but as anyone used to Linux knows, you really don't want to be running programs using "sudo".
While trying to get my machine to work properly with the IDE's I have completely broken everything. Next step is to fully install 20.04 from scratch and try again. At the moment I am just borrowing my wife's windows laptop and exploring the Portenta H7 from that.
I feel that there is a simple solution but I am not sure what it is. Any ideas would be appreciated, but I think I will use windows for a few weeks.
I had an older Ubuntu 16.x LTS install and I just upgraded it to 20.04 LTS - I installed the Pro-IDE and 1.8.13 and had no issue in getting a MKR WiFi 1010 and Nano 33 IoT to be recognized.
I currently have my Portenta M7 in a test fixture so I have to bring the laptop to it vs. the other way around.
But, in the meantime - I noticed yet something else on another machine - are you able to assign the Portenta in your system to a different USB port?
Maybe try an external USB powered Hub - yes, I've seen issues with non-powered USB hubs, and see if that works.
In the meantime as well I will see if the Portenta M7 shows up ok and programs on my 20.04 LTS laptop install.
I have yet to get the Portenta M7 to program under Ubuntu 20.04 LTS.
It will show up under 1.8.13 - but gets the DFU error when programming.
Under the new IDE - I can't even get it to show up. (Or any other board right now.)
I noticed that in bootloader mode ('breathing' Green LED) - the /ttyACM0 or maybe /ttyACM1 (I plugged in a Nano 33 IoT and they 'swapped' last boot) - won't change when it's in bootloader mode or 'running' mode - I'll see if I can program the Nano OK or not and verify that behavior.
I also did what's in your other thread regarding the sudo ... dialout.. and all of that - and have basically confirmed I'm seeing what you're seeing - not what you want to hear right now but 50% of the solution is correct identification of the problem.
My user has admin rights but I've also gone through the sudo stuff and see basically the same thing.
Thanks John. I always assume I have done something really stupid, so nice for you to confirm some of the Ubuntu issues. Great idea about the external hub.
P.S. Example of really stupid; I just uploaded a webserver to the M4 core several times wondering why the M7 core serial printout wasn't showing the new upload. LOL.
I ran the sudo arduino to make sure the board packages were installed - and I was able to build the MKR WiFi 1010 'blinky' app OK using 1.8.13 under Ubuntu 20.04 LTS.
I then started the new Pro IDE - but I had to do that as 'sudo' as well.
Please see the attached - did you modify your CLI settings? When you 'sudo' - it may have changed to /root/ - and that could explain why it's failing.
I was able to load the 'blinky' build for the Portenta M7 - please refer to the attached.
Like you mentioned before - it's probably a good idea to run the beta Pro-IDE as Admin. (on win10)
I hadn't been doing that all the time - and I changed that on one of the PC's I'd been seeing the DFU error
when in bootloader mode - now the Portenta programs.
If things are working and all of a sudden they aren't - we need to remember all of this is still in 'BETA' -
check for Zombie Processes - I just found an instance of the debugger that is still running - see attached (on Win10).
On Ubuntu - you can run something like ps -aux | grep -i "arm" or ps -aux | grep -i "ide" or something similar to check for processes that may have not terminated properly.
