I tried running the diagnostic on the nucleo board but got the following error saying mpremote not found, even though the python installation seems to work correctly. @mehdi

You probably installed

mpremote

to

~/.local/bin

. Is that directory on your

$PATH

?

Yes, it seems so. This is what I got by typing command env in terminal

What are the outputs of 1.

python3 -c 'import site; print(site.getuserbase())'

2.

python3 -c 'import mpremote'

3.

find ~ -name mpremote -type f -executable

?

image.png

Ok, tracked it down, apparently it's a typo in line 2 of the Makefile, $PATH is expanded as ${P}ATH and not as ${PATH} like in bash. Does this patch work for you?

--- a/firmware_vex/nucleo/Makefile
+++ b/firmware_vex/nucleo/Makefile
@@ -1,5 +1,5 @@
 
-export PATH=$PATH:/bin:/usr/local/bin/:../../venv/bin:/usr/bin/:.
+export PATH:=${PATH}:/bin:/usr/local/bin/:../../venv/bin:/usr/bin/:.
 
 #DEV=/dev/cu.usbmodem3103
 DEV=/dev/cu.usbmodem34203

Thanks for your reply. The mpremote error is no longer there. But I faced another error shown below. Also attaching a screenshot of my makefile initial lines.

Ok, so one problem is fixed now. The new one is because your $DEV is empty. At the beginning of the Makefile, you have commented out all the DEV= lines, so it is now trying to execute

mpremote connect  exec ...

instead of

mpremote connect /dev/whatever exec ...

. You can list your devices with

mpremote devs

, try to find the correct one and then edit the Makefile to add a line

DEV=/dev/whatever

near the beginning.

Hi. Thanks for your reply. It makes sense. However, mpremote devs does not list any devices connected after I have connected the CN1 connector on Nucleo to my laptop. Do I need to make any other connections. If not what maybe a possible cause ?

Do you see any changes in

lsusb

output when you unplug or replug the device? Do you see anything relevant in the kernel log (e.g. using

dmesg

)? Depending on your user & device permissions, you might need to check these as root.

Hi. Thanks for your reply. There doesn't seem to be any difference in the lsusb output and the kernel log with and without the board connected. Am attaching the screenshot of the 2 cases for reference.

It means that your machine doesn't see the device attached. Your output also indicates that you are doing this inside a virtual machine, which makes hardware access a bit more complicated. First you need to make sure that your host machine sees the device (on a linux host check

lsusb

&

dmesg

as above; on a windows host run `devmgmt.msc`; on a mac os host use Apple menu > About this Mac > System Report...; etc.) Once the device is visible on the host you'll need to set up a filter in VirtualBox to pass it to the guest. You'll need to find out the details yourself, but it works the same way for any usb device so there should be plenty of tutorials on the internet.

Thanks a lot @htamas. The issue with the detection of the usb device on the virtual machine is now resolved by setting up the filter in the Virtual Box. After my virtual machine began recognizing the nucleo board, I also typed the command "_sudo chmod a+rw /dev/ttyACM0"_ to get rid of the error "failed to access /dev/ttyACM0 (it may be in use by another program)"

That's great. If you don't want to run

chmod

every time you plug in the device, you can create an

udev

rule that automates it for you. The way I usually do it is I create a rule file in the udev rules directory, let's say

/etc/udev/rules.d/51-usb-permissions.rules

(the number just gives the ordering if there are several rule files and can be mostly ignored). For every one of my usb devices I put a line in this file that says

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", ATTR{idProduct}=="YYYY", MODE="0660", GROUP="plugdev"

where

XXXX:YYYY

is your device vendor & product ID as it appears in the

lsusb

output. Once you modify the rules file, you'll need to run

sudo udevadm control --reload

for the changes to take effect (or just reboot the vm). This sets up a rule that every time you plug in a usb device with the particular ID, users in the

plugdev

group get read-write access to it. I think your user should be in the plugdev group by default, but if you type

groups

in the terminal and the result doesn't include

plugdev

, you'll also need to add your user to this group and then reboot (you don't actually need a reboot, but this way it's easier to explain).

added some context into which I was getting the same error in https://github.com/efabless/caravel_board/issues/17