Hi DJ and Michale,
As per your mail, I have checked for 2 to 3 hours continuously, i have
observed 2 things here.
i). some times i have got every 10th byte is over write by
11th byte(10th Byte is not received). and
ii). Most of the cases 114 byte is over write by 115 byte(i.e
114th byte is not received)
in my code, i have taken receiver buffer size is 512 bytes and continuously
i am sending 256 bytes for 100 loops, and i have initialized input and out
put flags correctly. The baud rate is 115200bps. I am thinking to use
different available flags and queue buffer. please inform me if u have any
idea.
Thanks & Regards,
Raju
On Sun, Nov 10, 2013 at 8:02 AM, DJ Regan <regantechservices...@gmail.com>wrote:
> Hi Michael, Question to you - would Raj's stream behave a little more
> chaotic if cpu loading caused the problem?
>
> Hi Raj, When you say every 10th character is over-written - does this
> pattern hold true irrespective of the amount of data streamed? If you sent
> several kilobytes of data - it is only each 10th byte that is clobbered?
> ...what are your frame rate and flow control settings? Here's another
> thought (purely a troubleshooting measure)... what happens when you
> throttle back data throughput to one character per second or less - Does
> the 10th character still get blown away? I haven't looked at the driver
> code - but, it made me curious to see the size of the driver's queue. Is
> the queue size also coincidentally 10 +/-1 characters deep?
>
> Just brain storming with you all. ;-)
>
> Excited to hear what root cause is...
> --DJ
>
>
>
> On Thu, Nov 7, 2013 at 11:00 AM, <uclinux-dev-requ...@uclinux.org> wrote:
>
>> Send uClinux-dev mailing list submissions to
>> uclinux-dev@uclinux.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> or, via email, send a message with subject or body 'help' to
>> uclinux-dev-requ...@uclinux.org
>>
>> You can reach the person managing the list at
>> uclinux-dev-ow...@uclinux.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of uClinux-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: 2.6.38 in Freescale Feb 2012 BSP (Michael Durrant)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 07 Nov 2013 11:36:58 -0500
>> From: Michael Durrant <mdurr...@uclinux.org>
>> To: uclinux-dev@uclinux.org
>> Subject: Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
>> Message-ID: <527bc1aa.7090...@uclinux.org>
>> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>>
>> Raju,
>>
>> I would expect data overruns causing lost characters if your CPU
>> utilization is high and your kernel
>> driver can't get back to servicing the UART IRQ fast enough. Your
>> MCF523x part appears to have
>> only a small FIFO buffer (a shift register and 3 receiver registers).
>> So if the data rate is faster than
>> the kernel can remove the data hardware FIFO it is likely you will miss
>> data due to overruns. So
>> in your case the 10th character was lost (overwritten) by the next
>> character. Sounds like you need
>> DMA support for the UART you are using or perhaps slow down the incoming
>> data or perhaps
>> turn hardware flow control on.
>>
>> Michael
>>
>> On 11/06/2013 04:40 AM, Raju B wrote:
>> > Hi Michael,
>> >
>> > The ColdFire is 523x and using UART serial interface.
>> >
>> > Thanks & regards,
>> > Raju B
>> >
>> >
>> > On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant
>> > <mdurr...@uclinux.org<mailto:
>> mdurr...@uclinux.org>> wrote:
>> >
>> >
>> > Raj,
>> >
>> > Which ColdFire are you using?
>> > Which serial interface are you seeing this with (UART/SPI/I2C/..)?
>> >
>> > Michael
>> >
>> >
>> > On 11/05/2013 07:40 AM, Raju B wrote:
>> >> whenever i am trying to receive data from serial communication
>> continuously in uClinux, I am getting every 10th byte is overwrite by 11
>> byte and so on....
>> >>
>> >> Iam using freescale coldfire processor. Could you any body
>> please help me to resolve this issue.
>> >>
>> >> Thanks & Regards,
>> >> Raj
>> >>
>> >>
>> >> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
>> lsore...@csclub.uwaterloo.ca <mailto:lsore...@csclub.uwaterloo.ca>>
>> wrote:
>> >>
>> >> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
>> >> > I have a 4.7MB application that runs on the 2.6.26 kernel
>> (Freescale BSP) and am working to make it run on the 2.6.38 kernel released
>> in the ColdFire BSP in Feb 2012. I'm concerned about memory allocation as
>> my first attempt to run on the 38 kernel appears to be using 2^n memory
>> allocation vs. allocation that sizes just 1-page over the application.
>> >> >
>> >> > 1) Can anyone tell me the exact kernel config name that
>> needs to be adjusted for the 38 kernel to set the default memory allocation?
>> >> > - Older posts indicate modules like page_alloc2 or
>> Kmalloc2 control this so I'm going to investigate these in more detail
>> >> > - RTFMing indicate that this might be the area but I
>> don't see it in the 38 version (LTIB or make menucionfig):
>> >> > menuconfig -> kernel settings -> general
>> settings, try enabling either the "Permit large allocations" setting, or
>> the "non-power-of-2"
>> >> >
>> >> > 2) Historically, we use LTIB to create the kernel. Does
>> LTIB expose most/all settings of the 2.6.38 kernel? Can it be out of sync
>> with the make menuconfig uClinus kernel?
>> >>
>> >> Maybe this changed the behaviour you see:
>> >>
>> >> commit fc4d5c292b68ef02514d2072dcbf82d090c34875
>> >> Author: David Howells <dhowe...@redhat.com <mailto:
>> dhowe...@redhat.com>>
>> >> Date: Wed May 6 16:03:05 2009 -0700
>> >>
>> >> nommu: make the initial mmap allocation excess behaviour
>> Kconfig configurable
>> >>
>> >> NOMMU mmap() has an option controlled by a sysctl variable
>> that determines
>> >> whether the allocations made by do_mmap_private() should
>> have the excess
>> >> space trimmed off and returned to the allocator. Make the
>> initial setting
>> >> of this variable a Kconfig configuration option.
>> >>
>> >> The reason there can be excess space is that the allocator
>> only allocates
>> >> in power-of-2 size chunks, but mmap()'s can be made in
>> sizes that aren't a
>> >> power of 2.
>> >>
>> >> There are two alternatives:
>> >>
>> >> (1) Keep the excess as dead space. The dead space then
>> remains unused for the
>> >> lifetime of the mapping. Mappings of shared objects
>> such as libc, ld.so
>> >> or busybox's text segment may retain their dead space
>> forever.
>> >>
>> >> (2) Return the excess to the allocator. This means that
>> the dead space is
>> >> limited to less than a page per mapping, but it means
>> that for a transient
>> >> process, there's more chance of fragmentation as the
>> excess space may be
>> >> reused fairly quickly.
>> >>
>> >> During the boot process, a lot of transient processes are
>> created, and
>> >> this can cause a lot of fragmentation as the pagecache and
>> various slabs
>> >> grow greatly during this time.
>> >>
>> >> By turning off the trimming of excess space during boot
>> and disabling
>> >> batching of frees, Coldfire can manage to boot.
>> >>
>> >> A better way of doing things might be to have /sbin/init
>> turn this option
>> >> off. By that point libc, ld.so and init - which are all
>> long-duration
>> >> processes - have all been loaded and trimmed.
>> >>
>> >> Reported-by: Lanttor Guo <lanttor....@freescale.com<mailto:
>> lanttor....@freescale.com>>
>> >> Signed-off-by: David Howells <dhowe...@redhat.com <mailto:
>> dhowe...@redhat.com>>
>> >> Tested-by: Lanttor Guo <lanttor....@freescale.com <mailto:
>> lanttor....@freescale.com>>
>> >> Cc: Greg Ungerer <g...@snapgear.com <mailto:
>> g...@snapgear.com>>
>> >> Signed-off-by: Andrew Morton
>> >> <a...@linux-foundation.org<mailto:
>> a...@linux-foundation.org>>
>> >> Signed-off-by: Linus Torvalds <
>> torva...@linux-foundation.org <mailto:torva...@linux-foundation.org>>
>> >>
>> >> After all before this commit, trimming after allocating was
>> always done.
>> >> Now it is only done if you enable this CONFIG, or set the
>> sysctl flag
>> >> at runtime, which of course affects behaviour for all
>> allocations after
>> >> you change the setting.
>> >>
>> >> --
>> >> Len Sorensen
>> >> _______________________________________________
>> >> uClinux-dev mailing list
>> >> uClinux-dev@uclinux.org <mailto:uClinux-dev@uclinux.org>
>> >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> >> This message was resent by uclinux-dev@uclinux.org <mailto:
>> uclinux-dev@uclinux.org>
>> >> To unsubscribe see:
>> >> http://mailman.uclinux.org/mailman/options/uclinux-dev
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> uClinux-dev mailing list
>> >> uClinux-dev@uclinux.org <mailto:uClinux-dev@uclinux.org>
>> >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> >> This message was resent byuclinux-...@uclinux.org <mailto:
>> uclinux-dev@uclinux.org>
>> >> To unsubscribe see:
>> >> http://mailman.uclinux.org/mailman/options/uclinux-dev
>> >
>> >
>> > _______________________________________________
>> > uClinux-dev mailing list
>> > uClinux-dev@uclinux.org <mailto:uClinux-dev@uclinux.org>
>> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> > This message was resent by uclinux-dev@uclinux.org <mailto:
>> 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
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131107/d649bbcb/attachment-0001.html
>> >
>>
>> ------------------------------
>>
>> _______________________________________________
>> 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
>>
>> End of uClinux-dev Digest, Vol 21, Issue 5
>> ******************************************
>>
>
>
> _______________________________________________
> 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
