Understanding serial IO misbehavior

[Korporal]

I've been trying to adapt an example piece of code that utilizes a UART from the Visual GDB website.

The adaptations are:

1. Using an STM32F769 Discovery board.
2. Communicate with an ESP8266 device plugged into the board's WiFi socket.

I managed to work out that I need to use UART5 and PD2 as the UART's RX and PC12 as the UART's TX.

The serial details are the same as the example so need to alter those.

Well when I run this code the send appears to do something because the blue data LED on the ESP8266 flashes briefly (during the send) so this tells me either the send is working or at least the TX pin is fluctuating in some way.

However the receive hangs, the only to stop it hanging is a finite timeout or pass 1 as the buffer length. When I pass 1 as the length I can see that it does indeed write to the buffer and in fact writes a 0x00 but nothing more.

Repeated receives hang, so trying to receive 1 byte then again trying that leads to a hang, only the first read of 1 byte ever returns (with an OK status too).

I have two of these ESP8266 devices and they work fine, I can use a USB adapter for them and chat to them via a terminal program and I also have a sophisticated .Net class library I developed that can hammer these devices asynchronously (via the USB COM port) for long periods and they behave very well.

Any ideas about where I'm going wrong are appreciated.

Thanks

Hugh

 ...a short time later... Hmm, I wonder if I must force the device's reset pin high as part of this...

[S.Ma]

Maybe this ESP STM32 Github web hint could bring some clues?

https://github.com/MaJerle

[Korporal · Accepted solution]

@S.Ma​ 

Not easy for me to peruse that codebase, I'm still pretty green with a lot of this stuff and the STM32. However I think that I may have misunderstood the "alternate function" I'd assumed this was specific to the STM32F4 article that I copied my code from, seems its a much more fundamental concept altogether and equally applicable to the STM32F769.

Anyway I found documentation here but as you can see there are three values defined that pertain to UART5

GPIO_AF1_UART5,

GPIO_AF7_UART5,

GPIO_AF8_UART5.

It's far from clear what the 1,7 and 8 refer to or imply, the WiFi device's RX/TX are connected to PC12 and PD2 respectively (that is to the UART5's TX/RX).

So how does one decide which of the three GPIO_AFx_UART5 value to use?

Thanks

[Korporal]

AHHHH - Success - I simply tried them one at a time and 8 leads to real data in the received buffer!!!

[S.Ma]

Coding without reading the datasheet?

[Korporal]

@S.Ma​ 

Well as I say I'm new to this and I did read the datasheet but its almost 2,000 pages long and also I do not understand how one decides on which of these:

GPIO_AF1_UART5,

GPIO_AF7_UART5,

GPIO_AF8_UART5.

At least I did not understand, no idea why alternate function 8 is what I needed, perhaps you know?

Thanks!

[S.Ma]

The RM = reference manual describes the IP blocks (peripherals)

The DS = datasheet is much shorter and represent the physical implementation

Most people will get from DS the package pinout, per pin functions and the magical Alternate function table which the source code reversing was created from.

It;s a landscape multipage table placed just before the memory mapping.

This plus the DMA stream table (RM) are the most vital information to select a package and a board schematic.

[Korporal]

Much appreciated, these are very helpful insights!