Timeline for VHDL USB UART Problem
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 12, 2014 at 17:16 | answer | added | hdhzero | timeline score: 1 | |
| Oct 10, 2014 at 16:17 | comment | added | Paebbels | No that's not my guess, but you should also consider low-level debugging. It costs me 1 week of debugging and a additioal day to proof this fauöty behaviour to my colleages :) so be prepared for everything | |
| Oct 10, 2014 at 15:54 | comment | added | hdhzero | @Paebbels So your guess is that the problem is really the cable? | |
| Oct 10, 2014 at 15:51 | comment | added | Paebbels | Uh this is bad. I never got this CH340 running. Driver issues/couldn't active COM port. I switched to CP2103 which supports up to 921 kbit/s | |
| Oct 10, 2014 at 15:45 | comment | added | hdhzero | @Paebbels I'm not sure what the chipset is (I've found the cable in the laboratory). It doesn't has any info in the cable (chipset, etc). When I plug on linux and run lsusb, I got a CH340 chipset (this cable: ayagroup.com/product.php?productid=19576) | |
| Oct 10, 2014 at 15:36 | comment | added | Paebbels | Which USB-UART chip do you use (e.g. FDDI, CP2103, ...) I experienced a faulty CP2103 on a VC707 board which has a baud rate deviation of over 15%, so the last one or two bits come in wrong. One way to check your UART is a simple chipscope core (64k cycles deep, 2 bits (rx,tx), data=trigger, sampled on falling edge). So you can see what is going on on the wire and you can measure the bit times in cycles. If you don't have enough BRAM, you can use a 10 MHz clock from a free DCM/PLL port to drive chipscope or you use your tick-signal as a storage-qualifier in chipscope (advanced technique :) ) | |
| Oct 10, 2014 at 15:32 | comment | added | hdhzero | I really dont know what the problem is... I've already tested the design on linux and windows. I've also tried three or four implementations I've found in the internet. Today, I am going to buy a new usb-rs232 cable and see if the problem persists. Also, I will try to test on another FPGA. But for the moment, I have no clue of what is the problem | |
| Oct 10, 2014 at 15:19 | comment | added | hdhzero | @Qiu In rx, I wait for the first '0' level, then I switch to the data_bits states. I use 16 ticks to sample data, so the middle of the bit is between seven~eight. I simple take advantage of the fact that the counter will overflow automatically. So when it reaches 7, then I set it to 8 (or I could just let it increment). When I set to 8, the counter goes: 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7, which is just the middle of the following incoming bit | |
| Oct 10, 2014 at 14:53 | comment | added | Qiu | @hdzero: why do you count 16 ticks in your tx module and 8 in rx? | |
| Oct 10, 2014 at 3:08 | comment | added | hdhzero | All the modules can be found at github.com/hdhzero/hivek-io-modules/tree/master/uart/src. top_uart_controller is the top level where I make the pin assignemnts. Uart_controller.vhd basically create instances of the tx, rx and mod counter | |
| Oct 10, 2014 at 3:06 | comment | added | hdhzero | The system clock is 50MHz. The clock feeds a mod counter that generates an enable tick for the transmitter and receiver modules | |
| Oct 10, 2014 at 2:58 | comment | added | Zuofu | What clock are you giving the module? What does your surrounding top-level look like? | |
| Oct 10, 2014 at 2:52 | history | edited | hdhzero | CC BY-SA 3.0 | related link |
| Oct 10, 2014 at 2:44 | history | asked | hdhzero | CC BY-SA 3.0 |