 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : RS232 stop bit problem.
| Author | Message | ||||
MustardMan Senior Member  Joined: 30/08/2019 Location: AustraliaPosts: 175 |
Hi, When sending out a contiguous stream of data from an Explore 100, on a random basis my terminal emulator looses the plot and starts spewing random trash. The on-screen LCD display continues just fine. This happens with both TeraTerm & the MMedit terminal, and on two different computers, pointing (non-conclusively) towards the MicroBridge (a PIC16F1455). On occasion the data stream is corrupted so badly it somehow crashes the USB/RS232 driver in windows and requires the cable be unplugged and replugged. The data coming out of the E100 is formatted 1 start bit, 8 data bits and 1 stop bit (the MMbasic default) with no inter-character delay. My current theory is that because all the bit times in the data stream are equal, the MicroBridge looses sync at some stage, starts interpreting the wrong bits, converting them to USB and dutifully sending them over the emulated serial port. I have attached a bus sniffer analysis. 38400 baud. Yellow trace : Data coming out of the E100 (Tx) Blue trace : Data going into the E100 (Rx) 0009 shows a test sequence AA 55 00 FF sent continually 0010 shows a zoom of 55, showing the start & stop bit being equal and no inter-character delay When sending data to the E100 there is an inter-character delay (0012 & 0013) I assume the PIC32 hardware on the E100 is used to send data and the buffer is simply filled and then the UART told "go to it". I was wondering if it were possible to change the default to either 1.5 or 2 stop bits? However, that might break compatibility for incoming data, so even trickier, is it possible to specify 1.5 or 2 stop bits for Tx (out of the PIC32) and retain 1 stop bit for incoming? I have had the exact same problem occur with 19200 & 9600 baud. I have not tried higher or lower though. Cheers,     |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Some questions are complicated!!  Firstly all serial ports on the MM+ can be opened with the S2 option which will set two stop bits. However, I suspect that you are using the serial console as your serial port. In that case you have two options: - Disable the serial console and then open COM4 with the S2 option. - Try this command: POKE BYTE &HBF806008, 1 The latter will directly force the hardware UART for the serial console into two stop bits mode. I have not tested this so it could crash the processor and cause a reboot  All these will set two stop bits for both transmit and receive, you cannot set them separately. Another option would be to write a subroutine that sent your data byte by byte with a PAUSE 0.04 command after each byte is sent. That will wait for the byte to clear the UART and add an additional 14us delay to make sure the receiver is not confused. Finally, I suspect that setting two stop bits will not fix your problem. The MM+ uses a crystal and so the baud rate is very accurate. The MicroBridge gets its timing from the USB signal from your host which will be crystal locked so it will also be very accurate. Indeed, with all my testing I have never seen the issue that you have described. Geoff Edited 2020-09-09 00:40 by Geoffg Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
hi, i've seen this sort of behaviour before using a contrived mmbasic program designed to max out the console output for testing purposes - every now and then things would jump out of sync by one or more bits. essentially, rs232 and UARTs were never designed with continuous bulk transmission without any breaks in mind. there are a couple of solutions: 1. use a baud rate high enough that the rate of transmission naturally allows for a short gap between characters so that the clock of the receiving UART has time to resynchronize to the leading edge of the start bit, or, 2. break your data up into blocks of (for example) 128 characters, after which you wait for an acknowledgement message from other end. the acknowledgement could be as complicated as a checksum calculated on the just sent block of data, or as simple as a single fixed ACK character. depending on your setup, you could also consider using the pic32's on-chip USB port if the E100 still supports this. i've been playing around with atmel 32u4 processors recently that have an onboard USB port that establishes a CDC serial emulation back to the host, and over this have been able to send data at high speed, continuously, no handshaking, and without error. in theory communication up to 1 million bytes per second is possible over USB CDC. cheers, rob :-) |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
Hi Geoff, Thanks for the tip on the POKE - I'll try that later this-evening. I agree that with everything running to quite a respectable precision with crystal clocks & such there should not be a problem. I am very surprised I saw it pop up at all, and that spurred me on to write that test snippet (DO : PRINT ... : LOOP) to try and see what was happening. I could be all wrong about the stop bit causing the problem but that is my best theory so far... I have no doubt you know all about hard-to-solve bugs! And thanks for the suggestions Rob. This is one bug particular that I didn't expect, but that's how we learn. If everything worked first time there would be no lessons, and life would perhaps be easier but a lot more boring... "How does that work?", "Oh, I don't know, I just put all the parts together and turned the power on". Cheers, |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
MMEdit will never be able to keep up with continuous data streams. TeraTerm has a much better chance. Jim VK7JH MMedit |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
Hi Jim, True. I first noticed the problem with MMedit when it was doing an Xmodem, and thats when I started to look further. TeraTerm does keep up (until the USB port/driver crashes). I tried Geoffs suggestion, ie: the POKE, and the E100 does not crash. I can tell immediately it does 2 stop bits (scope grabs before & after the poke) without even having to output AA or 55. The POKE survives through a NEW, but (as expected) does not survive a reset. I will report back with an update after operating it for a few days. Cheers, Unfortunately the TX/Rx channels/colours got swapped when I reconnected the scope. Oh well. Before POKEing...  After POKEing...  |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
As promised, a report back... Unfortunately, after several days I have not been able to reproduce the problem. Same development PC (no new software installed), same Explore 100 (ie: the 2-stop-bit POKE not executed), same USB cable. The only thing I've done is move it (several times) between my software development bench and my hardware development bench, and each time taking full ESD precautions. I am at a complete loss as to why. It was misbehaving for two straight days before Geoff suggested the POKE to flip it to 2-stop-bits, and since then, even when it goes back to 1-stop-bit, it works fine. Grrr. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
I have on occasion had weird stuff like this. prolly a bit late now, but if this nonsensical thing happens again, try re-flashing the PIC. Glad it's sorted Edited 2020-09-18 01:14 by CaptainBoing |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
A further update... This-morning the problem re-appeared: MMedit would continually fail when trying to XMODEM a .bas file up to the Explore 100. I got a screenshot that essentially shows that the MMedit/E100 communication had screwed up even before the 'print mm.ver' got through. I have however seen considerably more interesting variants than my screengrab where it would mess up the 'XMODEM RECEIVE' command, turning it into something like 'XMODEM REXMODEM' (sorry, I didn't take careful note, and I didn't get a screengrab). This morning I was able to show the problem to a colleague, and after much discussion we thought it might/could have been either the Windows 10 USB/serial port driver, or MMedit itself, and nothing to do with the Explore 100 hardware. Multiple exits and restarts of MMedit did not make any difference, and in the majority of cases the USB to the Explore 100 had to be unplugged and replugged to get it talking again, and that would restart the USB/serial driver (according to Control Panel). In frustration I finally shutdown & restarted my PC (not just a restart, but full power off cycle), and now it works just fine! Probably not the Explore 100 then!! Crikey - the time wasted! Current install : MMedit v4.0.0 I am unsure whether to upgrade to the latest MMedit and hope it is all behind me, or continue with the older version in case it happens again and I can get more data... the problem may be completely absent in the newer version, or it may still be buried somewhere in the code...  |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Because you appear to be having problems with the USB side failing, I would start with a new USB cable. Updating MMEdit will not help. I have not made any changes in the serial routines. Your connecting failed at the second step. It correctly replied to PRINT MM.DEVICE$ but didn't even manage to echo the next command PRINT MM.VER but did manage to give a prompt. I don't know of any problems with the Microbridge and W10. I use them here and there are plenty out there. You could try uploading your program from 'LOAD' in the chat window instead of using XMODEM. That is my usual method now-a-days. When the USB port fails, you will have to close MMEdit, remove and reinsert the USB, then restart MMEDit. (Most of the time, closing the Chat window is sufficient rather than a full shutdown). TeraTerm is better at recovering but you may have to do something similar with TeraTerm. Another way of uploading that uses a splightly differnt sequence and gives you the option of crunching, is MMUploader. With the correct comment line at the start of your program, it's a simple drag and drop. Jim VK7JH MMedit |
||||
| MustardMan Senior Member Joined: 30/08/2019 Location: AustraliaPosts: 175 |
Thanks for those suggestions Jim. It's funny, I've used the same cable and same machine for *months*, and this problem has really only shown up twice. The first time it seemed to go away by itself, which I now realise was most likely me turning the PC off one night and on the next day. Most of the time it just stays running the whole time. I had not even thought to use LOAD. I had previously looked through your page on MM programs and the description of MMuploader didn't grab my attention. After your comments above, I went back and read the .pdf about MMuploader and I must say I am impressed with what it can do. Far more powerful than the webpage suggests! I am most certainly going to be installing it! Cheers, |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
