Is that on a Pi?
If by everyone you mean me, I believe so, I’ve only had 1 successful install but I’m quietly confident that went as planned and have no reason to doubt it would work again.
I think @Ian gave up and used Windows, @TrystanLea and you are using amd64 as is @Paul via a VM, I don’t know of anyone other than myself that is testing on a Pi so it would be useful if you could confirm it’s ok on a Pi.
No Ubuntu desktop
Great
If it works for you on a Pi it should work fine on all Pi’s since Pi’s are should be identical
Yes, -D is the equivalent of #define. Therefore using -D was incorrect in this instance since we wanted to pass the value direct to the compiler as a flag.
Just to test this I started on a new out of the box pi with 2018-03-13-raspbian-stretch.image.
I followed your platform instructions exactly using the links provided.
First issue was platform:
pi@STM_Test:~ $ pio
-bash: pio: command not found
I reinstalled with sudo
pi@STM_Test:~ $ sudo python -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/develop/scripts/get-platformio.py)"
and then pio was recognised as a command.
Next
pi@STM_Test:~/stm32tests/emonTxshield $ pio run -t upload
This worked fine until the upload when I got this error:-
Looking for upload disk...
Error: Please specify `upload_port` for environment or use global `--upload-port` option.
For some development platforms it can be a USB flash drive (i.e. /media/<user>/<device name>)
*** [upload] Explicit exit, status 1
========================= [ERROR] Took 397.06 seconds =========================
================================== [SUMMARY] ==================================
Environment stm32f303-dev [ERROR]
Environment stm32f303 [SKIP]
========================= [ERROR] Took 397.06 seconds =========================
I know the nucleo is on /dev/ttyACM0 because I can see it in miniterm still running the firmware I uploaded a day or so ago.
Ian
Ian, /dev/ttyACM0 is the devices serial port, but when uploading to a STLink you are copying to a mass storage device usually at “/media/<user>/<device name>” as stated in the pio output. Mine is usually at /media/pi/NODE_F303RE.
What does this return for pi’s media folder?
ls -la /media/pi
Hi Paul
pi@STM_Test:~/stm32tests/emonTxshield $ ls -la /media/pi
total 12
drwxr-x---+ 3 root root 4096 Apr 3 14:46 .
drwxr-xr-x 3 root root 4096 Apr 3 14:46 ..
drwx------ 2 root root 4096 Apr 3 14:46 NODE_F303RE
pi@STM_Test:~/stm32tests/emonTxshield $
That looks like an empty folder
What do you find in that folder (if anything)?
ls -la /media/pi/NODE_F303RE
also what does this return?
mountpoint /media/pi/NODE_F303RE
here’s my results
pi@raspberrypi:~ $ ls -la /media/pi
total 16
drwxr-x---+ 4 root root 4096 Apr 3 17:15 .
drwxr-xr-x 3 root root 4096 Mar 13 23:17 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
pi@raspberrypi:~ $ ls -la /media/pi/NODE_F303RE
total 16
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 .
drwxr-x---+ 3 root root 4096 Apr 3 17:05 ..
-r--r--r-- 1 pi pi 46 May 27 2004 DETAILS.TXT
-r--r--r-- 1 pi pi 512 May 27 2006 MBED.HTM
pi@raspberrypi:~ $ mountpoint /media/pi/NODE_F303RE
/media/pi/NODE_F303RE is a mountpoint
Are you doing this via startx? Or have you had startx running at any point when you’ve had the stm device hooked up? This looks very much the same as your original attempt.
Also what does
ls -la /dev/sd*
and
mount | grep "NODE_F303RE"
return? Here’s mine again.
pi@raspberrypi:~ $ ls -la /dev/sd*
brw-rw---- 1 root disk 8, 0 Apr 3 17:05 /dev/sda
pi@raspberrypi:~ $ mount | grep "NODE_F303RE"
/dev/sda on /media/pi/NODE_F303RE type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
[edit - I have just dragged out a hdmi cable and fired up startx and it doesn’t appear to have changed anything for me.]
I think you will need to setup the port permissions. Try once with
$ sudo pio run -t upload
If this works, we will just need to fix the group permissions or just continue to use sudo before every pio command. Not best practice but ‘works’ on a Pi.
My NODE_F303RE folder details are
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
Ian’s NODE_F303RE folder details are
drwx------ 2 root root 4096 Apr 3 14:46 NODE_F303RE
“4096” is the initial size for an actual folder in Linux and “Apr 3 14:46” is when that folder was created. There is something very odd about the way the device is (or isn’t?) mounted.
This was further proved when Ian was able to copy the .bin file to the NODE_F303RE “folder” and view it there just like any other file copying process, the .bin file should have been consumed by the device if it was mounted there.
Besides why would a storage device be mounted under /media/pi if the user pi has no access to it? It’s as if the device has been mounted with
sudo mkdir -p /media/pi/NODE_F303RE
sudo mount /dev/sda /media/pi/NODE_F303RE
that would give you a root owned folder BUT that method arrives at slightly different “group” and “all users” permissions, so I guess the folder is being created another way.
pi@raspberrypi:~ $ sudo mkdir -p /media/pi/NODE_TEST
pi@raspberrypi:~ $ ls -la /media/pi
total 16
drwxr-x---+ 4 root root 4096 Apr 4 12:19 .
drwxr-xr-x 3 root root 4096 Mar 13 23:17 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
drwxr-xr-x 2 root root 4096 Apr 4 12:19 NODE_TEST
I’m using a totally stock Pi with totally stock OS, So the question is why am I getting different results, I have not had to use sudo at any point since installation. it has to be the order of events or the way something is being done differently.
@Ian did you run update and dist-upgrade on the new image? I have to admit I have done that immediately on each image I’ve created so I can’t say if this works on an un-updated latest image. Are you still using the “full” image not a “lite” image? {must be if you are using startx I guess]
sudo pio run -t upload made no difference. Same error. It would seem the problem is that the nucleo is not being mounted when plugged in. See reply to @pb66 below
Result of commands suggested:-
pi@STM_Test:~/stm32tests/emonTxshield $ ls -la /media/pi/NODE_F303RE
ls: cannot open directory '/media/pi/NODE_F303RE': Permission denied
pi@STM_Test:~/stm32tests/emonTxshield $ sudo ls -la /media/pi/NODE_F303RE
total 44
drwx------ 2 root root 4096 Apr 3 18:16 .
drwxr-x---+ 3 root root 4096 Apr 3 14:46 ..
-rwxr-xr-x 1 root root 33416 Apr 3 18:18 emonTxshield.bin
pi@STM_Test:~/stm32tests/emonTxshield $ mountpoint /media/pi/NODE_F303RE
/media/pi/NODE_F303RE is not a mountpoint
pi@STM_Test:~/stm32tests/emonTxshield $ ls -la /dev/sd*
brw-rw---- 1 root disk 8, 0 Apr 4 14:48 /dev/sda
pi@STM_Test:~/stm32tests/emonTxshield $ mount | grep "NODE_F303RE"
pi@STM_Test:~/stm32tests/emonTxshield $
I did update and upgrade on the new image but not dist-upgrade, which I just did but that resulted in no changes.
I used startx tp set Pi configuration and connect to WiFi. I first did it without the nucleo plugged in but whether I have ever done it with the nucleo plugged in I cannot be absolutely sure.
I have had the same issue with 2 different Pi. The first one I retrieved from from my junk box and has seen better days. The second one is brand new straight out of the packaging. I have used a different power supply just in case there was a power issue.
The only common feature hardware wise is the nucleo board and the USB cable its connected by.
It mounts on my windows PC but it would seem for some reason it does not mount correctly on the Pi.
So I cannot us PIO or cp build/emonTxshield.bin /media/pi/NODE_F303RE using a Pi. I can use PIO on windows and I can copy the result of make from the Pi to the windows machine and then copy onto the mounted nucleo using either Pi.
Was the Nucleo attached when you did that last batch of tests?
Everything is as I expected except the “grep”, Can you run a couple more commands/
sudo blkid | grep "/dev/sd"
should show the device whether it’s mounted or not
sudo mount | grep "/dev/sd"
should show any mounted devices that use /dev/sd? regardless of what name it’s been assigned, I’ve included sudo this time just in case previously mount didn’t include the “NODE_F303RE” for grep to find because of the root ownership.
my results
pi@raspberrypi:~ $ sudo blkid | grep "/dev/sd"
/dev/sdb: SEC_TYPE="msdos" LABEL="NODE_F303RE" UUID="2702-1974" TYPE="vfat"
pi@raspberrypi:~ $ sudo mount | grep "/dev/sd"
/dev/sdb on /media/pi/NODE_F303RE type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Using sudo pio run can result in a duplication of libs and a change of ownership of the compiled results that could block future use of pio without sudo, so can you also post the results of these 2 commands
ls -la ~/stm32tests/emonTxshield/.pioenvs
sudo ls -la /root/.platformio
hopefully as the sudo pio run -t upload command was not a full recompile you should be ok
Yes the Nucleo was attached.
Results of commands:-
pi@STM_Test:~ $ sudo blkid | grep "/dev/sd"
/dev/sda: SEC_TYPE="msdos" LABEL="NODE_F303RE" UUID="2702-1974" TYPE="vfat"
pi@STM_Test:~ $ sudo mount | grep "/dev/sd"
pi@STM_Test:~ $ ls -la ~/stm32tests/emonTxshield/.pioenvs
ls: cannot access '/home/pi/stm32tests/emonTxshield/.pioenvs': No such file or directory
pi@STM_Test:~ $ sudo ls -la /root/.platformio
total 20
drwxr-xr-x 4 root root 4096 Apr 4 14:50 .
drwx------ 5 root root 4096 Apr 4 14:50 ..
-rw-r--r-- 1 root root 25 Apr 4 14:50 appstate.json
drwxr-xr-x 8 root root 4096 Apr 4 14:56 packages
drwxr-xr-x 3 root root 4096 Apr 4 14:50 platforms
pi@STM_Test:~ $
The 1st result is good, it shows the Nucleo is connected.
The second result confirms the device is not mounted,
The third is odd as there should be a folder .pioenvs like this
pi@raspberrypi:~ $ ls -la ~/stm32tests/emonTxshield/.pioenvs
total 196
drwxr-xr-x 3 pi pi 4096 Apr 4 17:37 .
drwxr-xr-x 8 pi pi 4096 Mar 30 16:20 ..
-rw-r--r-- 1 pi pi 102 Mar 30 16:17 do-not-modify-files-here.url
-rw-r--r-- 1 pi pi 176954 Apr 4 17:37 .sconsign.dblite
drwxr-xr-x 5 pi pi 4096 Apr 4 17:37 stm32f303-dev
-rw-r--r-- 1 pi pi 40 Mar 30 16:17 structure.hash
perhaps the message is misleading and it is just a casualty of using sudo with pio, you could try the command again with sudo and/or try ls -la ~/stm32tests/emonTxshield too. eg
pi@raspberrypi:~ $ ls -la ~/stm32tests/emonTxshield
total 100
drwxr-xr-x 8 pi pi 4096 Mar 30 16:20 .
drwxr-xr-x 5 pi pi 4096 Mar 30 15:08 ..
drwxr-xr-x 2 pi pi 4096 Mar 30 16:20 build
drwxr-xr-x 2 pi pi 4096 Mar 30 16:20 .dep
drwxr-xr-x 4 pi pi 4096 Mar 30 15:08 Drivers
-rw-r--r-- 1 pi pi 18140 Mar 30 15:08 emonTxshield.ioc
-rw-r--r-- 1 pi pi 102 Mar 30 15:08 emonTxshield.mak
drwxr-xr-x 2 pi pi 4096 Mar 30 15:08 Inc
-rw-r--r-- 1 pi pi 5730 Mar 30 15:08 Makefile
-rw-r--r-- 1 pi pi 4797 Mar 30 15:08 .mxproject
drwxr-xr-x 3 pi pi 4096 Apr 4 17:37 .pioenvs
-rw-r--r-- 1 pi pi 931 Mar 30 15:08 platformio.ini
drwxr-xr-x 2 pi pi 4096 Mar 30 15:08 Src
-rw-r--r-- 1 pi pi 14111 Mar 30 15:08 startup_stm32f303xe.s
-rw-r--r-- 1 pi pi 4937 Mar 30 15:08 STM32F303RETx_FLASH.ld
The last test tells us you most likely have duplicate libs (0.6GB) from using sudo with pio.
I think we should try and quickly cleanse your setup and if that doesn’t work we should probably start from scratch and add your wifi details and enable ssh via the /boot partition files so you can ssh in at first boot without ever going into startx, if that works then we can then work on from there.
To cleanse the current setup try unplugging the Nucleo and run these commands
sudo rm -r /root/.platformio
sudo rm -r /home/pi/.platformio
sudo rm -r /home/pi/stm32tests/emonTxshield/.pioenvs
sudo rm -r /media/pi/NODE_F303RE
sudo reboot
when it has rebooted, ssh in and check there is no folder at /media/pi/NODE_F303RE using
sudo ls -la /media/pi
Then plug in the Nucleo and check again. If there is still nothing there after a few seconds, run these and report the results along with the result of the above.
sudo blkid | grep "/dev/sd"
sudo mount | grep "/dev/sd"
IF the “NODE_F303RE” is there after plugging in, then try
pio run -t upload
it will take several minuets because we previously deleted the compiled code and libs, if that still fails, please post the full output so we can we see the paths etc.
Do not use sudo with pio at anypoint
OK some progress.
I ran all the commands suggested exactly as indicated and I have the results saved if you would really like to see them.
However the result was that clearly the Nucleo was not being mounted.
In the meantime I reformatted the SD card on the older pi and burnt a new image. This time I set up ssh on the PC before I used the SD card and I also used a spare Ethernet to connect to the Pi.
On first boot I ran upgrade and dist-update. and rebooted. I setup wifi from the command line, shut down, dropped the Ethernet connection. and rebooted. I then plugged in the Nucleo.
Result:-
pi@raspberrypi:~ $ sudo ls -la /media/pi
total 12
drwxr-x---+ 3 root root 4096 Apr 5 16:23 .
drwxr-xr-x 3 root root 4096 Apr 5 16:11 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
Unplugged Nucleo
pi@raspberrypi:~ $ sudo ls -la /media/pi
total 8
drwxr-x---+ 2 root root 4096 Apr 5 16:35 .
drwxr-xr-x 3 root root 4096 Apr 5 16:11 ..
Plugged in again
pi@raspberrypi:~ $ sudo ls -la /media/pi
total 12
drwxr-x---+ 3 root root 4096 Apr 5 16:35 .
drwxr-xr-x 3 root root 4096 Apr 5 16:11 ..
drwxr-xr-x 2 pi pi 1024 Jan 1 1970 NODE_F303RE
pi@raspberrypi:~ $
So it appears using startx somehow stops the Nucleo mounting properly.
My next move was to install Platformio.
I used:-
pi@raspberrypi:~ $ pip install -U platformio
Every thing seemed to go ok, a lot of file unpacking and no errors reported.
When it finished before I did anything else I tried this to make sure platformio was working.
pi@raspberrypi:~ $ pio
-bash: pio: command not found
I have been here before. Previously I have installed platformio with sudo and the pio then command worked.
This time I have called a halt pending advice!
The good thing is platform has not affected the mounting of the Nucleo which I have plugged and unplugged about 6 times and it always remounts.
If I can get platform to work I am sure everything will be the same as your setup. I have not tried the make procedure yet as I thought it better to sort out PlatformIO first but I have no doubt it would now work as NODE_F303RE contains MBED.HTM and DETAILS.TXT just as it shows when mounted on the Windows PC.
Fantastic news!
Good move!
Although using pip to install platformio has added another unknown element though. I have not tried using pip myself. However, we need to try and establish if the “-bash: pio: command not found” error is because it isn’t there or whether it’s the wrong user level. I suspect it’s an incomplete installation because maybe it needed to be
sudo pip install -U platformio
so that pip was run with a high enough permission level to make changes to the root file system, eg adding the pio executable to the “PATH”. I’m guessing a bit here and carrying over my experience of using the platformio “easy install” command line, it seems to install ok without sudo, but then it won’t work, re-running it with sudo seemed to fix the issue.
Since pip is a package installer, you might need to remove the current installation before you can reinstall with “sudo”.
First try
pio --version
should fail as above
sudo pio --version
not sure, but I suspect this might fail too
just check to see if either of the executables are present, here’s mine
pi@raspberrypi:~ $ ls -la /usr/local/bin/pio
-rwxr-xr-x 1 root staff 221 Mar 30 15:06 /usr/local/bin/pio
pi@raspberrypi:~ $ ls -la /usr/local/bin/platformio
-rwxr-xr-x 1 root staff 221 Mar 30 15:06 /usr/local/bin/platformio
I’m guessing the’re not there, if you want to double check there not somewhere else you can use the whereis command eg
pi@raspberrypi:~ $ whereis platformio
platformio: /usr/local/bin/platformio
pi@raspberrypi:~ $ whereis pio
platformio: /usr/local/bin/pio
but, it might be time to try and reinstall using sudo
sudo pip install -U platformio
if it complains that it’s already installed or that it’s already the latest version, we need to remove it first.
pip uninstall platformio
then try installing with again with sudo.
to test use pio --version, if that doesn’t work try checking for the executables as we did above.
That’s cool! I also suspect make will work no problems, it is much simpler than pio. for the record it’s also much faster than pio on a RPi, so although you might eventually prefer to use make over pio, I appreciate you helping resolve this as I’m sure there will be many others that hit a similar snag.
I’m still unclear about how and when startx interferes with the mounting as I tried every which way last night to get the mounting to fail and couldn’t, I used startx from boot, I rebooted with the Nucleo attached and unattached, I could not replicate what you have seen (yet).
The question over using sudo or not when installing is less of an option than platformio make out. Thier documentation is peppered with lines like
“To install or upgrade PlatformIO paste that at a Terminal prompt (MAY require administrator access sudo):”
and
“To install or upgrade PlatformIO, download (save as…) get-platformio.py script. Then run the following (MAY require administrator access sudo):”
All of the places the pio or pip installer could install the executables are owned by root, so if you are not the “root” user (or belong to the “staff” group) you must use sudo, if you are the root user, sudo has no effect, so why they do not just include sudo with these commands as standard I have no idea. Nor do I understand why the installer does not alert the user that it has failed to create/copy certain crucial files.
My fingers are crossed for you.
OK success at last.
pi@raspberrypi:~ $ pio --version
-bash: pio: command not found
pi@raspberrypi:~ $ sudo pio --version
sudo: pio: command not found
pi@raspberrypi:~ $ ls -la /usr/local/bin/pio
ls: cannot access '/usr/local/bin/pio': No such file or directory
pi@raspberrypi:~ $ ls -la /usr/local/bin/platformio
ls: cannot access '/usr/local/bin/platformio': No such file or directory
pi@raspberrypi:~ $ sudo pip install -U platformio
This ran without error.
pi@raspberrypi:~ $ pio --version
PlatformIO, version 3.5.2
Cloned stm32tests from github following instructions and all went well.
Auto-detected: /media/pi/NODE_F303RE
Uploading .pioenvs/stm32f303-dev/firmware.bin
Firmware has been successfully uploaded.
(Some boards may require manual hard reset)
======================== [SUCCESS] Took 467.77 seconds ========================
================================== [SUMMARY] ==================================
Environment stm32f303-dev [SUCCESS]
Environment stm32f303 [SKIP]
======================== [SUCCESS] Took 467.77 seconds ========================
For the sake of completeness perhaps perhaps a note could be added in the various stm repositories that if using a Pi the first thing to check is to see if the Nucleo mounts and dismounts when plugged in and out.
Secondly a note also on a Pi you need to use sudo pip install -U platformio to install platformio.
That’s good news, that means that (Pi) users installing by either method (Python+curl or pip) can just reissue the installation command with sudo if they omit it the first time.
Are you now able to use startx without any problems returning?
At this point I’ve still got no idea what has caused the issue and to my knowledge you are the only one to have experienced it (thus far), so I’m not really able to give a concise check, cure or even guidance on how to avoid it happening yet, The guide will get real messy if we include all the checks and explanations etc, it might not be clear to a user that it isn’t mounted, or it might actually be mounted to the root owned folder created by startx.
Here, however, I think we have established enough of a clear pattern for a warning, something like
Raspberry Pi (Raspbian) users should always use sudo to install platformio and generally never use sudo when using any platformio or pio commands, ever!
Just a note to add that support for the STM32F303CBT6 MCU as used in the latest prototype has now beed added to platformIO
I’ve added a platformio.ini file to the repo:
All that’s needed to compile and upload and view serial is
$ git clone https://github.com/openenergymonitor/STM32
$ cd Emon3CT_CB
$ pio run -t upload
$ pio device monitor