Archive for the ‘software’ Category

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.


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:

    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:

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

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…


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.

Finding the limit and power saving

Monday, July 26th, 2010

Well I’m definitely going to make a 20MHz ATmega328p version just to discover where the limit lies with FLAC. Scratch that… apparently Atmel is working with ‘speed grades’ these days, or in other words “Maximum frequency is dependent on Vcc”. Reaching 20MHz requires at least 4.5V and this poses a bit of a problem since all other components require 3.3V or less. Guess this also explains why the 3.3V Arduino Pro Mini board only comes at 8MHz.

In the mean time I’ve been working on getting some basic functionality to work. Currently working are play, pause and stop playback, play next song, continues playback (instead of just 1 song for testing purposes which got a little repetitive after a while ;)), volume control (up, down and mute) and a debug function outputting decode time, samplerate, bitrate and type of file.

Atm I’m trying to get sleep modes working. Also new is card detection. When no card is inserted the AVR goes into the 0.1 uA power down mode. Insert a card and it starts playing. Not fully working yet , but it’s getting there. Also when playback is stopped it should go into idle mode until the play command is received (saving 4 mA).

A command I haven’t got a clue yet on how to implement is shuffle. If anyone has a suggestion,  feel free to add a comment.

SD card reading progress

Saturday, July 17th, 2010

Now that the communication problem has been solved, things are moving forward again. Time for a quick update. I’ve been working on getting the SD card to mount. So far mounting still fails, but things are progressing. Initialising an 8GB seems to work, but after that things go awry.  With a bit of luck reading the card and it’s FAT32 filesystem will work soon!

Mounting works, now if only reading the root directory would work….. :)

Success! Reading files from a SDHC card with FAT32 filesytem works.


Tuesday, July 13th, 2010

Know the feeling where you look back at a problem feeling really stupid? Yep, it’s that time of the week again. A quick look into the makefile and code of the bootloader revealed it sets the UART’s double speed bit. Unsetting this bit solved the communication problem. Grmbl…


On top of the above I also discovered  a typo causing the weird results mentioned earlier. AAAAAARG, I’m off banging my head against the wall…

Something fishy

Saturday, July 10th, 2010

During the past week I’ve spend various evenings getting bluetooth communication and SPI (for the SD card/VS1053) to work, but thus far without success. Something fishy is going on and I haven’t yet been able to put my finger on it. I’ve been using avr-gcc (the one included in WinAVR and Debian testing) and results are unpredictable.


Older is better?

Friday, July 9th, 2010

Having problems with avrdude 5.10 (included in the latest WinAVR, version string “Version 5.10, compiled on Jan 19 2010 at 10:45:23″. Also valid for the latest version in the Debian testing repository) I had to dig a little deeper and ended up with the version included in the Arduino 0018 distribution. Here’s a working commandline:

avrdude -Cavrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\\.\COM11 -b57600 -D -Uflash:w:musicplayer.hex:i

It’s an old version, but confirmed to work: “Version 5.4-arduino, compiled on Oct 11 2007″. Beats me why a 3 year old version works better, but after having unreliable results for days with the latest version, I’m not complaining.

Arduino programming woes

Tuesday, July 6th, 2010

After finally successfully programming an Arduino Pro Mini using avrdude here’s a commandline to remember:

avrdude -v -v -v -v -pm328p -carduino -b57600 -PCOM11 -D -Uflash:w:<xxx>.hex:i

The documentation only seems to mention baudrates of 19200 and 9600 baud (for really old versions) so knowing the above will save you an evening of fruitlessly hunting for answers…

Btw, way to go Sparkfun for not answering questions regarding your own product. It’s been 3 days and not a single word. No points for you this week.