Archive for the ‘ARM’ Category

STM32 design contest

Sunday, November 21st, 2010

STMicroelectroics distributor EBV Elektronic is hosting a STM32 design contest and sends you a STM32 Discovery Kit for free if you register to participate. Mine arrived yesterday and is a welcome dev board for testing purposes :)

Offcourse I entered the contest as well. The project is called FLACie and I intend to get the official FLAC decoder running on the Cortex-M3 core. There is a port done for the Rockbox project of the FFmpeg decoder, but it’s old (5+ years and from before the reference decoder was optimised) and only works on ARM7TDMI controllers. I’m talking about a port based on the reference decoder and optimised to run on Cortex-M3 controllers. General idea is that if it runs on ARM7TDMI cores it must definitely be possible on Cortex-M3 cores.

If this succeeds the VS1053B decoder can be taken out of the musicplayer design. And since that component is the most expensive one it should have a nice impact on the total component cost. Besides it would be a kicker if this actually works!

To be continued…

On a sidenote; remember my rant about shipping costs? The dev board was send through Deutsche Post from Germany using a normal postage stamp. Thankfully no UPS, DHL or any other expensive customer unfriendly courier. Props to EBV for using the postal system as it’s supposed to be used!

Two thumbs up for TI!

Wednesday, October 6th, 2010

2 days ago there was a post on Hack a Day about a nice deal on TI’s new Stellaris robotic evaluation board (EVALBOT). Even though the deal was never intended to be picked by HaD readers (which ordered the board en masse not surprisingly considering the huge discount, even making TI’s eStore crash in the process ;)), it seems TI will hold up their end of the deal:

As some posts already note, the coupon code is only available to ESC Boston attendees. That said, we’re psyched about all of your interest and understand there seems to have been some confusion, so TI plans to fulfill all of the finalized orders to date. We’re working on some logistics in getting the code up and running again for ESC Boston attendees, but proof of ESC registration will be required. Stay tuned.

We hear you about the e-store and are working as quickly as possible to avoid issues in the future. Thanks for your patience.

Bottom line – we’re glad to see the excitement around EVALBOT and look forward to checking out your projects! We encourage you to share them on our e2e Forums at http://e2e.ti.com/

-Jean Anne Booth, Texas Instruments

Posted at 3:05 pm on Oct 5th, 2010 by Jean Anne Booth

I was lucky enough to get through after numerous attempts. So if indeed the board arrives one day, TI has earned another huge plus behind their name. If this is anything like their handling and quality of the MSP430 LaunchPad, we’re in for a treat!

(more…)

Dev boards

Monday, September 27th, 2010

Yee a new ‘toy’ has arrived. After waiting only 3 months to the day, a little carton box containing TI’s MSP430 Launchpad board finally found it’s way to my doorstep. It was cheap, comes with free tools and no shipping costs which is a huge pro if you just want to try a new product. No idea what to do with it yet, but I’m sure something fun can be made with it.

Also very nice are the extras. Apart from the nice box it comes in, it includes 2 controllers (2211 and the 2231 which has an USI and ADC), a 32.768 kHz crystal, headers and an USB cable. And to top it off there are 4 anti-slip pads beneath the PCB (it’s often in the small details). Kudos to TI!

Btw, this thing is actually sold below the actual cost of the parts. Just the 2 LQFP IC’s (a Serial-to-USB Converter and a 16-bit ULP MCU with 55kB Flash and 5120B RAM) are over $10 @1k units.

Speaking of dev boards, ST recently introduced a nice STM32 board. According to ST you can get one for under $10, but I haven’t seen those, not even at the distributors they link to. A more realistic value is €12,55 which boils down to $16,90 incl VAT at today’s exchange rate. Yes that’s right, 160% more than ST advertises with. Still not bad, but saying it’s under $10 is just a big lie.

Anyhow, I’m thinking of getting 1, mainly for quick testing. Right now the Futurlec board and some chips is all I’ve got, which is a bit of a pain when you quickly want to swap boards for some simple testing. Besides that I’m looking forward to giving that ST-link thing a try.

The downside is that ST throws up some barriers. You can only buy the board through big distributors, which for us Europeans means you’re screwed as a private person. These distributors won’t even talk to you unless you place a minimum order value which is way higher than the board alone. ST can learn a thing or two from TI when it comes to bringing their products to a wider audience.

Secondly the whole ST-link thing only comes with Windows software. However no surprise there given their complete lack of non-MS support previously. A bit of a downer, but no show stopper.

Did you hear something?

Saturday, September 18th, 2010

The moment of truth has finally arrived; FLAC playback! After going through all the trouble of switching over to a Cortex-M3 controller and SDIO, this is a pretty gratifying moment :D

On the right you’re seeing SD card access reading 512 byte sectors (yellow) and the DREQ signal of the decoder requesting more data (blue). Playing is a 886kpbs FLAC file and just look at the space in between. That means there’s a lot of room for additional functionality.

Some quick notes about clocks;

  • SPI is running at 9 MHz
  • SDIO running at 7.2 MHz
  • Decoder running with recommended 3.5x multiplier and 1.0x addition

Well I’m off listening to some test tracks :)

Another milestone reached

Sunday, September 12th, 2010

Good news, SDIO is working, including an upgrade from Petit FatFs to FatFs.

Basically there were 2 problems. Some time ago I ripped some stuff from the breadboard to tidy things up a bit. Unfortunately this included a wire connecting the PSU to the right most power rail. As fate would have it this is where I attached the 3,3V of the SD card socket to a few days later. As long as the missing connection was well.. missing, the SD card was powered by the SDIO signal lines through the pull-up resistors. This resulted in unexplainable behaviour such a Kinston card to timeout at CMD8 and a Sandisk card never completing the voltage validation cycle.

The other thing were CRC errors during transfers. 25 MHz is simply too much for the current setup, which in all honesty isn’t really surprising given the long and poor connections. A real PCB and some pull-up resistor tweaking should make a speed increase possible. Currently it’s running at 4,2 MHz (simply because 0x0F is an easy to remember CLKDIV value ;)), but what this means in data throughput numbers… no idea yet.

Oh and it uses DMA, which also is a nice addition!

Practical STM32 differences compared to AVR

Saturday, August 28th, 2010

I’ve been playing with the STM32 header board for a while now, so today I’d like to write about some practical differences between the STM32 and AVR. At first I wanted to use Cortex-M3 instead of STM32, but that wouldn’t be correct since the Cortex-M3 is only the core, while the peripherals is where most of the practical differences lie. Also note I’m talking about programming using C/C++, not assembly.

Clock signals

On an AVR you can simply set/clear a bit in the appropriate register to make a GPIO pin high or low. Not so on the STM32. While the concept of setting a bit remains the same (there are differences such as atomic write access, but you won’t notice those during normal usage), the difference is that they won’t do anything until you enable the corresponding peripheral. Before going any further take a look at the system architecture diagram:

As you can see in this diagram the STM32 has a couple of busses; an AHB and 2 APB busses. Each peripheral is connected to one of those busses and will only do something if it gets a clock signal. After a reset all clocks are disabled, including the system clock (please look up CMSIS’ SystemInit() function for info on enabling the Embedded Flash Interface, the PLL and SystemCoreClock). Before using a peripheral look up which bus it is connected to and set the corresponding bit in the RCC register to enable its clock signal. If for example you want to use GPIOA, you need to set the IOPAEN bit in the RCC_APB2ENR register. Another GPIO difference is that you must choose between 3 speeds; 2MHz, 10MHz or 50MHz.

But that’s not all concerning clock signals. Peripherals such as USARTs and SPI are mapped to the same pins as GPIO pins. Even though you can not use both at the same time, the GPIO pins have to be initialised as usual (clock enabled, input/output, speed and mode (floating/push-pull/etc)) as used by the used peripheral. On top of that you get clocks for the alternate function and the peripheral itself. That’s 3 clock signals total which all have to be enabled.

Shift registers

Another issue I ran into was the use of shift registers. Peripherals such as USART and SPI only have a data register on the AVR. Just write a byte to it and the AVR blocks until the byte is transmitted. The STM32 takes a slightly different approach. You write data to the data register which is blocking. Next the data is moved into a shift register for transmission and execution continues.

In reality this means that your code continues and for example deactivates the chip select signal of some other IC (e.g. the audio decoder in case of the music player) while data is still being transmitted. The result is a partial reception of the data and nothing happens. The solution is to wait for a status bit to clear before deactivating any chip select signal (in case of SPI; the BSY bit in the SPI_SR register as seen in the above diagram).

That’s it for now.

Desk meets head

Saturday, August 21st, 2010

Finally got a change to pick up the STM32 USART issue again after a few hectic days. Which wasn’t a bad thing since it offered a fresh look and I quickly found the root of the problem. The headerfile containing the list of command defines to control the player defined RESET as well. But since I hadn’t touched that file after migrating existing code to the STM32, I never thought of it. Renaming that specific define solved it all and all pieces of the puzzle fell into place.

There’s just 1 thing bothering me. Why didn’t the compiler warn about a redefinition? Even after explicitly enabling all warnings with -Wall you don’t get a redefinition error.

Strange STM32 USART behaviour?

Tuesday, August 17th, 2010

Is my code faulty? Does the STM32F103RET6 have an unknown bug? Could it be a problem with ARM GCC compiler? Who knows?

During the past couple of evenings I’ve been trying to figure out what’s going wrong with it’s USARTs. What happens is when sending multiple characters only the last character is received (characters send right before never leave the controller). The reference manual states this on page 741:

7. Write the data to send in the USART_DR register (this clears the TXE bit). Repeat this for each data to be transmitted in case of single buffer.

and:

The TXE bit is always cleared by a write to the data register.

and on page 742:

When no transmission is taking place, a write instruction to the USART_DR register places the data directly in the shift register, the data transmission starts, and the TXE bit is immediately set.

It even comes with the following figure:

However what happens in reality is that there’s a delay between writing to the USART_DR register and the moment TXE is set. This messes things up.

Take the following code to send a string:

  while(*pSrc)
  {
    USART_SendData(USART3, *pSrc++);
    while(USART_GetFlagStatus(USART3, USART_FLAG_TXE) == RESET);
  }

This is also what the STM32F10x Standard Peripherals Firmware Library USART examples do. However this does not work. The while loop is never entered (try turning on a LED, it stays turned off). Now instead of assuming the TXE bit is cleared by the write, wait for the bit to be set:

  while(*pSrc)
  {
    USART_SendData(USART3, *pSrc++);
    while(1) {
      if (USART_GetFlagStatus(USART3, USART_FLAG_TXE) == SET) {
        break;
      }
    }
  }

This does work (although I can’t recommend it) and a string is transmitted as it should be. So far I’m stumped as to what’s actually going on. Also played around with compiler settings (with/without optimisation), but no effect. It just doesn’t make sense.

Asking around on ST’s e2e community forums has so far resulted in hints and tips, but no solution. Well actually it has left me with the feeling I’d rather chew off an arm than to visit that forum again. The people are great, but the Sharepoint forum software ST uses is a total disaster! And it’s down… again… *sigh*

Anyhow, the investigation continues…

STM32 code upload woes

Wednesday, August 11th, 2010

For the past 2 evenings I’ve been trying to figure out a strange problem I was having while uploading code to the STM32 board. As it stands now the mystery is finally solved. What was happening was that the flash loader wouldn’t recognise the controller…. except when I connected the ground clamp of my digiscope to the board’s grounds. Measured everything and all seemed ok, just as long as the clamp stayed on. Checked the entire chain multiple times from beginning to end, PSU, board, USB to RS-232 converter and cable connections. Nothing to be found….

But then in a rare flash of brilliance I noticed the PSU of the board and the power adapter of the laptop were plugged into wallsockets on opposite sides of the room. Plugged both in on the same side and the problem disappeared. At this time I cannot explain what was going on, but I’m glad it’s solved now. Took enough time to figure this one out.

CMSIS

Sunday, August 8th, 2010

Looks like the chip manufacturers have been busy:

The Cortex Microcontroller Software Interface Standard (CMSIS) answers the challenges that are faced when software components are deployed to physical microcontroller devices based on a Cortex-M0 or Cortex-M3 processor. The CMSIS will be also expanded to future Cortex-M processor cores (the term Cortex-M is used to indicate that). The CMSIS is defined in close co-operation with various silicon and software vendors and provides a common approach to interface to peripherals, real-time operating systems, and middleware components.
ARM provides as part of the CMSIS the following software layers that are available for various compiler implementations:

  • Core Peripheral Access Layer: contains name definitions, address definitions and helper functions to access core registers and peripherals. It defines also a device independent interface for RTOS Kernels that includes debug channel definitions.

These software layers are expanded by Silicon partners with:

  • Device Peripheral Access Layer: provides definitions for all device peripherals
    Access Functions for Peripherals (optional): provides additional helper functions for peripherals

CMSIS defines for a Cortex-M Microcontroller System:

  • A common way to access peripheral registers and a common way to define exception vectors.
  • The register names of the Core Peripherals and the names of the Core Exception Vectors.
  • An device independent interface for RTOS Kernels including a debug channel.

Sounds good and a quick inspection revealed CMSIS is applied to both STM32 and Stellaris LM3S controllers, so this could make swapping out various controllers from different manufacturers a whole lot easier!

Go over to ARM’s website to get the full spec.