EVALBOARD STM32L476G USART1 receive problem

[guillaume-dugast]

Posted on June 01, 2016 at 14:23

Hello,

I am working on the STM32L476G board, with my own code (except using: stm32l4xx.h, stm32l476xx.h, system_stm32l4xx.h,startup_stm32l476xx.sand core_cm4.h). Which means that i'm building my own usart driver in this way: i.e.:

usart[id].reg->ISR &= ~ USART_ISR_TXE;

I'm trying to have a functionnal RS com through the usart 1 rx and tx pins, with this config: 8bits, even, 1 stop bit, no hw flow control. I have configured the usart 1 and the transmission works. (tested on an hyperterminal and with an analyzer (scanastudio)). I have issues trying to get usart 1 reception working (for a couple of days now :\ ) Do you think it can be due to the pinning of the eval board? Is there any other way I can test it? What is going on exactly? - starting programm - initializing usart1 - then I have an interrupt with ISR.FE, ISR.CMF and ISR.RXNE set - but, as soon as go to the next instruction (with a JTAG debugger), and, without doing anything (the line can be __ASM(''nop'')), the ISR.RXNE is cleared by i-don't-know-who. After this, the RXNE flag is not set anymore. Thank you for your time and sorry for the bad english.

[Radosław]

Posted on June 01, 2016 at 14:40

1. For pinning problem check schematic user manual for board. (check JP15)

2. Register which reading them can clear some flags, should not be view in any view in debug window.

[guillaume-dugast]

Posted on June 01, 2016 at 17:26

Thanks.

You were right about the debugger dilema.

I have closed any register window and focus now on my rx ring buffer content.

After reseting the µC, the rx buffer is now putting the value ''0x00'' in his first index, and then no more data arrives. But I don't send any ''0x00'' value! all data which is sent is  between 0x0A and 0xFF. I still can see with my analyser the data coming on the rx pin...

[Tesla DeLorean]

Posted on June 01, 2016 at 17:36

The debugger doesn't have magical access to the registers, if you have a ''view'' on the screen showing you what is in the RDR it is because it has READ it, and in doing so will clear the RXNE bit in the status register.

When debugging the USART put values in memory locations you can look at, don't park a register view over the peripheral. It is invasive.

[guillaume-dugast]

Posted on June 06, 2016 at 10:42Any other clues?- maybe gpios config?- usart config?- clocks?- anyhing else?

[Tesla DeLorean]

Posted on June 06, 2016 at 12:49

All of the above, remember I can't see anything you are doing. Describing it with prose doesn't help me. Suggest you review available board examples and sample code.

[guillaume-dugast]

Posted on June 06, 2016 at 18:22 Yes i know Clive, I don't think i'm allowed to share the code, and I understand how it can be difficult to help me in those conditions. whatever, i assume i can send the following part. What is going on now? IRQs are active. I can send data to the right baudrate through rs4 Data is well formed (i can see it on analyser and on hyperterminal) I can also receive data, but the received data is corrupted (framing error). It is not due to baudrate cause i've checked it on my transmission and it's ~9568b/s i.e.: i send 0x58 with labview, i get 0x (rxinv = false, datainv = false, and lsb first) Furthermore, I can see the right data (0x58) on the RX pin with my analyser, so it's coming from the software... what can cause framing error? thank you for your time.

void process_irq(void)
{
// read interrupt : frame error
if(USART3->ISR & USART_ISR_FE)
{
USART3->ICR |= USART_ICR_FECF; // clear interrupt
debug.error_cnt++;
}
// read interrupt : character match
if(USART3->ISR & USART_ISR_CMF)
{
USART3->ICR |= USART_ICR_CMCF; // clear interrupt
debug.error_cnt++;
}
// read interrupt : overrun error
if(USART3->ISR & USART_ISR_ORE)
{
USART3->ICR |= USART_ICR_ORECF; // clear interrupt
debug.error_cnt++;
}
// read interrupt: rx
if(USART3->ISR & USART_ISR_RXNE)
{
UART_fill_rx_buf(id); //receive data
}
// read interrupt: tx
if(USART3->ISR & USART_ISR_TXNE)
{
USART3->ISR &= ~ USART_ISR_TXE; // clear interrupt
//doing some stuff here
}
}

[Tesla DeLorean]

Posted on June 06, 2016 at 21:23

I'd probably start with the USART1 RS232 port of the STM32L476G-EVAL board, doing a polled echo back after an initial message string output.

The TXE interrupt can be cleared by writing TDR, if you don't have data to send you need to disable the TXE interrupt.RS485 will be complicated by the direction the USART and transceivers are configured in.Framing errors come from seeing signal transitions that fall outside expected intervals, and expectations for start/stop bits.RS232/RS485 level converters typically also invert.