Archive for August, 2010

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.

Digital out soon?

Friday, August 27th, 2010

Some missing SMD adapter PCB’s arrived today. Can’t wait to give this combo a try :)

What a sight!

Monday, August 23rd, 2010

It was rainy (40 mm in an hour) and extremely windy (10 bft), but well worth the trip :)

Fake flux

Saturday, August 21st, 2010

After the LQFP soldering adventure 2 weeks ago I thought it might be worth a try and get some el-cheapo flux from dealextreme. Previous buyers of the Amtech flux tube warned they didn’t receive the real thing, and not surprisingly neither did I. No idea yet if this stuff does anything….

And best of all it comes with these inspiring words:

This product contains chemicals knomn to the state of Colofomia and other states to canuse cancer, birth defects or other reproductive harn

Must admit that I’m not looking forward to using this stuff….

Also included were a little cup of Lodestar solder paste (which does look like the original thing, but Lodestar is a China based company) and some disposable medical syringes. Will report back once I had the chance to test this stuff out.

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.

New iTunes terms

Wednesday, August 18th, 2010

Sometimes you wonder what kind of drugs companies give to their employees. Apparently I must accept new iTunes terms and they expect you read them….. all 109 (scrollable) pages. Idiots…

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…

Would you go in?

Friday, August 13th, 2010

Had a little adventure last night while cycling back from a dark place to watch the Perseids. Imagine it’s the middle of the night and you’re all alone on dark roads. You’ve never been there before and it’s raining without the moon illuminating your surroundings. The light on your bicycle is broken and all you’ve got is a small flashlight with a dying battery. Then all of a sudden you find yourself standing in front of some ancient gate. Behind that gate lies a dark forest…. would you go in?

I did… what a rush :D

No more

Friday, August 13th, 2010

Discovered a new spam tactic. They initially post an innocent looking post, similar to a trackback(?)

Blog…

[...] something about blog[...]…

Also the poster looks pretty innocent; blog.blogger.com. I did find it a little suspicious (decent posters usually don’t add a homepage URL), but decided not to mark it as a spam comment at that time. For 3 weeks nothing happened. But during the past 2 days this blog was flooded with bogus comments, apparently all from the same person that initially posted that innocent looking comment. Be warned.

And don’t forget to add this mofo to your blacklist: 89.248.168.40

Prepare your wishes

Thursday, August 12th, 2010

The Perseids are here again! It peaks tonight between 23:30 and 02:00 UT.

Just popped my head outside the window and even though it’s still early, a bright meteor came over. Last year it was clouds clouds and more clouds, but it looks like things are going to be much better this year :)