Questions about 9-bit RS485 Multiprocessor Mode and HAL.

[SBurc]

I am working on a project which is an upgrade of an existing project. The existing project was done with an Atmel processor, the current upgrade is based on an STM32F767. The project involves, among other things, multiple serial busses communicating with multiple devices. I used STM32CubeMx to develop drivers for all the ports, and all of them but one is running. However, unknown to me until today was that one of the ports is using what Atmel called "multidrop",which is what I remember from projects a long time ago as "UART 9-bits protocol", where the 9th bit is used as an address bit, so that writing to a specific device can be done by addressing it, and after addressing the address bit is lowered, and data is sent 9 bits with the MSbit as 0 only bothering the addressed device.

First, It is unclear from the documentation if this is what is meant by "Multiprocessor Mode". If so, two things are unclear from the HAL functions. The first is how to generate the address bit in a frame of data. The second is that STM32CubeMX, when entering Multiprocessor Mode, removes the hardware controlled DXEN, which means I have to handle the DXEN as a GPIO if I want to work my 485 Transceiver.

The only way that I can see to handle this right now is manually - define the UART as a standard Asynchronous 9-bit no-parity UART, with the DXEN hardware controlled, and send my data at 16 (9) bit data, like this

0x01rr 0x00tt 0x00tt...

where rr is the address, and the tt's are the data, and on the receive end to stop ignoring data bytes after receiving 0x01mm (mm = my address), taking the 8 LSbits of the data that comes in after that as mine, until another 0x01xx (= some other address) comes.

Am I correct in understanding that what the Multiprocessor mode is giving me is not what I require? And also correct in my understanding that there is no other mode existing which handles this other than what I am showing above?

[SBurc]

I passed this to tech support, in the meantime implemented the solution above - and it works. Sending 9-bit with no parity allows me to handle the protocol correctly. I then modified my question to tech support, and it's been a couple of weeks - so I'm asking here as well...

Now the question is simplified and less urgent. However, out of curiosity, I still do not understand why DXEN is not an option in multiprocessor mode, and if in that mode I could have found a better solution. "

[After Forever]

> DXEN

Do you mean the DEM bit in USART_CR3 for controlling the "driver enable" signal? I don't use HAL, but skimming over the source code the HAL_RS485Ex_Init function seems to be the the one which you want to use. See the stm32f7xx_hal_uart_ex.c file for the documentation.

[SBurc]

That is the function, but in Stm32cubemx, if multiprocessor mode is selected, it automatically deselects the hardware control of DXEN. They seem to be mutually exclusive, which I don't understand from the datasheet.

[After Forever]

Maybe it makes sense, if the RS-485 mode is used for the "master" and the multiprocessor mode is used for the "slaves" (so that the peripheral can detect when it is addressed and decide when to "mute" and when to "wake" (reference manual terminology)).

[SBurc]

My thoughts were that if I were to implement the slaves with similar hardware, and they used a Stm32f7 processor, with an Rs422/485 transceiver controlled by DXEN, I would have to choose between HW control of DXEN and multiprocessor mode. For the master it's not such a big deal, I agree, as I don't sleep until spoken to
In any case, for using the multiprocessor mode, I don't see a "send address" functionality in the Hal either, any other way to handle the 9th bit

[After Forever]

> I don't see a "send address" functionality in the Hal either

Yes, it seems there is is no such function, and frankly - just doing it in your own code is so easy that there is no need for a separate function. After all, sending the address is the same thing as sending any other regular data (with one additional bit set).

[SBurc]

That doesn't make sense to me. Drive enable is much more important on the slave side as they all share the bus, as far as I'm concerned as a master, except for power consumption reasons I could leave DXEN on at all times. But the slaves who are sharing the bus need to respond raising their own DXEN when they transmit, and lowering it when not. It's how they share.