STM32H7B3: Taking a FrameBuffer and sending it over USART3 to a computer

[AChan.8]

Hi, I'm currently programming an STM32 H7B3I-EVAL. There are two things I'd like to do: find and extract a FrameBuffer, and send that data to my computer via a debug port. I would just like to make sure that I'm developing this correctly, because I feel like I may be confusing myself by working too low-level or jumping into too many rabbit holes...

Regarding the first part - extracting a FrameBuffer - I've used CubeMX to set the FrameBuffer dimensions to 800x480 (the size of the LCD on the evaluation kit), single buffer, RGB565, and the memory address to 0xC0000000.

All I need to do to access this in C++ is to set a pointer to that address for an array of 800x480 uint16s (since it's 16bpp), correct?

Regarding the second part - sending the data to the computer - I've used CubeMX to set pins PB10 and PB11 to USART3_TX and RX, respectively. I did this because USART3 is designated as the virtual COM port connected to CN21, a microUSB port.

However, the actual communication confuses me a bit... the reference sheet for the board does not specify what the initial register values are, so I'm unsure which of the USART control register bits I actually need to change to enable USART communication to the computer. I do know that the base address for USART3 is 0x40004800, and that there is a transmitter enable bit in USART_CR1, but I'm unsure what to change aside from that.

Furthermore, I'm not sure what would be used to read the incoming information from the evaluation kit on my computer. I'm also unsure about potential settings I'd need to process the incoming data correctly; for example, baud rate, parity bits, etc. This is also an issue since, again, I don't know the initial register settings, so I don't know if the evaluation kit starts as FIFO-enabled, even/odd parity, baud rate, etc.

I'm mainly confused about the communication here and I'm wondering if I'm on the wrong track or if there's a simpler tool for this.

Thanks!

[TDK]

The reference manual of the chip will have the reset register values. The peripheral is disabled at reset, so you will be responsible for configuring everything.

There are examples for the UART. Or CubeMX will generate the initialization for them.

https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/STM32H7B3I-EVAL/Examples/UART/UART_Printf

[AChan.8]

The reference manual I was using is RM045, and I don't see the reset register values... for example, Section 53.8.1 on page 2004 details USART_CR1 (FIFO-enabled), but I don't see the reset values there... am I looking in the right place? I remember also looking in that general section and not finding it.

That being said, that page looks very useful and has the settings I was curious about. One question though - will there be issues if I use PB10 and PB11 so it uses the onboard STLINK-V3E through CN26, instead of the listed PB14 and PB15 which are routed through CN6 and require an external STLINK device?

[TDK]

> RM045

You mean RM0455?

https://www.st.com/resource/en/reference_manual/dm00463927-stm32h7a37b3-and-stm32h7b0-value-line-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

It's at the start of each register. "Reset value"

 

> will there be issues if I use PB10 and PB11...

No issues, except that you won't be able to use the other interface at the same time. You'll also want to ensure those pins are not used on the board for another peripheral by checking the schematic. Most pins on EVAL boards are already spoken for. Also, external pullup resistors are required on UART.

https://www.st.com/en/evaluation-tools/stm32h7b3i-eval.html#cad-resources

[Tesla DeLorean]

Doesn't sound like you're ready for the lower level programming, I'd suggest you stick to HAL level code, and the examples provided there.

Decide what baud rates you want to use, and set both sides to the same settings.

You'll need to write the host side application on the PC to accept the incoming data stream. When you open the COM port selection the baud rate and bit widths then.

Suggest you use 8-bits, No Parity, 1 stop bit, it doesn't need to be more complicated.

[TDK]

I would also echo the advice that HAL is probably more appropriate here, given that you have the TouchGFX level of abstraction already.

Note that sending 800*480*2byte over UART at 115200 baud will take about a full minute. Maybe this is acceptable, maybe not.

[AChan.8]

Ah, no idea how I missed that. Thank you!