STM32F051 USART Not working

[jprinster]

Posted on February 01, 2013 at 00:39

I created some simple code on the STM32F05-Discovery board to write a byte of data repeatedly out USART1.  However when I run this code on my target board the USART doesn't send the data.  The TXE line goes low and never comes up so the USART is effectively dead.  (USART2 seems to be working fine, but I need that for another purpose so I can't just switch.)  Has anyone seen this problem? 

The Discovery board runs an STM32F051R8 (64 pin) while my target board runs an STM32F051C8 (48 pin).  On both boards USART1-TX is PA.9, so I shouldn't have any pin reassignments.  My code enables no other I/O pins or any other functions of the chip other than USART1.  My target processor is running since I can step through the code with a debugger. I'm stumped, and ST hasn't responded to my questions other than asking for code.  The errata sheets don't mention any issues with the USART.  I tried replacing the chip on my target just in case it was damaged, but that didn't make any difference.  My next step is to try the C6 or C4 version in case there is a die error. Has anyone seen this problem or have any suggestions? #usart #stm32f051

[Tesla DeLorean]

Posted on February 01, 2013 at 00:48

I doubt it's a die error both packages likely share the same die with different bond out lists.

I'd look a lot closer to home for failures, check for solder shorts, PCB errors, or unexpected net connections. Probe the board, xray it, replace the chip or try a couple of other boards. Of course ST is going to ask for code and schematics, it's what I'd expect to see before I sent a validation team into looking at silicon issues.

[Tesla DeLorean]

Posted on February 01, 2013 at 01:01

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/stm32f0%20discovery%20usart1%20tx%20stays%20high&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentv...

[jprinster]

Posted on February 04, 2013 at 17:28

Some additional findings.....

It turns out that my baud rate was set too high.  I was running the USART at 2250k baud.  This number was chosen since it was the maximum baud I could push the USARTs on the STM32F103 chip my target board would be talking to.  The reference manual for the F103 lists that baud rate.  However, in the reference manual for the F051 it lists 2000k as the fastest.  Strangley, 2000k doesn't work on the F051C8 either!  916k works, so I'll have to see what the true maximum is and what are the error rates. Does anyone understand why these higher baud rates work on the F051R8 but not on the F051C8? 

[Tesla DeLorean]

Posted on February 04, 2013 at 17:53

The data manual (DM00039193 Rev 2) I'm looking at states both support up to 6 Mbps, this would depend on the bus clocks being 48 MHz, and the USARTs in 8x over sampling. USART2 is not present of the 16KB flash parts.

If you're doing RS232 level conversion, a lot of those parts filter >1MbpsThe device embeds up to two universal synchronous/asynchronous receiver transmitters (USART1 and USART2), which communicate at speeds of up to 6 Mbit/s.

[jprinster]

Posted on February 05, 2013 at 01:25

And the solution to the problem.....

It turns out I did not have the system clock set correctly.  I had developed my code starting with examples from the Discovery board samples and built up a working prototype.  It turns out that although the crystal X1 is not installed, the processor is getting an external clock from the ST-LINK processor.  This means the code examples are configured with the system clock as HSE.  My target board, however, was designed to use the internal clock to save on parts.  It needed to be configured as HSI.  Once I realized I had it configured wrong and fixed it, the master clock was running at 48MHz and the baud rates got zipping along back to normal.  The example code best to start with is the following that came with the Discovery board since it has a convenient define to set the clock as HSE or HSI in system_stm32f0xx.c.  There's also a great snippet in main.c for exposing the master clock onto pin PA.8. stm32f0discovery_fw\STM32F0-Discovery_FW_V1.0.0\Project\Peripheral_Examples\RCC So at least I'm a little smarter now. By the way, thank you Clive for your responses.  I've seen many of yours on various postings and they are always quite helpful.