This post explains how to ignore the USB storage of the STM32-VL Discovery board so it enumerates in Ubuntu 12.04. Problems arise when you boot your linux system from an external USB drive. The not so obvious solution is really simple.
Over the past couple of years, I’ve managed to accumulate a pile of STM32 discovery boards. I really haven’t done much with them and that is a shame as they are truly capable boards. I’ve decided to try and use them more often in the future. I think I’m addicted to buying these things, my newest addition is the NUCLEO-F030 board. This new board adds yet another version of the ST-LINK firmware to the list.
There are now three versions, ST-Link/V1, ST-Link/V2, and the latest ST-LINK/V2-1. The V2-1 version adds a mass storage device and virtual serial port. However, openocd requires a patch to the latest source code so you can use the Nucleo. I added the patch and it worked great. (see link below)
However, in the process of testing this openocd patch, I realized my STM32-VL Discovery board was no longer enumerating with my Ubuntu 12.04 setup. The STM32-VL Discovery board uses the older ST-LINK/V1 interface. The VL board shows up as a composite USB device with the ST-Link/V1 interface and a Mass Storage device that contains document links to the ST website. The problem with the V1 firmware is the buggy implementation of the mass storage device. Most people on linux just configure modprobe to ignore the usb-storage on the ST-Link/V1 (see link below). Something on my system had changed though, it wasn’t working. After looking at the sysylog output, I realized that when I plugged in the STM32-VL board it was constantly resetting itself because of the usb-storage part of the STM32-VL device. It would start to work and then repeatedly reset.
I had long ago added a file called /etc/modprobe.d/usb-storage.conf that looks like this:
# stlink/v1 ignore mass storage options usb-storage quirks=0483:3744:i
That .conf file is supposed to tell modprobe to ignore the Mass Storage device of the ST-Link/V2. Modprobe seemed to be ignoring my quirks file. In syslog, I found linux trying to mount it:
kernel: [69942.096314] usb 1-3.1: New USB device found, idVendor=0483, idProduct=3744 kernel: [69942.096319] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: [69942.096323] usb 1-3.1: Product: STM32 STLink kernel: [69942.096326] usb 1-3.1: Manufacturer: STMicroelectronics kernel: [69942.096330] usb 1-3.1: SerialNumber: Uÿn^FH<U+0082>HSuP"<U+0087> kernel: [69942.097047] scsi15 : usb-storage 1-3.1:1.0 mtp-probe: bus: 1, device: 18 was not an MTP device kernel: [69943.098593] scsi 15:0:0:0: Direct-Access STM32 PQ: 0 ANSI: 0 kernel: [69943.099301] sd 15:0:0:0: Attached scsi generic sg4 type 0 kernel: [69943.102181] sd 15:0:0:0: [sdc] 64000 512-byte logical blocks: (32.7 MB/31.2 MiB) kernel: [69943.103309] sd 15:0:0:0: [sdc] Write Protect is on kernel: [69943.103314] sd 15:0:0:0: [sdc] Mode Sense: 03 00 80 00 kernel: [69943.104578] sd 15:0:0:0: [sdc] No Caching mode page found kernel: [69943.104583] sd 15:0:0:0: [sdc] Assuming drive cache: write through kernel: [69943.180188] usb 1-3.1: reset full-speed USB device number 18 using ehci-pci kernel: [69943.356184] usb 1-3.1: reset full-speed USB device number 18 using ehci-pci kernel: [69943.532185] usb 1-3.1: reset full-speed USB device number 18 using ehci-pci kernel: [69943.708185] usb 1-3.1: reset full-speed USB device number 18 using ehci-pci kernel: [69943.884192] usb 1-3.1: reset full-speed USB device number 18 using ehci-pci kernel: [69944.060196] usb 1-3.1: reset full-speed USB device number 18 using ehci-pci kernel: [69944.157595] sd 15:0:0:0: [sdc] No Caching mode page found kernel: [69944.157600] sd 15:0:0:0: [sdc] Assuming drive cache: write through
Digging around on google yielded no answers that seemed to work. I finally posed my problem to the ##stm32 IRC channel on freenode.net. PaulFerster quickly provided the clue I needed once I explained my problem. I had recently switched from an ATA unix boot disk to an external USB drive to provide more flexibility with my development system setup. My new setup had a side effect on the usb-storage kernel module. Using a USB drive forces the usb-storage module to get loaded by the initfs device which happens earlier in the boot process. This new bootflow ends up ignoring my modprobe.d configuration changes.
The simple solution to this problem is to run this command as root before you plug in your STM32-VL Discovery board:
# echo "0483:3744:i" >/sys/module/usb_storage/parameters/quirks
That command tickled the insides of the loaded usb-storage module and fixed the problem. I plugged in my board and tailed the syslog output. Here is what it looks like when usb-storage does the right thing:
kernel: [14512.588393] usb 1-3.1: New USB device found, idVendor=0483, idProduct=3744 kernel: [14512.588398] usb 1-3.1: New USB device strings: Mfr=1, Product=2 kernel: [14512.588402] usb 1-3.1: Product: STM32 STLink kernel: [14512.588406] usb 1-3.1: Manufacturer: STMicroelectronics kernel: [14512.588409] usb 1-3.1: SerialNumber: 123456890 kernel: [14512.589160] usb-storage 1-3.1:1.0: device ignored
Notice the line: “kernel: [14512.589160] usb-storage 1-3.1:1.0: device ignored”? That is what it is supposed to do. So the real source of my problem was switching my boot drive from an ATA drive to a USB external one. Hopefully, this will solve the problem for someone else.
ST-Link/V2-1 patch for openocd:
How to ignore the ST-Link/V1 disk in linux (see the modprobe section):