Archive for the ‘testing’ Category

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…

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.


Tuesday, July 27th, 2010

Couldn’t resist and upload the FLAC patch to the VS1053b. Tried the lowest bitrate I could find (877kbps) and started playback. Guess what, it played. Not fluently though, SPI transfers went through the roof and DREQ was active 100% of the time, so it wouldn’t respond to anything. But hey it played better than expected!

Hmmmz… AVR  running @20MHz @5V, add a couple 10+ MHz logic level converters and see what surprise that brings… just sounds a whole lot better after this little experiment :)

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.

I don’t think she can hold much more Captain! She’s gonna blow!

Sunday, July 25th, 2010

It was doubtful from the start, but by now it’s becoming increasingly clear the AVR isn’t going to cut it when it comes to playing FLAC. It’s close, but even at 20 MHz it’s likely any peaks in bitrate will ruin the party. Since Friday I’m been throwing various MP3 and Ogg Vorbis files at the decoder while monitoring data requests.

While all files played fine some variable bitrate files occasionally showed peaks of over 60% at 256kbps. Now take a FLAC with 4 times the bitrate; 1000kbps (average!). In the current setup the AVR runs at 8MHz. Max speed available is 20MHz, only 2.5 times the current speed. Due to the nature of average bitrates, one can’t predict the exact numbers, but you’ll have a pretty good idea of how this is going to end. Maybe with some clever programming and optimisations it could be done… maybe.. could… Don’t know about you, but I don’t like those words. Would be nice to know where the limit lies in reality, so who knows, maybe I’ll give it a go one day.

Time for plan B. Next post, so check back soon.

Let’s dance!

Friday, July 23rd, 2010

We have lift off! Reading the datasheet has once again proved to be the key. The SCI_CLOCKF register is initialised to 0×00 at power up. This means the decoder’s DSP is working at 12.288MHz with a max SPI write speed of 3.072MHz. The result is 2 fold; either the DSP hasn’t got enough decoding power and/or data transfers go out of sync. The ATmega328  is using it’s max SPI speed of 4MHz, roughly 1MHZ more than the decoder. You don’t have to be a rocket scientist to imagine this is a disaster waiting to happen.


Almost there…

Wednesday, July 21st, 2010

First the good news; I’m getting clearly recognisable audio output.

Now for the bad news; output a also clearly distorted and slowed down and I have no idea why yet. In the waveform below you can see what I mean. Just right of the middle is a flat piece in both channels. This goes on throughout the song. At the moment I’m not sure if this is the only thing wrong or if there’s more going on. For now my guess would be there’s something wrong with sending audio data to the decoder. Or data can’t be read fast enough, but if that’s the case the whole thing needs some rethinking as this is just a lowly 128kpbs MP3 file.

Update: DREQ has a duty cycle between 15 to 20%, so the decoder isn’t starved of data. Same goes for the SD card, it’s select signal is only active for around 11% of the time.

Hardware merge

Monday, July 19th, 2010

For the first time all components sit together on a breadboard (well actually 2 because the decoder board is so wide). And yes, things still work – UART, SDHC reading and decoder tests. Code wise things are also looking good. There’s still lots to do, but seeing less than 8kB FLASH and 850 byte RAM is used so far (without the FLAC patch) my current concern is speed. Doing a directory listing takes much longer than expected. Slow is normal at this stage (no 512 byte sector reading, dumping via ‘slow’ UART), but still.

The next step will be attempting to play a couple of songs, starting with a low bitrate MP3 up to a 50MB FLAC file. In the meantime, enjoy these two shots;

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…