STM32F100C6 USART TX pin floating after stopbit

[kimtommy]

Posted on March 25, 2015 at 13:32

Hi 

Issue:Using USART, configured as a normal uart full duplex, we see that the TX pin from the MCU is floating after the stopbit. This seems to be causing issues in some cases.Question 1:What is the default behavior of the TX pin, should it be floating or held high when idle from the MCU or is it correct to add an external pull up?Question 2:Depending on answer on Q1, is there any register setup that could cause the floating TX we're seeing? Additional info:* In reference manual Smartcard communication setup uses a mode where the TX line can be driven by the receiver right after the stop bit. But then the port is configured as Open-drain. We configure it as Push-Pull* Our code is mainly written without use of the standard libraries functions.* Some modified code snippets, this is only to show the register settings:

// Setting PortA Pin2 to Alternate function Push Pull output (remap not shown)

// CNF_ALT_PUSH_PULL_OUTPUT = 0x00000008,  // MODE_OUTPUT_2MHZ = 0x00000002 GPIOA->CRL = CNF_ALT_PUSH_PULL_OUTPUT | MODE_OUTPUT_2MHZ <<  8; // Setting CR1 - ParityBits = 0x0000, No parity (M=0, PCE=0, PS=0)USART2->CR1 = (USART_CR1_RXNEIE | USART_CR1_RE | ParityBits); // Setting CR2USART2->CR2 = 0; // STOPBIT = 0, LINEN=0, CLKEN=0, CPOL=0, CPHA=0, LBCL=0, LBDIE=0, LBDL=0, ADD=0// CR3 left untouched.. CTSIE=0, CTSE=0, RTSE=0, DMAT=0, DMAR=0, SCEN=0, NACK=0, HDSEL=0, IRLP=0, IREN=0, EIE=0I'll add real code if needed depending on the questions asked.Thanks in advance for any comments and help./Kim Tommy #uart-usart-tx-floating

[Tesla DeLorean]

Posted on March 25, 2015 at 16:24

The pin should be programmed in AF PP mode, then it is either driven high or low.

This is chronically awkward code:

GPIOA->CRL = CNF_ALT_PUSH_PULL_OUTPUT | MODE_OUTPUT_2MHZ <<  8; 

The shift doesn't do what you think it does, and you blow away any other settings in the register for pins unrelated to the one you want to change.

[kimtommy]

Posted on March 27, 2015 at 11:54

Hi Clive

Thanks for the comment. It is currently configured as alternate push pull and is driven fine while transferring data. Only during idle time it floats. Do you believe there could be another reason for that? Sorry for the code. As said I did some quick copy paste to isolate what I was trying to do and show the actual values. The real code for setting the register is as follows:

GPIOA->CRL = (((CNF_ANALOG_INPUT | MODE_INPUT) << (4 * I_OUT_SENSE)) |
((CNF_ANALOG_INPUT | MODE_INPUT) << (4 * V_OUT_SENSE)) |
((CNF_ALT_PUSH_PULL_OUTPUT | MODE_OUTPUT_2MHZ) << (4 * TX_INT_COM)) |
((CNF_FLOATING_INPUT | MODE_INPUT) << (4 * RX_INT_COM)) |
((CNF_PULLUP_PULLDOWN_INPUT | MODE_INPUT) << (4 * IO18)) |
((CNF_PULLUP_PULLDOWN_INPUT | MODE_INPUT) << (4 * IO17)) |
((CNF_PULLUP_PULLDOWN_INPUT | MODE_INPUT) << (4 * IO16)) |
((CNF_PULLUP_PULLDOWN_INPUT | MODE_INPUT) << (4 * IO15)));

Assuming we got the defines correct here I think we've configured the CRL register correctly.

[Tesla DeLorean]

Posted on March 27, 2015 at 12:12

I don't know what ''float'' means in this context. I would expect the pin to be high inter-symbol. Perhaps you can diagram what you're seeing and anotate what you think is wrong, or our of place.

The hex value of the data written into the CRL would be of interest here, as I don't have a decoder table for what you're doing, and I'm not a fan of register level programming because it's very fragile, and often a huge time waster. Try your test with a small example coded in the standard peripheral library, and see how it works, and what register values it ends up with. It's a ten minute exercise, and should be illustrative about where the problem lies.