- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi there!!.
Set up attached project, capturing rs232 1200baud data and latch each byte to leds.
Project compiles and pass timing constraints wo issue. Simulation testbench also gives correct result. However when connected to max3232 board and send characters by teraterm, specially close followed... data seems corrupted. I use to send a line of 000000 on a file or several 0 by pressing rapidly, that reproduces iisue easier.
Whole design is using 50MHz clock and a clock enable signal which triggers each 1200Hz hz and drives the FSM, the capturer and the synchronizer. (Clock enable usage is suggested to use just one clock domain). system.v connects all submodules.
In design ive routed rx_in_sync output to external pin to check the rs232 data being pass to 2 flops synchronizers synced with clock enable signal.
Ive check that from time to time rx_in_sync edges are missalingned with the rs232 data from max3232 board. If that output is bad, then FSM and counter will get also corrupted data and of course leds sometime will show wrong characters... So issue is already present between clock enable generator and the actual synchronizer as below:
Clock enable signal is sent to 2 flop synchronizer-->clock enable_sync
clock enable_sync is sent to 2 flop synchronizers with clock enable input, this 2 flop sync receives the rs232 RX_IN from outside to give-->rx_in_sync as output.
In yellow is the original 1200baud rs232 byte "30" thats ascii "0".
In blue is the "rx_in_sync output" which sometimes has edges missaligned as u can see below. My scope clearly cannot decode when issue happens:
ok case
bad case, wrong edges
Anyone has come across this situation when synchronize async input data?
Thanks in advance!
BR
- Tags:
- MAX2 DEVICES
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I read the code so that you are sampling 1200 Baud UART input at 1200 Hz only. I'd expect oversampling with e.g. factor 8 as any usual UART does. Or did I miss code details?
There's no use of synchronizing Rx at a reduced rate, this can be done with full clock rate, e.g. 50 MHz.
Decoding of UART data at suitable oversampling rate allows to detect start bit falling edge with necessary accuracy and start to sample data bits after 1/2 bit duration.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I read the code so that you are sampling 1200 Baud UART input at 1200 Hz only. I'd expect oversampling with e.g. factor 8 as any usual UART does. Or did I miss code details?
There's no use of synchronizing Rx at a reduced rate, this can be done with full clock rate, e.g. 50 MHz.
Decoding of UART data at suitable oversampling rate allows to detect start bit falling edge with necessary accuracy and start to sample data bits after 1/2 bit duration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your reply.
Yes. At first i just synced rx data with 50MHz clock itself but found out also sometimes bytes are corrupted.
FSM and Counter works on 1200Hz, otherwise would need to add some counter ie if i use clock enable at 3600 to sample in the middle only for the counter but fsm must work on high frec if i want to capture start bit accurately i guesss..
Weird thing is simulation works fine jejej
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
working simulation doesn't mean much if you don't test different timing relations between clock and data.
Although it can be instructive to design UART from the scratch, it's also a good idea to take a look at one of many existing designs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep im just doing from scratch for the sake of learning. I know there is a known uart scheme already defined online, also there is IP on quartus offering uart itself
Im working on 2x sampling and capture on middle of the bit.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
factor 4 is the minimal oversampling ratio we see in UART design, factor 8 is more commonly used. You play in simulation with relation between sampling clock and RX data and see why factor isn't enough.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi FvM
In this current design attached, state machine is working at 50MHz top speed, its duty is just detect the start bit and enable the baudrate generation just then (i guess this was the key part with problem i had before on data sampling missalignement).
The baudrate generator is 2x sampling, here is set for 115200 top rs232 speed. The counter samples at the middle of the bit after start bit. The more complex and maybe "pain to see" part is the capturer way for waking up DONE signal and put it down again before FSM stops the baudrate generation. Since capturer uses the baudrate generator clock enable signal to work....
Solution was combinational and the pulse last just 1/2 50Mhz period so im quite adjusted on hold time constraint for faster models... even it pass the timing analisys.... Maybe that could be enhaced by enlarge the capturing window on baudrate generator to several 50MHz clocks, that will enlarge clock_enable pulse width and allow.
As said, just learning however let me know if consider FSM sampling 50MHz is good enough.
Tested working fine so far at 115200 speed.
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sampling at double bit rate can surely work if the rate generator is restarted at each start bit. The method has drawbacks, you e.g. can't use a common rate generator for RX and TX. I personally prefer "standard" method with 8 - 16 oversampling factor. A possible modification is to use special factors, e.g. 13 for better baudrate matching.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I understand the drawback u mention, would need another freerun baudrate gen for tx. At the end im just experimenting my own way to learn more.
BTW needed to modify capturer module "if(reset || !GO) begin //always reset to 0 when GO signal goes low" otherwise some rs232 chars end in 1, like ç or ñ cause sample signal missalign and thus loose of frame sync.
At the end i guess is better as u say the known methods, maybe a little more elaborated as i saw on web than this one... Or maybe just i can use the IP rs232 UART library.
Thanks anyway!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page