Windows ME?
Archiver
Posts: 46,084
I took my new Windows ME notebook with me today to a remote site. The
target stamp was a Stamp2 and the IDE was stampw.exe v1.1.
Being a suspicious sort about the possible influence of NT policies
on ME I tested this setup before I left for the site. My little test
program ran fine and displayed its Debug statements correctly.
But when I went to download the real application at the site the stamp
would just lock up. I inserted a debug statement at the beginning of
the program to see if the application was running at all and was
surprised to find the program then ran just fine. I took out the debug
statement and the app stalled again. After some experimentation I
discovered it did not make any difference where I put the debug
statement; everything would run just fine even if the statement was
inserted past the end of the program! Finally I found that if I
disconnected the RS-232 cable from the Stamp while it was hung after a
no-debug-statement download the stamp would subsequently boot the
program and run just fine.
I believe the download process was hanging the serial port somehow and
the cable removal or a debug process was clearing this fault. Since
the debug statement didn't have to even be in the code path I also
think that the debug dialog box may have been the key to clearing the
fault (it appears whether or not any debug statements actually
execute).
Does anybody have a clue on this "feature" ?
target stamp was a Stamp2 and the IDE was stampw.exe v1.1.
Being a suspicious sort about the possible influence of NT policies
on ME I tested this setup before I left for the site. My little test
program ran fine and displayed its Debug statements correctly.
But when I went to download the real application at the site the stamp
would just lock up. I inserted a debug statement at the beginning of
the program to see if the application was running at all and was
surprised to find the program then ran just fine. I took out the debug
statement and the app stalled again. After some experimentation I
discovered it did not make any difference where I put the debug
statement; everything would run just fine even if the statement was
inserted past the end of the program! Finally I found that if I
disconnected the RS-232 cable from the Stamp while it was hung after a
no-debug-statement download the stamp would subsequently boot the
program and run just fine.
I believe the download process was hanging the serial port somehow and
the cable removal or a debug process was clearing this fault. Since
the debug statement didn't have to even be in the code path I also
think that the debug dialog box may have been the key to clearing the
fault (it appears whether or not any debug statements actually
execute).
Does anybody have a clue on this "feature" ?
Comments
and when the serial cable is connected to the PC, but the Stamp
compiler/monitor application is not running, the Stamp will simply freeze.
If the RS-232 cable is disconnected, then all is OK. I wonder if the PCs
serial port's ATN line remains in the 'reset' state (be it high or low) when
the port is closed, or no application is accessing it, but I can confirm
that it somehow affects the Stamp.
We went to preform a demo for a costumer, and the Stamp & related circuit
refused to work, it was a disaster. Later back at the lab we concluded
(after a lot of testing & trying different configurations) that the
programming cable must be disconnected, after downloading the final app, for
the Stamp to work.
I hope this helps,
Mike
>
Mensaje original
> De: fdavidson@m... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=aoIpBVlsiBZ1xqixiTQg8LRdWNnPO90q_jRLCpXGxtKowPZIUAllqt2jYoppoDp7Y5poI2uTvnHXvYiYv3__aaE]fdavidson@m...[/url
> Enviado el: jueves, 12 de abril de 2001 23:35
> Para: basicstamps@yahoogroups.com
> Asunto: [noparse][[/noparse]basicstamps] Windows ME?
>
>
> I took my new Windows ME notebook with me today to a remote site. The
> target stamp was a Stamp2 and the IDE was stampw.exe v1.1.
>
> Being a suspicious sort about the possible influence of NT policies
> on ME I tested this setup before I left for the site. My little test
> program ran fine and displayed its Debug statements correctly.
>
> But when I went to download the real application at the site the stamp
> would just lock up. I inserted a debug statement at the beginning of
> the program to see if the application was running at all and was
> surprised to find the program then ran just fine. I took out the debug
> statement and the app stalled again. After some experimentation I
> discovered it did not make any difference where I put the debug
> statement; everything would run just fine even if the statement was
> inserted past the end of the program! Finally I found that if I
> disconnected the RS-232 cable from the Stamp while it was hung after a
> no-debug-statement download the stamp would subsequently boot the
> program and run just fine.
>
> I believe the download process was hanging the serial port somehow and
> the cable removal or a debug process was clearing this fault. Since
> the debug statement didn't have to even be in the code path I also
> think that the debug dialog box may have been the key to clearing the
> fault (it appears whether or not any debug statements actually
> execute).
>
> Does anybody have a clue on this "feature" ?
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
stamp whether or not to run the code or wait for commands from the PC.
The other thing I noticed in working with the BS1 and the DOS editor is that
two different windows pop up depending on whether or not you have a debug
statement in your code. I can't remember how the Windows editor does this
becauses I've always had debug statements in my BS2 code.
Maybe when the editor sees the debug statement it knows to let the BS2 run
after the code has downloaded, but without a debug statement it forgets?
Original Message
> I took my new Windows ME notebook with me today to a remote site. The
> target stamp was a Stamp2 and the IDE was stampw.exe v1.1.
>
> Being a suspicious sort about the possible influence of NT policies
> on ME I tested this setup before I left for the site. My little test
> program ran fine and displayed its Debug statements correctly.
>
> But when I went to download the real application at the site the stamp
> would just lock up. I inserted a debug statement at the beginning of
> the program to see if the application was running at all and was
> surprised to find the program then ran just fine. I took out the debug
> statement and the app stalled again. After some experimentation I
> discovered it did not make any difference where I put the debug
> statement; everything would run just fine even if the statement was
> inserted past the end of the program! Finally I found that if I
> disconnected the RS-232 cable from the Stamp while it was hung after a
> no-debug-statement download the stamp would subsequently boot the
> program and run just fine.
>
> I believe the download process was hanging the serial port somehow and
> the cable removal or a debug process was clearing this fault. Since
> the debug statement didn't have to even be in the code path I also
> think that the debug dialog box may have been the key to clearing the
> fault (it appears whether or not any debug statements actually
> execute).
>
> Does anybody have a clue on this "feature" ?
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
stamp in reset while the program is being downloaded. if noise gets on this
line the stamp will go into reset mode for an instant.
Original Message
From: <fdavidson@m...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, April 12, 2001 5:34 PM
Subject: [noparse][[/noparse]basicstamps] Windows ME?
> I took my new Windows ME notebook with me today to a remote site. The
> target stamp was a Stamp2 and the IDE was stampw.exe v1.1.
>
> Being a suspicious sort about the possible influence of NT policies
> on ME I tested this setup before I left for the site. My little test
> program ran fine and displayed its Debug statements correctly.
>
> But when I went to download the real application at the site the stamp
> would just lock up. I inserted a debug statement at the beginning of
> the program to see if the application was running at all and was
> surprised to find the program then ran just fine. I took out the debug
> statement and the app stalled again. After some experimentation I
> discovered it did not make any difference where I put the debug
> statement; everything would run just fine even if the statement was
> inserted past the end of the program! Finally I found that if I
> disconnected the RS-232 cable from the Stamp while it was hung after a
> no-debug-statement download the stamp would subsequently boot the
> program and run just fine.
>
> I believe the download process was hanging the serial port somehow and
> the cable removal or a debug process was clearing this fault. Since
> the debug statement didn't have to even be in the code path I also
> think that the debug dialog box may have been the key to clearing the
> fault (it appears whether or not any debug statements actually
> execute).
>
> Does anybody have a clue on this "feature" ?
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
I use an external pull down resistor.
Original Message
From: Miguel Puchol <mpuchol@w...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, April 12, 2001 5:50 PM
Subject: RE: [noparse][[/noparse]basicstamps] Windows ME?
> I have had the experience of placing the Stamp in a box with a custom PCB,
> and when the serial cable is connected to the PC, but the Stamp
> compiler/monitor application is not running, the Stamp will simply freeze.
> If the RS-232 cable is disconnected, then all is OK. I wonder if the PCs
> serial port's ATN line remains in the 'reset' state (be it high or low)
when
> the port is closed, or no application is accessing it, but I can confirm
> that it somehow affects the Stamp.
>
> We went to preform a demo for a costumer, and the Stamp & related circuit
> refused to work, it was a disaster. Later back at the lab we concluded
> (after a lot of testing & trying different configurations) that the
> programming cable must be disconnected, after downloading the final app,
for
> the Stamp to work.
>
> I hope this helps,
>
> Mike
>
>
> >
Mensaje original
> > De: fdavidson@m... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=cIF_3yIVsrfQUY3AkQuyHqSKJ8Os3qPLKY8bmZXjfO0zzMMG-zihu0yvTKW6mzdGUm_mqNbvliuY3v7AQpzR]fdavidson@m...[/url
> > Enviado el: jueves, 12 de abril de 2001 23:35
> > Para: basicstamps@yahoogroups.com
> > Asunto: [noparse][[/noparse]basicstamps] Windows ME?
> >
> >
> > I took my new Windows ME notebook with me today to a remote site. The
> > target stamp was a Stamp2 and the IDE was stampw.exe v1.1.
> >
> > Being a suspicious sort about the possible influence of NT policies
> > on ME I tested this setup before I left for the site. My little test
> > program ran fine and displayed its Debug statements correctly.
> >
> > But when I went to download the real application at the site the stamp
> > would just lock up. I inserted a debug statement at the beginning of
> > the program to see if the application was running at all and was
> > surprised to find the program then ran just fine. I took out the debug
> > statement and the app stalled again. After some experimentation I
> > discovered it did not make any difference where I put the debug
> > statement; everything would run just fine even if the statement was
> > inserted past the end of the program! Finally I found that if I
> > disconnected the RS-232 cable from the Stamp while it was hung after a
> > no-debug-statement download the stamp would subsequently boot the
> > program and run just fine.
> >
> > I believe the download process was hanging the serial port somehow and
> > the cable removal or a debug process was clearing this fault. Since
> > the debug statement didn't have to even be in the code path I also
> > think that the debug dialog box may have been the key to clearing the
> > fault (it appears whether or not any debug statements actually
> > execute).
> >
> > Does anybody have a clue on this "feature" ?
> >
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
writes:
> I have had the experience of placing the Stamp in a box with a custom
> PCB, and when the serial cable is connected to the PC, but the Stamp
> compiler/monitor application is not running, the Stamp will simply
> freeze. If the RS-232 cable is disconnected, then all is OK. I wonder
if the
> PCs serial port's ATN line remains in the 'reset' state (be it high or
> low) when the port is closed, or no application is accessing it, but I
can
> confirm that it somehow affects the Stamp.
>
> We went to preform a demo for a costumer, and the Stamp & related
> circuit refused to work, it was a disaster. Later back at the lab we
> concluded (after a lot of testing & trying different configurations)
that the
> programming cable must be disconnected, after downloading the final
> app, for the Stamp to work.
It is possible if the cable is connected to the Stamp, but not to the PC,
to act as an antenna and for noise to cause spurious spikes on the ATN
pin, causing the Stamp to reset.
is most definitely a difference between a download from Windows ME and
from Windows 98 (not sure about other operating systems). At the end
of a download from Windows 98 with a program not containing any
debug statements the transmit data line (TD), request to send (RTS)
and data terminal ready (DTR) all go low (negative volts). After a
Windows ME download of the same routine these three lines are left
high (positive volts).
Of the three lines it appears that the key problem is the TD line; if
it is opened after a Windows ME download containing no debug
statements the stamp (in my case a BS2) will boot and run. If it is
subsequently closed the stamp will continue to run but will crash if
the Reset button is pressed.
Conversely, if the routine contains a debug statement both operating
systems leave these lines low and the routine runs properly.
Note that a steady high TD line is a BREAK. This normally is used to
tell the Stamp to stop executing and prepare for a download.
I suspect that this is an editor bug and that Parallax can fix
the problem.
--- In basicstamps@y..., agarb@j... wrote:
> On Thu, 12 Apr 2001 23:50:07 +0200 "Miguel Puchol" <mpuchol@w...>
> writes:
> > I have had the experience of placing the Stamp in a box with a
custom
> > PCB, and when the serial cable is connected to the PC, but the
Stamp
> > compiler/monitor application is not running, the Stamp will simply
> > freeze. If the RS-232 cable is disconnected, then all is OK. I
wonder
> if the
> > PCs serial port's ATN line remains in the 'reset' state (be it
high or
> > low) when the port is closed, or no application is accessing it,
but I
> can
> > confirm that it somehow affects the Stamp.
> >
> > We went to preform a demo for a costumer, and the Stamp & related
> > circuit refused to work, it was a disaster. Later back at the lab
we
> > concluded (after a lot of testing & trying different
configurations)
> that the
> > programming cable must be disconnected, after downloading the
final
> > app, for the Stamp to work.
>
> It is possible if the cable is connected to the Stamp, but not to
the PC,
> to act as an antenna and for noise to cause spurious spikes on the
ATN
> pin, causing the Stamp to reset.