Cannot send break condition via uart.I have a nucleo board 32l422 and i connected lora rn2483. I can communicate with module but when set this to sleep i cannot wake up module.I tried HAL_LINSendBreak with no success.

[FNtin.1]

LORA DATASHEET

The default settings for the UART interface are 57600 bps, 8 bits, no parity, 1 Stop bit,

no flow control. The baud rate can be changed by triggering the auto-baud detection

sequence of the module. To do this, the host system needs to transmit a Break

condition to the module followed by a 0x55 character at the new baud rate. The

auto-baud detection mechanism can also be triggered during sleep to wake the module

up before the predetermined time has expired.

Note: A break condition is signaled to the module by keeping the UART_RX pin

low for longer than the time to transmit a complete character. For example,

at the default baud rate of 57600 bps, keeping the UART_RX pin low for

226 �?�s is a valid 13-bit break condition, whereas at 9600 bps this may be

interpreted as a 0x00 character. Thus, the Break condition needs to be

long enough to still be interpreted as such at the baud rate that is currently

in use. At 9600 bps a valid 13-bit Break condition must need to be 1,350 �?�s.

[Andrew Neil]

"Cannot send break condition"

Are you sure that it's not sending a break at all, or is it just that the module is not recognising the break that it does send?

"A break condition is signalled to the module by keeping the UART_RX pin low for longer than the time to transmit a complete character."

So is that actually happening?

[FNtin.1]

Thanks for fast reply,To be clear sometimes wakesup. I only tried via hal library and LIN mode.I cannot dig into uart registers.

As RX pin is not used as output pin i think i cant "gpio.writepinLOW" for couple of time.

SO,Could you think an implementation that would be more reliable and working when it's called?

[FNtin.1]

Sorry,yes it is mentioned by Microchip so i cant doubt about it.

[Andrew Neil]

@FNtin.1​  "To be clear sometimes wakesup"

Sounds like your timing is marginal?

Have you actually looked at the timing on the wire?

"As RX pin is not used as output pin"

but that's referring to the LoRa module's "RX" pin - isn't it?

The pin on the STM32 has to be an output to drive the line low!

[Andrew Neil]

So it's the STM32's TX pin that you need to drive low ...

[FNtin.1]

with which way?i cannot write gpio.writepin(low) as its not a general purpose output pin

Sending a coumple 00s seems not working

[Andrew Neil]

Sure it is a GPIO pin.

Not sure if the UART overrides it, though - so you might have to switch it back to GPIO mode to do the break.

If it's just that the timing is marginal, maybe try setting the UART to a lower baud rate to give a longer break?

But, again, you still haven't said what timing you're actually getting at the moment - you really need to know what the actual problem is before trying random things which may or may not solve it ...

[FNtin.1]

Sorry ​for the late reply,I've borrowed a logic analyser and found that when i call Hal_lin_break function generates a LOW signal for about 100us.That figures out that lora module wont wakes up.It needs at least 160us,or 200us to be sure.

So i think that i should try t​hese two methods.

1.Before fuction call,to get low baud rate so the low signal will be longer.

2.i)DeInit uart

ii)Init tx pin as gpio and set LOW for 200us(HAL_Delay(200)

iii)Init uart tx pin again, supposed mo​dule has waked up

I tried 1st method with no success.

2nd method seems to works but it isnt enough flexible

Any ideas?Probably if i could play ​directly with MODER,ODR registers will work?

[Andrew Neil]

@FNtin.1​  ",I've borrowed a logic analyser and found that when i call Hal_lin_break function generates a LOW signal for about 100us"

When dealing with embedded microcontrollers like this, the hardware is a key part of the system - you can't just look at the software in isolation.

Therefore you need hardware test & debug tools - just as much as software tools.

"I tried 1st method with no success."

What do you mean by that?

Did the length of the break not change?

If so, are you sure that the baud rate change actually took effect?

There was a thread on this recently - try a search

"2nd method seems to works but it isn't enough flexible"

In what way(s), exactly, is it not "enough flexible" ?

It should be entirely flexible.