four uarts on stm32L433?

[John Griswold]

Posted on September 05, 2017 at 22:05

Is it possible to get four USART/UART devices at once on the STM32L433 in a 64-pin package? I need one UART for input, one for output, one for external logging, and USART1 for debugging.

Is this doable? I've used CubeMX to try various configurations, and I end up short of the goal. I'll also need an ADC and a PWM or DAC, and DMA on at least the input device would be nice.

Suggestions?

[Tesla DeLorean]

Posted on September 05, 2017 at 22:26

Do they have different baud rates?

Could you use the other half of the 'Input USART' for the debugger/telemetry output?

Suggest you pull the Data Sheet 

and a highlighter pen

, print out the pin list and go over the 64-pin column down, and the across the USART lines.

[John Griswold]

Posted on September 05, 2017 at 22:51

Not that simple. The 'input' side also sends commands. All ports run at the same baud rate (921600 - yeah, I know!)

CubeMX shows that all of the pins are not conflicting, but I can only get one to work, apparently, in the mode where I have four UARTs going. Test case is pretty simple - I print a test string to each port at main() after initialization, then target one UART for input/output, and send characters to the L433 using TeraTerm. I can see the printed string, but not the keyed-in data, leading me to think that the input channels aren't working properly on all UARTs.Kind of baffling.

[Tesla DeLorean]

Posted on September 06, 2017 at 03:30

If the pins map then it should work, whether CubeMX/HAL screws up from there who knows.

Make a simple loop, polling the RXNE from each (LP)U(S)ART and echoing back the data.

while(1)

{  uint16_t data;

  if (USARTX->ISR & USART_ISR_RXNE) // Data Pending

  {   data = USARTX->RDR & 0xFF;

   if (USARTX->ISR & USART_ISR_TXE) // should be empty (balanced?)

     USARTX->TDR = data; // Echo back  }

  // repeat for all UART/USART/LPUART

  // ....

}

[Tesla DeLorean]

Posted on September 06, 2017 at 03:32

Which pins/usarts? Have the GPIO banks been enabled/powered correctly?

[John Griswold]

Posted on September 06, 2017 at 15:57

I think this is the crux of the question. For example, I have generated code using CubeMX to initialize all four U(S)ARTs, and a simple test is to print a test string to each UART. In this particular test, only the LPUART works - the other three fail to print to the terminal. If I can't send a character from a UART, it's unlikely that I'll receive a character, so I don't think the UARTs are being initialized properly. 

This is the current configuration - I have not tried to bring in DMA, ADC, or DAC to the mix. I'm focusing on the UARTs for the time being.

Configuration test1

STM32CubeMX 4.22.0Date 09/05/2017MCU STM32L433RCTx

PERIPHERALS MODES FUNCTIONS PINS

LPUART1 Asynchronous LPUART1_RX PC0LPUART1 Asynchronous LPUART1_TX PC1SYS SysTick SYS_VS_Systick VP_SYS_VS_SystickTIM15 ITR0 TIM15_VS_ClockSourceITR VP_TIM15_VS_ClockSourceITRUSART1 Asynchronous USART1_RX PA10USART1 Asynchronous USART1_TX PA9USART2 Asynchronous USART2_RX PA3USART2 Asynchronous USART2_TX PA2USART3 Asynchronous USART3_RX PC5USART3 Asynchronous USART3_TX PC4

Pin Nb PINs FUNCTIONs LABELs

8 PC0 LPUART1_RX 9 PC1 LPUART1_TX 16 PA2 USART2_TX 17 PA3 USART2_RX 24 PC4 USART3_TX 25 PC5 USART3_RX 42 PA9 USART1_TX 43 PA10 USART1_RX

I don't know whether you can determine if this is correct, but it's straight out of CubeMX.

I'll try to implement your test code. I've been using 

HAL_UART_Receive( &huart1, buffer1, 1, 1000);

HAL_UART_Transmit( &huart1, buffer1, 1, 1000);

which works using the LPUART, and has worked for some of the other ports as well. I just haven't built the 'what works' truth table yet.

Thanks for your input.

[Tesla DeLorean]

Posted on September 06, 2017 at 16:37

I'll go over the pins, don't have a L433 to hand.

The purpose of my proposed test is that it doesn't block for a second, and addresses all 4 ports concurrently, talking directly to the hardware. Should provide some baseline truth about what is/isn't working, if you need to look at the GPIO/RCC side as initialized, or the HAL side doing the equivalent.

A secondary test would be to just output 'A', 'B', 'C', etc in a loop to all available ports,

while(1)

{   if (USART1->ISR & USART_ISR_TXE) // when empty     USART1->TDR = 0x41; // A

   if (USART2->ISR & USART_ISR_TXE) // when empty

     USART2->TDR = 0x42; // B

   if (USART3->ISR & USART_ISR_TXE) // when empty

     USART3->TDR = 0x43; // C

   if (LPUART1->ISR & USART_ISR_TXE) // when empty

     LPUART1->TDR = 0x44; // D

}

[Tesla DeLorean]

Posted on September 06, 2017 at 18:38

Pins look Ok, additional options for USART1 on PB6/7 and USART3 on PC10/11

[John Griswold]

Posted on September 06, 2017 at 18:55

Using 

USARTX = huart(n).Instance

I have implemented your test, and it works the same, in general, as the test using HAL_UART_Receive & HAL_UART_Transmit. I haven't filled out the truth table. The other issue is that USART1 doesn't seem to reach the 921600 baud rate that I need. The LPUART does, so that's the fallback. I only need one UART at that speed, really.

[Tesla DeLorean]

Posted on September 06, 2017 at 19:40

Had issues with the L4 NUCLEO's last week not being able to get to 9600 baud, HAL_UART_Init() threw an error, 115200 was fine. Other biter being special enabling of GPIOG. Thinking LPUART1 on PG7,PG8 on L496ZG