Hi Fabio and all,i work on linux, with gtkterm, even without usb adaptor, i still had 1 time only a blank line, but no data missing anymore.
I don't like minicom, now i am testing putty, seems the best serial terminal in linux now, with many configurable options, and still didn't found any issue.
What i think is that, using high speeds (>=75600), when the baud error is > 1% (like in my case), some bad charachter can be received from the PC terminal, and this cause someway the hang situation.
Let's see what happen, thanks to all for now regards, Angelo On 09/06/2010 13:57, Fabio Giovagnini wrote:
It is possible. Are you running the PC remote terminal program in windows or linux? Are you using minicom (linux) or Hyperterminal (win)? In my experience the USB to serial convs work properly under linux but not exactly properly all the kinds under windows Cheers In data mercoledì 09 giugno 2010 12:49:46, angelo ha scritto: :> Hi Alessandro and all,i did some other tests: 1) from a test program loaded in internal SRAM through BDM, problem seems happening also, even if less frequently. 2) since mine is a custom-prototype board i developed, i unsoldered and resoldered completely MAX 3232 and capacitors, to check for shorts or bad soldered pins. Nothing changed. 3) kernel speed down to 57600, same issue. 4) kernel speed down to 19200, issue disappeared, but i get sometime some blank line in the output (double crlf ?) here and there, but no data is lost anymore. # ls -al drwxr-xr-x 1 0 0 32 Jan 1 1970 . drwxr-xr-x 1 0 0 32 Jan 1 1970 .. drwxr-xr-x 1 0 0 32 Jan 1 1970 bin drwxr-xr-x 1 0 0 32 Jan 1 1970 dev drwxr-xr-x 1 0 0 32 Jan 1 1970 etc drwxr-xr-x 1 0 0 32 Jan 1 1970 home drwxr-xr-x 1 0 0 32 Jan 1 1970 lib drwxr-xr-x 1 0 0 32 Jan 1 1970 mnt dr-xr-xr-x 26 0 0 0 Nov 30 00:00 proc lrwxrwxrwx 1 0 0 8 Jan 1 1970 tmp -> /var/tmp drwxr-xr-x 1 0 0 32 Jan 1 1970 usr drwxr-xr-x 6 0 0 1024 Nov 30 00:00 var # 5) in the portable pc i am using USB to serial converter. Tested connected to a real pc serial port, at 19200. Don't see anymore blank lines. 6) Back to 115200, real PC com port, works. So seems the usb-to-serial adapter is causing the issue. And the remainder sent later probably is kept inside the adaptor memory for some time. Any comments is welcome. Regards, Angelo On 09/06/2010 09:32, Alessandro Guerra wrote:Hi, I'm experiencing exactly the same issue on a Coldfire 5329. It seems to be a random problem... Till now, I haven't found any cause-effect relation between the actions taken on the microcontroller. I noticed that sometimes when I disconnect and reconnect the terminal emulator on the pc, the receiving process restarts regularly. In my opinion it is a pc related problem... Regards, Alessandro angelo ha scritto:thanks all for the replies, no Xon Xoff is enabled in the terminal, i tested also other PC terminals, same issue. Problem seems to happen for some hours/days, and then disappear, to come back again. MAX3232 circuit seems working properly, and in any case, it don't have any memory inside. Don't seems also that unused HW interrupts are the cause, i pulled them up. The fact that when i press a key, the rest of the message is received, make me think that the device is in some "paused" state, and send the reminder when i unlock it pressing a key. At boot, big parts of "mesg" are not sent out, and sometime i don't even get those parts later, but just the promt (#), like below. Linux version 2.6.29-uc0001 (ang...@angel7) (gcc version 4.2.4) #204 Tue Jun 8 21:35:13 CEST 2010 uClinux/COLDFIRE(m5307) COLDFIRE port done by Greg Ungerer, g...@snapgear.com Modified for M5307 by Dave Miller, dmil...@intellistor.com Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 Kernel command line: PID hash table entries: 64 (order: 6, 256 bytes) Dentry cache hash table entrieb] # 115200 should be still a quite safe serial speed, measured the bit width through scope, it is 8.8usec, (113.636 baud) the cable is hand-made. but in any case, as i said, often most of the missing parts are sent to the PC later, when i press a key, so this don't seems to be cable related. I am still investigating. thanks Regards, Angelo On 08/06/2010 22:57, Lennart Sorensen wrote:On Tue, Jun 08, 2010 at 10:35:18PM +0200, angelo wrote:i have a strange issue on the console serial port. On a coldfire 5307, uClinux kernel 2.6.X, using the console serial port at 115200,N,8,1, bus_clock 45Mhz, sometime a block of bytes (even some hundreds) seems lost and not received from the PC-side terminal. But when i press a key, the missing block is then received. Example: # ls bin dev etc (nothing more is received, so i press<enter>) # ls bin dev etc home lib mnt proc tmp usr var # (after enter missing part arrive). Could this issue be related to some kernel misconfiguration ? Or most probably another HW issue ?115200 is really pushing it unless you have a high quality cable and good buffering on both ends of the link (which the console port probably doesn't have). Use 57600 if you want reliable console is my experience. Now the other possibility is that you have an IRQ mistake, in which case you hitting a key generates an IRQ that then causes it to start transmitting again. Maybe your IRQ line isn't hooked up properly or not configured right.------------------------------------------------------------------------ _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
