Today I figured it out.
What did you figure out, I hear you say...
I finally resolved a problem with a USART on a STM32F407 board, that was easy to spot if I had just looked closely. I just lost a day in trying to find the fault.
I am working with this board made by Olimex (https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware)
And connected it using ST-Link interface to my PC.
I connected the SWD pins to the JTAG connector of the Olimex
SWD-pin-1 ------ JTAG-pin-1 (VCC)
SWD-pin-2 ------ JTAG-pin-9 (TCK)
What did you figure out, I hear you say...
I finally resolved a problem with a USART on a STM32F407 board, that was easy to spot if I had just looked closely. I just lost a day in trying to find the fault.
I am working with this board made by Olimex (https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware)
And connected it using ST-Link interface to my PC.
I connected the SWD pins to the JTAG connector of the Olimex
SWD-pin-1 ------ JTAG-pin-1 (VCC)
SWD-pin-2 ------ JTAG-pin-9 (TCK)
SWD-pin-3 ------ JTAG-pin-4,6,8 (GND)
SWD-pin-4 ------ JTAG-pin-7 (TMS)
SWD-pin-5 ------ JTAG-pin-15 (TRST)
SWD-pin-6 ------ JTAG-pin-13 (TDO)
I connected the serial port (USART6 is pins 3 and 4 of UEXT) of the Olimex to the TX/RX lines of the ST-link (see the green circle)
Then I wrote a program and tested it.
I made sure the PLL of the STM32F407 was running, configured all the needed files.
Looking up the specs for flat cable : https://www1.elfa.se/data1/wwwroot/assets/datasheets/ep171_xxG_dat_en.pdf
I connected the serial port (USART6 is pins 3 and 4 of UEXT) of the Olimex to the TX/RX lines of the ST-link (see the green circle)
Then I wrote a program and tested it.
I made sure the PLL of the STM32F407 was running, configured all the needed files.
- defined the target cpu in stm32f4xx.h (STM32F40_41xxx)
- defined the real crystal frequency to be 12MHz (HSE_VALUE 12000000 in stm32f4xx.h)
- defined the PLL values in system_stm32fxx.c (used cubeMX to verify many times)
- defined the correct baud rate, bits and parity...
It almost worked..
The output of the USART (my print statements) looked fine for about 30 chars and the became a mess.
I googled for a day, checking baud-rates and device initialization.
Changed baud-rates, clock frequencies and everything else.... but still it would go messy after about 30 chars..
Guess what happend, I mixed up TX and RX... Transmit and Receive wires..
But.. but... I can hear you thinking, why did it work for the first 30 chars?
Well.. take a look at my setup..
As you can see the TX and RX wires are 25 cm long and very parallel because it was cut from a standard flat cable.
Looking up the specs for flat cable : https://www1.elfa.se/data1/wwwroot/assets/datasheets/ep171_xxG_dat_en.pdf
Capacitance— 46pF/m for normal 1.27mm flat cable.
So we have about 11 pF between the RX and TX wire.
So we have about 11 pF between the RX and TX wire.
Since the RX wires are not terminated on any side (no pull ups present) the impedance of the RX is very high, so high that the capacitive coupling between TX and RX was enough to swing the RX input the rhythm of the TX wire.
This works because of the large pause at the start of the transmission and possibly the impedance change of the RX during reset of the MCU (did not check this).
After about 30 chars the voltage between RX and TX is equalized and the receiver can not detect the edges of the signal anymore.
Lessons learned :
This works because of the large pause at the start of the transmission and possibly the impedance change of the RX during reset of the MCU (did not check this).
After about 30 chars the voltage between RX and TX is equalized and the receiver can not detect the edges of the signal anymore.
Lessons learned :
- make sure RX is terminated with a pull up, or at least pulled up via software
- check wire connections
- the MCU world is not a digital world, it just looks that way when stuff is working well.
Until next time.
Reacties