four uarts on stm32L433?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-05 1:05 PM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-05 1:26 PM
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.Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-05 3:51 PM
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-05 8:30 PM
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
// ....
}Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-05 8:32 PM
Which pins/usarts? Have the GPIO banks been enabled/powered correctly?
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-06 8:57 AM
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 STM32L433RCTxPERIPHERALS 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 PC4Pin 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_RXI 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-06 9:37 AM
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; // Aif (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
}
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-06 11:38 AM
Pins look Ok, additional options for USART1 on PB6/7 and USART3 on PC10/11
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-06 11:55 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-09-06 12:40 PM
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
Up vote any posts that you find helpful, it shows what's working..
