[prev in list] [next in list] [prev in thread] [next in thread]
List: uclinux-dev
Subject: Re: [uClinux-dev] coldfire, console serial port issue
From: angelo <angelo70 () gmail ! com>
Date: 2010-06-09 14:22:08
Message-ID: 4C0FA390.6030702 () gmail ! com
[Download RAW message or body]
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 (angelo@angel7) (gcc version 4.2.4) #204
>>>> Tue Jun 8 21:35:13 CEST 2010
>>>>
>>>> uClinux/COLDFIRE(m5307)
>>>> COLDFIRE port done by Greg Ungerer, gerg@snapgear.com
>>>> Modified for M5307 by Dave Miller, dmiller@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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic