bzt
Posts: 175
Joined: Sat Oct 14, 2017 9:57 pm

[Solved] UARTs break

Wed Dec 13, 2017 8:38 pm

Dear All,

I've implemented UARTs (both PL011 and mini-UART), but I don't know how to detect break condition on serial line. This is what I've got so far:
1. Up to and including Pi2, UART0 was the default UART with fixed clock, and UART1's clock was GPU relative.
2. Since Pi3 UARTs are reversed; UART1 is now the default (meaning with fixed clock rate, and now UART0 depends on GPU clock).
3. According to BCM2835 peripherals page 179 and DDI0183 page 50, PL011 has a register with break condition status bit (DR bit 10).
4. On the other hand mini-UART is just 16550 like. Maybe I looked over it, but I couldn't find any break condition status bit in BCM2835 on page 10.

According to my experiments on Pi3, unfortunately 2. is true. That is a difference in BCM2837 to BCM2835. I was unable to set the correct baud rate for UART0 on real hw, only on qemu. Neither of the examples work, nor the linux code. I've seen others have reported linux driver issues too. UART1 works perfectly on real hw as well as on qemu, but I don't see a way to detect break condition.

So my question is, how to reliably set baud rate for PL011 or detect break on mini-UART on BCM2837?

Thanks,
bzt

EDIT: solution: you must set the clock rate of uart via mailbox for the divisor to be consistent.
Last edited by bzt on Sun Dec 17, 2017 1:50 pm, edited 2 times in total.

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: UARTs break

Wed Dec 13, 2017 9:21 pm

I dont use break much unless absolutely have to, problem is what is the definition for starters, how long does it have to be asserted to define a break? And then does the uart detect it at all, or detect just a framing error? Are you seeing a framing error and if so does the rx buffer have any data with that framing error?

worst case you can wire the pin to a gpio (in addition to the gpio for uart rx) and interrupt or otherwise monitor the state of the pin vs a timer and detect that way...

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: UARTs break

Wed Dec 13, 2017 9:22 pm

or just dont use the mini-uart if you want to detect break.

bzt
Posts: 175
Joined: Sat Oct 14, 2017 9:57 pm

Re: UARTs break

Thu Dec 14, 2017 9:37 am

Dear dwelch67,

Thank you for your response.
dwelch67 wrote:
Wed Dec 13, 2017 9:21 pm
I dont use break much unless absolutely have to, problem is what is the definition for starters, how long does it have to be asserted to define a break? And then does the uart detect it at all, or detect just a framing error? Are you seeing a framing error and if so does the rx buffer have any data with that framing error?

worst case you can wire the pin to a gpio (in addition to the gpio for uart rx) and interrupt or otherwise monitor the state of the pin vs a timer and detect that way...
Well, break is a signal on serial line which cannot be generated by normal means. I think that's the definition, and I haven't seen (so far) any controller having problem detecting it or misinterpreting it as a framing error. Also true I came from a desktop and server appliance world, micro-controllers are new to me.

The difference to any other signal makes it ideal for requesting some privileged system function over serial console. Many OS I've used over the years used break for that purpose, starting with VMS, but don't go that far, there's Linux's magic SysReq menu.

It could have been used for many other things too. For example raspbootin scans input buffer for ^C^C^C to send the kernel to RPi3. That's not ideal as the user can press (Ctrl)+(C) three times in a row. A break signal would be a more appropriate choice.
dwelch67 wrote:or just dont use the mini-uart if you want to detect break.
I would, but how can I reliably set pl011's baud rate? I couldn't find any example which works on my real hw. I can set everything up properly (GPIO mapping, 8N1 characteristics), it's only the baud rate that is not 115200 no matter what I do. The only thing I haven't tried are dts overlays, which I want to avoid if possible as I don't use the Linux kernel.

bzt

User avatar
Arjan
Posts: 256
Joined: Sat Sep 08, 2012 1:59 pm

Re: UARTs break

Sat Dec 16, 2017 6:17 pm

http://www.raspberrypi-dmx.org/
Open Source DMX/RDM/MIDI/OSC/Art-Net/sACN solutions

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: UARTs break

Sun Dec 17, 2017 5:49 am

I have been forced to use break from time to time, it is a framing error by definition, the stop bit doesnt arrive at the right time and you need to re-sync. (think of it is a start bit that lasts longer than a character, or a bunch of zeros that stop through and beyond the stop bit) Each uart has its own way of generating and detecting if possible at all (for that uart). Because of how problematic they are (windows nt 4 days a break would piss off the microsoft driver and cause havoc, was a royal pain, they didnt implement hardware flow control correctly in those days either, dont bother with windows much so dont know if things ever improved), I encouraged the engineer to stop using them. Dont think he did but the next person did something else.

Looks like there is an answer to your problem above, you should check that out.

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: UARTs break

Sun Dec 17, 2017 5:51 am

super simple way to test break and other framing errors is to feed the unit under test with a uart set for half or slower speed, write a 0x00 at 57600 into a 115200 unit under test and it looks like a break. feed other bit patterns and they look like various other things some legal some not pretty easy to determine the expected result.

bzt
Posts: 175
Joined: Sat Oct 14, 2017 9:57 pm

Re: UARTs break

Sun Dec 17, 2017 12:04 pm

Thank you for your answers!

@Arjan: I know how to detect break on pl011, my problem is the baud rate is not correct. Although the source you linked has an interesting part that may solve my problem. https://github.com/vanvught/rpidmx512/b ... dmx.c#L830

@dwelch67: are you suggesting for detecting break on aux one should handle it as a framing error and force resync? Interesting idea, I'll definitely look into that, thanks! I don't know much about win, as I've said. I've only used win7 on one machine in the last 20 years at my workplace, where there were a department to install and configure it. I'm more like a unix guy :-)

Cheers,
bzt

bzt
Posts: 175
Joined: Sat Oct 14, 2017 9:57 pm

Re: UARTs break

Sun Dec 17, 2017 1:39 pm

@Arjan: that was it, thank you very much! I've added clock setting to my code and it works perfectly! I can set 115200 baud rate for UART0 consistently (either on qemu or on real hw). Now ARM DDI 0183F page 3-12 makes perfect sense to me!

Thanks a lot!
bzt

dwelch67
Posts: 944
Joined: Sat May 26, 2012 5:32 pm

Re: [Solved] UARTs break

Tue Dec 19, 2017 7:02 pm

Nope, just stating that a break is a framing error. uarts are not all built equal (although a lot like/try to clone the 16550). So if there isnt a specific break detect and/or it doesnt work then perhaps a combination of framing error and rx data maybe you can assume break from that. I have not looked at these uarts on this topic so dont know what I would try...

bzt
Posts: 175
Joined: Sat Oct 14, 2017 9:57 pm

Re: [Solved] UARTs break

Thu Dec 21, 2017 11:38 am

dwelch67 wrote:
Tue Dec 19, 2017 7:02 pm
Nope, just stating that a break is a framing error. uarts are not all built equal (although a lot like/try to clone the 16550). So if there isnt a specific break detect and/or it doesnt work then perhaps a combination of framing error and rx data maybe you can assume break from that. I have not looked at these uarts on this topic so dont know what I would try...
"Nope"? Sorry if I was unclear, that's exactly what I meant :-) I wanted to say detecting break in a framing error handler seems to be a good idea. My thinking was like this:
1. On RPi with a serial cable on pins 14/15 PL011 can distinguish between framing error and a break, so it is possible to tell them apart
2. If AUX does not detect break, only framing error, then the same algorithm PL011 uses could be used by software in a framing error handler
3. To implement 2. one would need all the information PL011 hw has and use in that algorithm
4. Because break in length is not a multiple of a character length, to continue normal operation, one would need a re-sync

I'm 100% sure about 1., 2. and 4. What I don't know, is 3. Originally I was thinking about dumping all the device's registers in a dummy handler, and then feed it with several breaks and framing errors, and see in the dumps what's the difference (if any difference exists at all, there's a chance what PL011 hw uses to tell them apart is not exposed in user readable AUX status registers at all). Maybe a rx data is required, but not sure, I'd bet on it's not doable. Let's say break is 1,5 length of a character. In that case you'll need a longer than 1 character length to be able to detect framing error (to make sure it's not a valid zero character you're receiving). That means you are left with a less than 0,5 length signal remaining, which (I assume) cannot be read as a normal rx data, hence the need for a re-sync in the first place.

But I'm just guessing here, and doing think experiments. Framing error handler that can detect break by software seems doable in theory, but definitely needs more empirical information. If you cannot read all the information in the error handler, including reading shorter than a full character length signal, or if there's no difference in AUX register's bits for a framing error and a break, then software emulation cannot be done in practice for sure. Your idea led to a theory that can be checked by some experiments, which is really great! I like that!

bzt

rpimaker
Posts: 14
Joined: Mon Jun 11, 2018 2:30 pm

Re: UARTs break

Mon Jul 09, 2018 2:39 pm

bzt wrote:
Sun Dec 17, 2017 1:39 pm
@Arjan: that was it, thank you very much! I've added clock setting to my code and it works perfectly! I can set 115200 baud rate for UART0 consistently (either on qemu or on real hw). Now ARM DDI 0183F page 3-12 makes perfect sense to me!

Thanks a lot!
bzt
Hi,
link on github seems broken, could you please write here the code you used?
Thank!

bzt
Posts: 175
Joined: Sat Oct 14, 2017 9:57 pm

Re: UARTs break

Wed Jul 11, 2018 4:13 pm

rpimaker wrote:
Mon Jul 09, 2018 2:39 pm
Hi,
link on github seems broken, could you please write here the code you used?
Thank!
Yes, because M$ acquired github, I've removed my boot loader source. But I've converted everything into a tutorial series, still available on github. The UART0 code is here.

Cheers,
bzt

Return to “Bare metal, Assembly language”