STM32CubeProgrammer erase fails under Linux

[Duckpaddle]

I noticed that the V 2.20 STM32CubeProgrammer erase function doesn't work under Pop_OS!, a Linux distribution.  It does however work on Windows 10.  I don't think this is a logic failure within the STM32CubeProgrammer but some weird interaction with the USB Driver.  Just to be clear I am using STLink on a STM32N6 evaluation board.  Interesting that this function does work on a STM32h747i_disco board.  Another difference is I am using an USB A to USB C cable, but all the other functions work, after erase on the Windows machine.  

I have the erase under Windows workaround but it is a little inconvenient.

[Duckpaddle]

The exact error is: Error: Mass erase operation failed.Please verify flash protection

[Ozone]

Did you check your user is part of the required groups (usually dialout and plugdev) ?

Does the udev rules file cover both ST-Links, which might be different versions ?

[Duckpaddle]

Yes, my user is a member of both groups.  Yes, I am using the same executable V 2.20 for both the N6 and H7 processor.

[Ozone]

> Yes, I am using the same executable V 2.20 for both the N6 and H7 processor.

No, that's not what I meant.
The folder /etc/udev/rules.d/ contains text files describing the devices to which the "plugdev" rules apply.
At least on my (Debian-based) distros.
Here an excerpt from "99-jlink.rules" from one of my systems :
ATTR{idProduct}=="1010", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1011", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1012", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1013", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1014", ATTR{idVendor}=="1366", MODE="666"
...
As you see, it lists several product IDs, for different JLink adapter versions in this case.
I think it's at least worth to check both that your ST-Link IDs match.

I don't know Pop-OS, but what I read it is Debian/Ubuntu-based as well, so it should be similiar.

Alternatively, you can try OpenOCD to erase/flash the STM32N6 board, which supports ST-Link as well.

[Duckpaddle]

Thank you for the clarification: 

I will try the OpenOCD, good thought!

I used Gemini as an intelligent grep and it said that my 99-jlink.rules file has the rules you suggested:

Yes, your 99-jlink.rules file already contains the exact permissions suggested by the vendor.

Those lines are present in the section defining the permissions for the "[new format]" J-Link Product IDs.

Here is the matching section from the file you provided:

Code snippet

...
ATTR{idProduct}=="100f", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1010", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1011", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1012", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1013", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1014", ATTR{idVendor}=="1366", MODE="666"
ATTR{idProduct}=="1015", ATTR{idVendor}=="1366", MODE="666"
...

Your configuration file includes these rules and many others, so no changes are necessary based on that specific suggestion.

[Duckpaddle]

I did check to see if the USB id for the STM32N6 board appeared in my 49-stlinkv3.rules and it does: SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3754", \
    MODE="660", GROUP="plugdev", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", \
    SYMLINK+="stlinkv3_%n"

So just to reiterate, my STM32CubeProgrammer does connect to the STM32N6 board but fails on erase either mass erase or the erase prior to programming a hex file.