Skip to main content
JGreg.2
JGreg.2
Associate III
May 29, 2020
Solved

UART Tx low state level

  • May 29, 2020
  • 7 replies
  • 3172 views

Hello, I am trying to make communicate a NUCLEO STM3F030 with a STM32F030K6T6 mounted on a custom pcb.

Tx sends from NUCLEO is ok when i check it on an oscilloscope but when i connect the power supply of my pcb on the NUCLEO (or even on an external power supply), the TX low state level is shifted from 0 to 600mV without understanding why. Here are my connections:

  • VDD (5V) of the pcb is connected to the 5V pin of the CN6 arduino connector
  • GND of the PCB is connected to any ground on the arduino connector (let's say GND pin under 5V pin)
  • Rx of the STM32F030K6T6 (pin PA10 without any HW component on the line) on the custom pcb is connected to the TxUART1 of the NUCLEO

Note: i observe directly at the oscilloscope the Tx signal and the GND discussed above.

Did i do something wrong or missing anyconfiguration?

Thank you in advance,

This topic has been closed for replies.
Best answer by JGreg.2

ok, it now works well. Indeed TX were connected to tx... my bad ! :D

I have another issue and maybe you could help me:

I now can send well good commands to the STM32 mounted on the custom pcb and i see that he responds well (i can see and decode the datas from oscilloscop).

But unfortunately, the receive of the nucleo does not work well..

I use:

int data1 = 0x21 ;
int data2 = 0x22 ;
char *datachar1 = (char*)&data1 ;
char *datachar2 = (char*)&data2;
char *data = (char*)strcat(datachar1, datachar2) ;
char *msg = "KO \n\r";
char *Rxbuffer = NULL ;
int status ;
 
 
while (1)
{
HAL_UART_Transmit(&huart1, (uint8_t*)data, strlen(data), 0xFFFF);
status = HAL_UART_Receive(&huart1, (uint8_t*)Rxbuffer, 2, 65000) ;
if ( status == HAL_OK )
 {
 HAL_UART_Transmit(&huart2, (uint8_t*)Rxbuffer, strlen(Rxbuffer), 0xFFFF); //send to monitor the reception of uart1
 } else {
 HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), 0xFFFF);
 } 
 HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5) ; //to visualiy check on the nucleo that the main loop is still running
 HAL_Delay(5000) ; 
}

Any tips ?

Note: whatever the timeout value i put as argument of the HAL_UART_Receive function, the delay time i see thanks to the data monitored is the same. Is it normal ?

7 replies

waclawek.jan
waclawek.jan
Super User
May 29, 2020

> Tx sends from NUCLEO is ok when i check it on an oscilloscope

> but when i connect the power supply of my pcb on the NUCLEO (or even on an external power supply),

> the TX low state level is shifted from 0 to 600mV without understanding why.

I don't understand. Can you please make a drawing/simple sketch, or maybe even a photo of your setup, showing us the connections, and where the problem exactly happens?

Can't the problem be related to connection to the STLink's pins for VCP on the Nucleo?

JW

TDK
TDK
May 30, 2020

Pin PA9 being used on the Nucleo board?

Might be a diode being used as a level shifter, so the line stays one diode drop above 0V. Surely there's something on that line to explain it.

You drop the 5V down to 3.3V to run the device right?

"If you feel a post has answered your question, please click ""Accept as Solution""."
JGreg.2
JGreg.2Author
Associate III
June 2, 2020

Hello,

Thanks a lot for your answers.

waclawek.jan, you ll find below a simplified sketch to get you better understand the connections of my circuit.

0693W000001pplYQAQ.png

TDK, this is the software tool (STM32cubeMX) who has selected by default the TX and RX lane of the STM32 uart of the NUCLEO pcb).

For more explanation, when i send things on the TX lanes, the levels (high level is 3v3 et low level is 0) are good but, when i turn on the external 5v power supply, only the low level is shifted up to 0.6V, the high level state remains good.

I agree that there might be a diode issue (600mv corresponding to a average forward diode voltage).

JGreg.2
JGreg.2Author
Associate III
June 2, 2020

Note: when i use RX (and also TX) lane of the STM32F030 mounted on my custom pcb to communicate with a computer (via an external RS232 converter), there is no issue of levels so i guess the issue is coming from the NUCLEO board.

waclawek.jan
waclawek.jan
Super User
June 2, 2020

Do you have a good and solid ground connection between the two boards?

Do you have a pullup set for PA10 in STM32F030K6 on the custom board? If yes, is there any change if you switch it off?

Is PA9 on the Nucleo board disconnected from the STlink on Nucleo (VCP solder bridges, see Nucleo manual)?

JW

JGreg.2
JGreg.2AuthorBest answer
Associate III
June 2, 2020

ok, it now works well. Indeed TX were connected to tx... my bad ! :D

I have another issue and maybe you could help me:

I now can send well good commands to the STM32 mounted on the custom pcb and i see that he responds well (i can see and decode the datas from oscilloscop).

But unfortunately, the receive of the nucleo does not work well..

I use:

int data1 = 0x21 ;
int data2 = 0x22 ;
char *datachar1 = (char*)&data1 ;
char *datachar2 = (char*)&data2;
char *data = (char*)strcat(datachar1, datachar2) ;
char *msg = "KO \n\r";
char *Rxbuffer = NULL ;
int status ;
 
 
while (1)
{
HAL_UART_Transmit(&huart1, (uint8_t*)data, strlen(data), 0xFFFF);
status = HAL_UART_Receive(&huart1, (uint8_t*)Rxbuffer, 2, 65000) ;
if ( status == HAL_OK )
 {
 HAL_UART_Transmit(&huart2, (uint8_t*)Rxbuffer, strlen(Rxbuffer), 0xFFFF); //send to monitor the reception of uart1
 } else {
 HAL_UART_Transmit(&huart2, (uint8_t*)msg, strlen(msg), 0xFFFF);
 } 
 HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5) ; //to visualiy check on the nucleo that the main loop is still running
 HAL_Delay(5000) ; 
}

Any tips ?

Note: whatever the timeout value i put as argument of the HAL_UART_Receive function, the delay time i see thanks to the data monitored is the same. Is it normal ?

waclawek.jan
waclawek.jan
Super User
June 2, 2020

Please start a new thread. Describe what's the expected behaviour and what is the observed.

In this thread, please select your post above which explains what was the problem as Best, do that the thread is marked as solved.

JW

Terms & ConditionsAccessibility statement