Got Questions? Get Answers.
Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Failure to read serial port after ~5000 asynch reads

Subject: Failure to read serial port after ~5000 asynch reads

From: Scott Burnside

Date: 30 Sep, 2008 23:04:02

Message: 1 of 8

Running R2007a on WinXP with Instrument Control Toolbox 2.4.2 I am encountering serial port read failures after approx. 5000 read operations connected to a TrueTime XL-DC GPS Time and Frequency Reciever.

I've used continuous asynchronous, manual asynchronous (with readasync). I've tried flow control. All methods manifest the same problem, there is no output after about 5000 reads. It looks like Matlab's interface to the UART driver is locking up. Serialbreak doesn't work.

Nothing short of closing MATLAB and starting a new instance will clear this up.

Is this a known problem with 2007a? I find hints of this in the support literature but I would like to be more certain before I spend the money to upgrade.

Thanks,
Scott

Subject: Failure to read serial port after ~5000 asynch reads

From: Trent Jarvi

Date: 1 Oct, 2008 22:25:28

Message: 2 of 8


"Scott Burnside" <no@spam.com> wrote in message
news:gbub92$9sr$1@fred.mathworks.com...
> Running R2007a on WinXP with Instrument Control Toolbox 2.4.2 I am
> encountering serial port read failures after approx. 5000 read operations
> connected to a TrueTime XL-DC GPS Time and Frequency Reciever.
>
> I've used continuous asynchronous, manual asynchronous (with readasync).
> I've tried flow control. All methods manifest the same problem, there is
> no output after about 5000 reads. It looks like Matlab's interface to the
> UART driver is locking up. Serialbreak doesn't work.
>
> Nothing short of closing MATLAB and starting a new instance will clear
> this up.
>
> Is this a known problem with 2007a? I find hints of this in the support
> literature but I would like to be more certain before I spend the money to
> upgrade.
>

Hi Scott

AFIAK, this is not a known problem in 2007a. It may be a manifestation of
something else. Do you have minimal example code that can reproduced the
problem?

Subject: Failure to read serial port after ~5000 asynch reads

From: Scott Burnside

Date: 2 Oct, 2008 00:22:01

Message: 3 of 8

"Trent Jarvi" <tjarvi@mathworks.com> wrote in message <gc0tco$6v3$1@fred.mathworks.com>...
>
> "Scott Burnside" <no@spam.com> wrote in message
> news:gbub92$9sr$1@fred.mathworks.com...
> > Running R2007a on WinXP with Instrument Control Toolbox 2.4.2 I am
> > encountering serial port read failures after approx. 5000 read operations
> > connected to a TrueTime XL-DC GPS Time and Frequency Reciever.
> >
> > I've used continuous asynchronous, manual asynchronous (with readasync).
> > I've tried flow control. All methods manifest the same problem, there is
> > no output after about 5000 reads. It looks like Matlab's interface to the
> > UART driver is locking up. Serialbreak doesn't work.
> >
> > Nothing short of closing MATLAB and starting a new instance will clear
> > this up.
> >
> > Is this a known problem with 2007a? I find hints of this in the support
> > literature but I would like to be more certain before I spend the money to
> > upgrade.
> >
>
> Hi Scott
>
> AFIAK, this is not a known problem in 2007a. It may be a manifestation of
> something else. Do you have minimal example code that can reproduced the
> problem?
>

Trent thanks for replying. I've gotten a trial version of 2008a and am testing with that overnight. Right away it started out by droping every other read operation so its clear I had to much going on in the loop between reads and the 2007a serial interface was trying to cope unsucsessfully. The 2008a serial interface seems more robust but I won't know for sure until I see this run overnight.

If I continue to have problems I will post some representative code. Thanks again for your help.

Scott

Subject: Failure to read serial port after ~5000 asynch reads

From: Scott Burnside

Date: 2 Oct, 2008 20:15:04

Message: 4 of 8

"Scott Burnside" <no@spam.com> wrote in message <gc1479$or1$1@fred.mathworks.com>...
> "Trent Jarvi" <tjarvi?hox.?%wrote in message <gc0tco$6v3$1@fred.mathworks.com>...
> >
> > "Scott Burnside" <no@spam.com> wrote in message
> > news:gbub92$9sr$1@fred.mathworks.com...
> > > Running R2007a on WinXP with Instrument Control Toolbox 2.4.2 I am
> > > encountering serial port read failures after approx. 5000 read operations
> > > connected to a TrueTime XL-DC GPS Time and Frequency Reciever.
> > >
> > > I've used continuous asynchronous, manual asynchronous (with readasync).
> > > I've tried flow control. All methods manifest the same problem, there is
> > > no output after about 5000 reads. It looks like Matlab's interface to the
> > > UART driver is locking up. Serialbreak doesn't work.
> > >
> > > Nothing short of closing MATLAB and starting a new instance will clear
> > > this up.
> > >
> > > Is this a known problem with 2007a? I find hints of this in the support
> > > literature but I would like to be more certain before I spend the money to
> > > upgrade.
> > >
> >
> > Hi Scott
> >
> > AFIAK, this is not a known problem in 2007a. It may be a manifestation of
> > something else. Do you have minimal example code that can reproduced the
> > problem?
> >
>
> Trent thanks for replying. I've gotten a trial version of 2008a and am testing with that overnight. Right away it started out by droping every other read operation so its clear I had to much going on in the loop between reads and the 2007a serial interface was trying to cope unsucsessfully. The 2008a serial interface seems more robust but I won't know for sure until I see this run overnight.
>
> If I continue to have problems I will post some representative code. Thanks again for your help.
>
> Scott

Ok this is worked for about 10-hours total now using R2008a. The thing is that I'm not sure if it 2008a that fixed that problem or the fact that I trimmed alot of the bloated code in the read loop. I guess I should go back and test against R2007a again just to be sure. I'll post back with that result.

The program reads Agilent N9020a Spectrum Analyzer marker peak search frequency and amplitutde at 10 samples-per-second over Ethernet. The data are time tagged with UTC 1-pulse-per-second time stamps taken over the serial port from a TruTime XL-DC GPS/Rubidium Time Standard. The intersecond tics are derived from the internal high resolution counter. I'm using a mex file for that (hat.mexw32 from the FEX). The resulting timestamps are accurate to within 2 ms of absolute UTC time. I'll likely post this code to the FEX after some refinement and much more testing.

Scott

Subject: Failure to read serial port after ~5000 asynch reads

From: Trent Jarvi

Date: 3 Oct, 2008 17:47:22

Message: 5 of 8


"Scott Burnside" <no@spam.com> wrote in message
news:gc3a48$bjs$1@fred.mathworks.com...
> "Scott Burnside" <no@spam.com> wrote in message
> <gc1479$or1$1@fred.mathworks.com>...
>> "Trent Jarvi" <tjarvi?hox.?%wrote in message
>> <gc0tco$6v3$1@fred.mathworks.com>...
>> >
>> > "Scott Burnside" <no@spam.com> wrote in message
>> > news:gbub92$9sr$1@fred.mathworks.com...
>> > > Running R2007a on WinXP with Instrument Control Toolbox 2.4.2 I am
>> > > encountering serial port read failures after approx. 5000 read
>> > > operations
>> > > connected to a TrueTime XL-DC GPS Time and Frequency Reciever.
>> > >
>> > > I've used continuous asynchronous, manual asynchronous (with
>> > > readasync).
>> > > I've tried flow control. All methods manifest the same problem, there
>> > > is
>> > > no output after about 5000 reads. It looks like Matlab's interface to
>> > > the
>> > > UART driver is locking up. Serialbreak doesn't work.
>> > >
>> > > Nothing short of closing MATLAB and starting a new instance will
>> > > clear
>> > > this up.
>> > >
>> > > Is this a known problem with 2007a? I find hints of this in the
>> > > support
>> > > literature but I would like to be more certain before I spend the
>> > > money to
>> > > upgrade.
>> > >
>> >
>> > Hi Scott
>> >
>> > AFIAK, this is not a known problem in 2007a. It may be a manifestation
>> > of
>> > something else. Do you have minimal example code that can reproduced
>> > the
>> > problem?
>> >
>>
>> Trent thanks for replying. I've gotten a trial version of 2008a and am
>> testing with that overnight. Right away it started out by droping every
>> other read operation so its clear I had to much going on in the loop
>> between reads and the 2007a serial interface was trying to cope
>> unsucsessfully. The 2008a serial interface seems more robust but I won't
>> know for sure until I see this run overnight.
>>
>> If I continue to have problems I will post some representative code.
>> Thanks again for your help.
>>
>> Scott
>
> Ok this is worked for about 10-hours total now using R2008a. The thing is
> that I'm not sure if it 2008a that fixed that problem or the fact that I
> trimmed alot of the bloated code in the read loop. I guess I should go
> back and test against R2007a again just to be sure. I'll post back with
> that result.
>
> The program reads Agilent N9020a Spectrum Analyzer marker peak search
> frequency and amplitutde at 10 samples-per-second over Ethernet. The data
> are time tagged with UTC 1-pulse-per-second time stamps taken over the
> serial port from a TruTime XL-DC GPS/Rubidium Time Standard. The
> intersecond tics are derived from the internal high resolution counter.
> I'm using a mex file for that (hat.mexw32 from the FEX). The resulting
> timestamps are accurate to within 2 ms of absolute UTC time. I'll likely
> post this code to the FEX after some refinement and much more testing.
>

Hi Scott,

It may be changes we put in for the GPIB and VISA and or TCPIP interfaces
that also improved Serial. I didn't find a bug report for your exact
problem.

Neat application. I'd be interested in seeing it when you are ready.
Perhaps the upcomming LXI class B compliant machines (including Agilent SAs)
would be useful in this application.

Subject: Failure to read serial port after ~5000 asynch reads

From: David Atkinson

Date: 2 Dec, 2008 23:20:18

Message: 6 of 8

Scott,

I have experienced the same serial port problem. I have a DSP board taking to the PC using Matlab serial port. My m-file contains a repeating while loop which includes a pause(0.1) to set repetition rate. After starting it appears to run perfectly for a few thousand loops then fails. The number of loops before failure is variable. As you found, the only way to fix is to restart Matlab. I was originally using R2007b but found it does exactly the same with R2008b. One observation in my case was that if I only transmit data from PC to the DSP board then it doesn't fail. So the problem appears to be associated with data coming into Matlab.

Dave


"Trent Jarvi" <tjarvi@mathworks.com> wrote in message <gc5lra$2en$1@fred.mathworks.com>...
>
> "Scott Burnside" <no@spam.com> wrote in message
> news:gc3a48$bjs$1@fred.mathworks.com...
> > "Scott Burnside" <no@spam.com> wrote in message
> > <gc1479$or1$1@fred.mathworks.com>...
> >> "Trent Jarvi" <tjarvi?hox.?%wrote in message
> >> <gc0tco$6v3$1@fred.mathworks.com>...
> >> >
> >> > "Scott Burnside" <no@spam.com> wrote in message
> >> > news:gbub92$9sr$1@fred.mathworks.com...
> >> > > Running R2007a on WinXP with Instrument Control Toolbox 2.4.2 I am
> >> > > encountering serial port read failures after approx. 5000 read
> >> > > operations
> >> > > connected to a TrueTime XL-DC GPS Time and Frequency Reciever.
> >> > >
> >> > > I've used continuous asynchronous, manual asynchronous (with
> >> > > readasync).
> >> > > I've tried flow control. All methods manifest the same problem, there
> >> > > is
> >> > > no output after about 5000 reads. It looks like Matlab's interface to
> >> > > the
> >> > > UART driver is locking up. Serialbreak doesn't work.
> >> > >
> >> > > Nothing short of closing MATLAB and starting a new instance will
> >> > > clear
> >> > > this up.
> >> > >
> >> > > Is this a known problem with 2007a? I find hints of this in the
> >> > > support
> >> > > literature but I would like to be more certain before I spend the
> >> > > money to
> >> > > upgrade.
> >> > >
> >> >
> >> > Hi Scott
> >> >
> >> > AFIAK, this is not a known problem in 2007a. It may be a manifestation
> >> > of
> >> > something else. Do you have minimal example code that can reproduced
> >> > the
> >> > problem?
> >> >
> >>
> >> Trent thanks for replying. I've gotten a trial version of 2008a and am
> >> testing with that overnight. Right away it started out by droping every
> >> other read operation so its clear I had to much going on in the loop
> >> between reads and the 2007a serial interface was trying to cope
> >> unsucsessfully. The 2008a serial interface seems more robust but I won't
> >> know for sure until I see this run overnight.
> >>
> >> If I continue to have problems I will post some representative code.
> >> Thanks again for your help.
> >>
> >> Scott
> >
> > Ok this is worked for about 10-hours total now using R2008a. The thing is
> > that I'm not sure if it 2008a that fixed that problem or the fact that I
> > trimmed alot of the bloated code in the read loop. I guess I should go
> > back and test against R2007a again just to be sure. I'll post back with
> > that result.
> >
> > The program reads Agilent N9020a Spectrum Analyzer marker peak search
> > frequency and amplitutde at 10 samples-per-second over Ethernet. The data
> > are time tagged with UTC 1-pulse-per-second time stamps taken over the
> > serial port from a TruTime XL-DC GPS/Rubidium Time Standard. The
> > intersecond tics are derived from the internal high resolution counter.
> > I'm using a mex file for that (hat.mexw32 from the FEX). The resulting
> > timestamps are accurate to within 2 ms of absolute UTC time. I'll likely
> > post this code to the FEX after some refinement and much more testing.
> >
>
> Hi Scott,
>
> It may be changes we put in for the GPIB and VISA and or TCPIP interfaces
> that also improved Serial. I didn't find a bug report for your exact
> problem.
>
> Neat application. I'd be interested in seeing it when you are ready.
> Perhaps the upcomming LXI class B compliant machines (including Agilent SAs)
> would be useful in this application.
>

Subject: Failure to read serial port after ~5000 asynch reads

From: Geoff

Date: 2 Mar, 2009 17:23:01

Message: 7 of 8

Dave (and Scott) -- I'm suffering a similar behavior where Matlab 2008a fails to read several serial ports after 5000 to 7000 reads of the serial port. As you've reported, the only way to get the ports to start reading again is exit Matlab.

In my case I'm using a timer object, but I've experienced the same problems putting the read/write commands to the serial port in a for loop as well.

If you've found any work arounds or found certain tricks with your own code, I'd be appreciative of any insights.

Thanks,

Geoff

"David Atkinson" <djatkinson54@yahoo.co.uk> wrote in message <gh4fri$6vm$1@fred.mathworks.com>...
> Scott,
>
> I have experienced the same serial port problem. I have a DSP board taking to the PC using Matlab serial port. My m-file contains a repeating while loop which includes a pause(0.1) to set repetition rate. After starting it appears to run perfectly for a few thousand loops then fails. The number of loops before failure is variable. As you found, the only way to fix is to restart Matlab. I was originally using R2007b but found it does exactly the same with R2008b. One observation in my case was that if I only transmit data from PC to the DSP board then it doesn't fail. So the problem appears to be associated with data coming into Matlab.
>
> Dave
>

Subject: Failure to read serial port after ~5000 asynch reads

From: Marco Balsi

Date: 15 Apr, 2009 09:16:01

Message: 8 of 8

I also have this problem. In my case I am receiving small packets (15bytes) from a TI microcontroller (MPS430) card interfacing a ZigBee CC2480 trasmitter/receiver. It is connected to a COM port through the USB connector. Reading is done in a for loop. Everything works OK down to a repetition period of 250ms. At that frequency it goes on receiving correctly forever. At higher frequency (lower period) the problem appears in the same way as reported in this thread. This sensitivity to frequency makes me think of some kind of buffer saturation...
By the way, I also tried the same communication through hyperterminal, and in that case it does work correctly down to 100ms, so apparently it is not a problem with something external to Matlab (at least up to some point).
Marco

"Geoff " <reynolds-dot-gw-dot-2@pg.com> wrote in message <goh4ll$fi3$1@fred.mathworks.com>...
> Dave (and Scott) -- I'm suffering a similar behavior where Matlab 2008a fails to read several serial ports after 5000 to 7000 reads of the serial port. As you've reported, the only way to get the ports to start reading again is exit Matlab.
>
> In my case I'm using a timer object, but I've experienced the same problems putting the read/write commands to the serial port in a for loop as well.
>
> If you've found any work arounds or found certain tricks with your own code, I'd be appreciative of any insights.
>
> Thanks,
>
> Geoff
>
> "David Atkinson" <djatkinson54@yahoo.co.uk> wrote in message <gh4fri$6vm$1@fred.mathworks.com>...
> > Scott,
> >
> > I have experienced the same serial port problem. I have a DSP board taking to the PC using Matlab serial port. My m-file contains a repeating while loop which includes a pause(0.1) to set repetition rate. After starting it appears to run perfectly for a few thousand loops then fails. The number of loops before failure is variable. As you found, the only way to fix is to restart Matlab. I was originally using R2007b but found it does exactly the same with R2008b. One observation in my case was that if I only transmit data from PC to the DSP board then it doesn't fail. So the problem appears to be associated with data coming into Matlab.
> >
> > Dave
> >

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us