Posts Tagged programming

Blinky on the STM32L Discovery

My program seems to have locked-in syndrome, so now I’ll see if I can get it to flash an LED.

A good start would be to check the schematic for where the LED is connected.  There’s one connected to PB6 and PB7, and they’re actually marked with this on the PCB, next to the two push buttons.

Now how to interface them?  The programming manual has a whole section on GPIOs.  It mentions that there are registers for selecting the alternate function (which is how you activate SPI, the USARTs etc), selecting whether the pin is an output or input, whether there are pull-up or pull-down resistors activated, among other things.  One thing worth noting is section 6.3.1, which says “During and just after reset, the alternate functions are not active and the I/O ports are configured in input floating mode.”  What it doesn’t say though is how the registers map to the I/O pins.

The first page of the reference manual mentions one document I haven’t looked at yet: the datasheet.  And sure enough, the memory map in section 5 says that port B is at memory location 0x40020400.  There’s still no mention of how these map to the I/O registers, or how to access the registers from C code.

Figure 1 of the reference manual suggests the GPIO access is via the “AHB system bus”.  A search of the CPU reference manual says that AHB is the “Advanced High-performance Bus”, which doesn’t really mean anything for this.

Another look at the memory map shows that port B goes from 0x40020400 to 0x400207FF.  That’s 1kB of address space, so maybe all of the port registers live here?  If I assume that, I need to set a few bits in GPIOA_MODER at 0x40020400, and turn on the output pin in GPIOA_ODR at 0x40020414 (the reference manual shows the offset of this register as 0x14).  Like this:

    *((int*) 0x40020400) = 0x00005000;
    *((int*) 0x40020414) = 0x00000080;

No that doesn’t work… time to cheat.  I’ll look at “blinky.c”, which is included with the Keil IDE.  It mentions a GPIO clock, maybe I need to enable that.  This idea is a bit unusual to me, since AVRs don’t have a clock for the output pins, but maybe in an ARM you need one so DMA works or something.  Figure 12 contains a rather elaborate map of how the clocks work, but the important bit is on the right: HCLK goes to the AHB bus (which I saw earlier and dismissed!)  This is fed through a prescaler from SYSCLK.  Section 5.3.8 discusses the AHB peripheral clock enable register (RCC_AHBENR) which has a “GPIOB EN” bit at bit 1.  RCC is at 0x40023800, AHBENR is at offset 1C, so this register is at 0x4002381C.

So this gets the LED to light:

  *((uint32_t*) 0x4002381C) = 0x00000002; /* Enable GPIO clock */
  *((uint32_t*) 0x40020400) = 0x00005000; /* Output mode */
  *((uint32_t*) 0x40020408) = 0x00005000; /* 2MHz clock speed */
  *((uint32_t*) 0x40020418) = 0x00000080; /* LED on */

That’s pretty ugly and you wouldn’t want to write too much code like that, so I’ll look at libraries that contain these numbers instead.


Leave a Comment

Getting started with an STM32L Discovery with Linux and GCC

I’ve got the “hello world” working on my STM32L Discovery board that I got about 8 months ago.  It’s not even the canonical blinking light, but it counts up and you only know that it works by using a debugger!  Another site gave me the basic idea, but I needed a few changes to get it working.

    1. Download the Linaro bare metal ARM toolchain (it’s near the bottom of the page).  Extract it somewhere (I put it in /opt).
    2. Download and build OpenOCD.  I’m using version 0.6.0.  I used Checkinstallso I had a managed package:
      tar -zxvf openocd-0.6.0.tar.gz
      cd openocd-0.6.0.tar.gz
      ./configure --prefix=/usr --enable-jlink --enable-amtjtagaccel --enable-ft2232_libftdi
      sudo checkinstall make install
    3. Now something to compile.  I used this:
      // By Wolfgang Wieser, heavily based on:
      #define STACK_TOP 0x20000800   // just a tiny stack for demo
      static void nmi_handler(void);
      static void hardfault_handler(void);
      int main(void);
      // Define the vector table
      unsigned int *myvectors[4]
      __attribute__ ((section("vectors"))) = {
          (unsigned int *) STACK_TOP,         // stack pointer
          (unsigned int *) main,              // code entry point
          (unsigned int *) nmi_handler,       // NMI handler (not really)
          (unsigned int *) hardfault_handler  // hard fault handler
      int main(void)
          int i=0;
      void nmi_handler(void)
      void hardfault_handler(void)
    4. Build it:
      arm-none-eabi-gcc -I. -fno-common -O0 -g -mcpu=cortex-m0 -mthumb -c -o main.o main.c

      I believe the -O0 is to stop the compiler optimizing out the counting loop.

    5. Now for linking. The script on the other site didn’t seem to work for me – when I started the debugger, it looks like it was trying to run code from memory address 0. From what I’ve seen, the flash actually lives at 0x02000000, which might explain the problem. I found another script at ChibiOSwhich seemed to work better. Download the script, then run the linker:
      arm-none-eabi-ld -v -TSTM32L152xB.ld -nostartfiles -o demo.elf main.o
    6. Now extract the binary image from the .elf:
      arm-none-eabi-objcopy -Obinary demo.elf demo.bin

      My binary is a whopping 52 bytes!

    7. Before uploading the binary, the permissions on the Discovery board need changing, because only root can access it at the moment. Put this in /etc/udev/rules.d/90-stm32ldiscovery.rules:
      ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="0666"

      This will give everyone write access to the Discovery. To apply the rules, run:

      sudo service udev restart
    8. Now to start OpenOCD, and upload the binary:
      $ openocd -f /usr/share/openocd/scripts/board/stm32ldiscovery.cfg
      Open On-Chip Debugger 0.6.0 (2012-09-15-16:06)
      Licensed under GNU GPL v2
      For bug reports, read
      adapter speed: 1000 kHz
      srst_only separate srst_nogate srst_open_drain
      Info : clock speed 1000 kHz
      Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints

      In another terminal:

      $ telnet localhost 4444
      Connected to localhost.
      Escape character is '^]'.
      Open On-Chip Debugger
      > poll
      background polling: on
      TAP: stm32lx.cpu (enabled)
      target state: halted
      target halted due to breakpoint, current mode: Thread 
      xPSR: 0x01000000 pc: 0x0800001a msp: 0x200007f0
      target state: halted
      target halted due to breakpoint, current mode: Thread 
      xPSR: 0x01000000 pc: 0x0800001a msp: 0x200007f0
      > reset halt
      target state: halted
      target halted due to debug-request, current mode: Thread 
      xPSR: 0x01000000 pc: 0x08000010 msp: 0x20000800
      > flash probe 0
      flash size = 128kbytes
      flash size = 128kbytes
      flash 'stm32lx' found at 0x08000000
      > flash write_image erase demo.bin 0x08000000
      auto erase enabled
      target state: halted
      target halted due to breakpoint, current mode: Thread 
      xPSR: 0x61000000 pc: 0x20000012 msp: 0x20000800
      wrote 4096 bytes from file demo.bin in 0.325034s (12.306 KiB/s)
      > reset
      target state: halted
      target halted due to breakpoint, current mode: Thread 
      xPSR: 0x01000000 pc: 0x08000010 msp: 0x20000800
      > exit
      Connection closed by foreign host.

      I don’t know what all of those commands do though!

    9. Now to see whether the code is actually running:
      $ arm-none-eabi-gdb demo.elf
      GNU gdb (GNU Tools for ARM Embedded Processors)
      Copyright (C) 2011 Free Software Foundation, Inc.
      License GPLv3+: GNU GPL version 3 or later <>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
      and "show warranty" for details.
      This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi".
      For bug reporting instructions, please see:
      Reading symbols from /home/damien/projects/stm32l-demo/demo.elf...done.
      (gdb) target remote :3333
      Remote debugging using :3333
      main () at main.c:21
      21	{
      (gdb) cont
      Program received signal SIGINT, Interrupt.
      main () at main.c:26
      26	        i++;
      (gdb) print i
      $3 = 496378
      (gdb) cont
      Program received signal SIGINT, Interrupt.
      main () at main.c:26
      26	        i++;
      (gdb) print i
      $4 = 903650
      (gdb) quit
      A debugging session is active.
      	Inferior 1 [Remote target] will be detached.
      Quit anyway? (y or n) y
      Ending remote debugging.

      Yay, it looks like it’s running!

A program isn’t of much use if it can’t communicate outside of the chip, so driving I/O will be next. There looks like three options:

  1. Write to the hardware directly.  This involves looking through the CPU’s user manual, and working out how to access the I/Os.
  2. Use another library to access the hardware.  This is much like how you write AVR code – you access all of the I/Os through C library calls.  ST supplies a library, while it doesn’t have a particularly nice license it’s probably a good starting point.
  3. Use a operating system like ChibiOS, which has support for this board.  Having developed stuff for the AVR, I think it would be nice to have the resources of a real operating system – I wouldn’t have to worry about implementing scheduling and interrupts myself.

Hopefully one day I’ll try these out and get around to writing about the results!

My next post describes a what the code in this example does.

Comments (2)