Showing posts with label DFU. Show all posts
Showing posts with label DFU. Show all posts

Thursday, November 17, 2016

STM32F042 USB quirks with libopencm3

Needed a simple microntroller for an RF project, so picked the STM32F042F6P6 from ST.  It's cheap, comes in a 20-pin package, and has a built-in full speed USB device interface. It has an internal oscillator that can be synced to the USB signals from the host, so it doesn't even need a crystal.
It has a built-in DFU bootloader (among other programming options), so it requires no additional hardware to load the program.
After getting a simple LED blinker program to run, I decided to run some USB demo programs from the LIBOPENCM3 package. None of the demos are for this exact chip, but some are for the STM32F072, which is similar. Tried the tests/gadget-zero sample and ... No Go. The program loads and the LED's blink, but the USB device does not show up.
Turns out, there are a couple of subtle differences between this chip and the ones in bigger packages
  • The USB interface pins are shared with two other pins, and by default the USB pins are not connected to the outside world. Need to set a configuration bit so they can be used.
  • The peripheral clock needs to be turned on for the SYSCFG subsystem. I'm not sure whether that's a difference in the chips, or a quirk in libopencm3, but it's needed.
The setup calls at the beginning of the program for crystal-less USB operation are:
rcc_clock_setup_in_hsi48_out_48mhz();
rcc_periph_clock_enable(RCC_SYSCFG_COMP);
SYSCFG_CFGR1 |= SYSCFG_CFGR1_PA11_PA12_RMP;
crs_autotrim_usb_enable()
rcc_set_usbclk_source(RCC_HSI48)
where the highlighted lines had to be added. With those two lines, gadget-zero shows up as a USB device in Linux. I was also able to the a cdc_acm demo working.

Acknowledgments

Several websites mention the pin-remapping issue, but the IFUSB project (github.com/julbouln/ifusb) was where I found the clock-enable issue and solution. IFUSB looks like a nice little peripheral, by the way.
Libopencm3 is at github.com/libopencm3/libopencm3
For programming, I use dfu-util: dfu-util.sourceforge.net. It's already included in Debian and probably other distributions.

Thursday, February 13, 2014

STM32 on Linux, again.

Starting another project using the STM32 micro, so time to update and reinstall the toolchain. This is an update to my previous post on the topic at http://blog.sensicomm.com/2012/01/stm32-stm32f4discovery-arm-eval-board.html

Compiler

Previously I used the summon-arm gersion of GCC http://summon-arm-toolchain.org/
but the git repo says it's "not under active development" any more. They recommend https://launchpad.net/gcc-arm-embedded , which seems to be an offically ARM-supported
version.

It looks like Debian has packaged the launchpad version into the "unstable" branch: http://packages.debian.org/sid/gcc-arm-none-eabi but I'm running "stable" so I got it directly from launchpad instead. Install was simple:
  • Download  gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
  • unpack in /opt,
  • add to PATH
  • Create symlink:  cd /opt && ln -s gcc-arm-none-eabi-4_8-2013q4 gcc-arm-none-eabi

That's my setup, the chosen directory is just a matter of personal preference.

Programming tools:

I'm using the STM32F4DISCOVERY board for development, so there are two ways to get code
into the chip:
  1. Use the st-link USB input to the built-in programming hardware.
  2. Connect directly to the USB port of the STM32F4 chip and use dfu-util.
I used dfu-util before. That's now in Debian, and should still work but I haven't retested it.



Code for the st-link interface is available and built with no problem:
  • git clone git://github.com/texane/stlink.git stlink
  • cd stlink && ./autogen.sh && ./configure && make && make install
Programs are installed in /usr/local/bin: st-flash st-info st-term st-util

An example was successfully placed in flash using:
st-flash write *.bin 0x8000000

Libraries:


The open source libraries and examples at http://libopencm3.org/wiki/Downloads built without problem using the launchpad compiler. My build command was:
PATH=/usr/bin:/bin:/opt/gcc-arm-none-eabi/bin DESTDIR=/opt/libopencm3 make install

ST has standard peripheral library source code on their website, but it doesn't come with Makefiles. A USB serial example at http://vedder.se/2012/07/usb-serial-on-stm32f4/ includes some (all?) of the ST libraries and compiles fine with the launchpad compiler. I downloaded and unpacked STM32F4_USB_CDC.zip and "make" ran without problems. I only had to change the top-level Makefile so that BINPATH points to the directory that arm-none-eabi-gcc is in
(BINPATH=/opt/gcc-arm-none-eabi/bin for my install).

Friday, January 27, 2012

STM32 STM32F4DISCOVERY arm eval board and Linux

Picked up this eval board at the last Embedded Systems Conference, and finally starting to work with it. The chip is a 168MHz ARM Cortex M4 with 12-bit A/D and D/A's . The eval board includes an accelerometer, microphone, and separate audio D/A chip, among other things. Pricing is really interesting. Here are Digikey quantity-1 prices:
STM32F4DISCOVERY $19.50
STM32F407VGT6     $16.00
STM32F103C8T6    $ 5.71
(The F407 is the main ARM chip, and the F103 is a smaller ARM chip used as a programming interface). So the eval board is actually cheaper than the chips on it.

The F407 chip has a built-in program loader using either the serial port or the USB port. Both are supported by Linux tools, so I'm ignoring the F103-based programming port and using the F407's USB port.

Connections: I have USB cables from my Linux box to both the F103's mini-USB connector at the top and the F407's micro-USB connector at the bottom. The mini-usb is just used to supply power to the board, and isn't necessary if an external supply is used.

The programming tool is dfu-util, from dfu-util.gnumonks.org . I downloaded and built the latest version from the git repository. To test it, I used the miniblink example program from the libopencm3 package at www.libopencm3.org/wiki/Downloads . libopencm3 uses the summon-arm toolchain, so I downloaded and built that as well so the example would compile easily. (This also means I now have 5 different versions of GNU GCC for ARM on my system: summon-arm (linaro-based), 2 from CodeSourcery, one from openembedded, and a built-from-scratch GCC. One of these days I'll simplify that).

To program, I connect a jumper between the 3V and boot0 pins on connector P2. After hitting the black reset button, lsusb shows USB devices connected as:
Bus 001 Device 011: ID 0483:df11 SGS Thomson Microelectronics STM Device in DFU Mode
Bus 001 Device 012: ID 0483:3748 SGS Thomson Microelectronics ST-LINK/V2
To use it without being root, I also added the line:
SYSFS{idVendor}=="0483", SYSFS{idProduct}=="df11", MODE="666" GROUP="plugdev" SYMLINK+="usb/stm32_dfu"
to plugdev (in Debian, I just created a new file in the /etc/udev/rules.d directory with this single line in it. Locations may be slightly different in other Linux distributions).
With that done, the command:
dfu-util  --device 0483:df11 --alt 0 \
        --dfuse-address 0x08000000 \
        --download /miniblink.bin
works. I removed the jumper and hit reset again, and a single LED blinks, as expected.

So that's "Hello, World" for the STM32F4DISCOVERY. Now I can start doing real work with it.