F7 UARTs Anything special?

[Sking.21]

The F4 board worked fine doing UART DMA. I start to regret this upgrade.

Forget DMA and IT for now, just trying to get F7 polling working.

First HAL_UART_Receive works, but the rest time out.

Register analysis is unenlightening going by RM0385 reference manual.

Values before first read attached. EOBF bit goes high after the read, otherwise normal.

I wish I could find an example of UART polling with LL since I've never done it.

Majerle's usart_rx_polling_F4 is all full of DMA code.

Is there anything peculiar with the UARTs on an F7 (F/45VG)?

Any suggestions on things to try?

[TDK]

HAL_UART_Receive will time out if it's not receiving anything. Is data actually being sent? How do you know?

Note that reading registers will cause RXNE to be cleared when you read the DR register.

Also:

https://github.com/STMicroelectronics/STM32CubeF7/blob/3600603267ebc7da619f50542e99bbdfd7e35f4a/Projects/STM32F767ZI-Nucleo/Examples_LL/USART/USART_Communication_Rx_IT_Init/Src/main.c

[Sking.21]

The first Receive works, buffer contains good data, rc is HAL_OK, the rest time out and return with HAL_TIMEOUT with no data.

Data are sent continuously. Knowledge of how the sending device works, oscilloscope, and the fact that the F4 based board

reads data continuously leave no doubt. Understand that reading registers is invasive;, the thing misbehaves the same whether

they are read or not.

Thanks for the pointer to ALABSTMs work. I'll see what I can get out of that.

Regards

[Sking.21]

Finally solved the original problem. Didn't ever get the polling example going.

It turned out that just _reading_ main memory from a bad location caused uart/dma registers to be reset.

I didnt expect this so I didn't worry about the mem read, expecting to fix it later after I got the uart working

(it was for a segment on the old F4). It was worse that it did not happen every time. Ugh. But I now

worship at the church of read registers.

Thanks again TDK.