BS2 - Editor sees it under Run>Identify, but reports "No stamps found" on code load?
xanatos
Posts: 1,120
I've been using stamps for years now, never encountered this one before.
BS2px. Parallax Professional Development Board. Code working good.
In Editor, I select Run > Identify.
Scanning... reports BS2px with echo & loopback, all good, just like normal.
Make a code change to a SEROUT statement going to a memory stick datalogger, that has a following SERIN and DEBUG STR buffer\4 statement.
Code runs then hangs because I forgot to make a match between the byte count specified to the SEROUT, and the corresponding SERIN STR buffer\4 line:
Simple error, easy to catch & correct.
So I correct it. Control R to load it, editor reports No Basic Stamps Found.
"Odd", I think. So I do the Run>Identify thing again. System reports BS2px, etc. All good. Go to load the code again, No Stamps Found.
Powered the PDB off & on - Run>ID sees the stamp; code load - does not.
Powered down PDB, quit editor, pulled the USB to Serial (Parallax brand - always worked), waited 30 seconds, plugged it all back in, started up the editor, powered up the PDB.
Run>ID - stamp there.
Code load - no stamps found.
Finally, I pulled the stamp and put another one in and the code ran fine.
I pulled THAT stamp and put the original back in and IT ran fine.
Purposely recreated the same error by mismatching the bytes to get versus the bytes to receive and voila, no stamp found on code load.
Repeatable oddity.
Question is: Under what circumstances can the program running on the stamp prevent the stamp from being seen by the editor when loading code only?
Note that I have specified my TX & RX pins as 10 & 11, so no conflict with the stamp's "system" serial port... but something about that that SERIN command hanging waiting for that missing byte prevents the stamp from accepting a new code load.
I've been working with stamps for YEARS and never encountered this before.
Any ideas?
Here's the full code - I'm just messing with reading data from a text file on the memory stick - very basic (no pun intended). The datalogger has been firmware set to 4800, SCS, etc., hence the abbreviated init section for it. The text on the stick in PCODE.txt is:
2133
8740
8729
1741
9870
6262
6500
BS2px. Parallax Professional Development Board. Code working good.
In Editor, I select Run > Identify.
Scanning... reports BS2px with echo & loopback, all good, just like normal.
Make a code change to a SEROUT statement going to a memory stick datalogger, that has a following SERIN and DEBUG STR buffer\4 statement.
Code runs then hangs because I forgot to make a match between the byte count specified to the SEROUT, and the corresponding SERIN STR buffer\4 line:
DLTX PIN 10 ' RXDATA (4) on Datalogger
DLRX PIN 11 ' TXDATA (5) on Datalogger
'...
SEROUT DLTX, DBaud,[$0B,$20,0,0,0,$04,CR]
SERIN DLRX, DBaud, [STR buffer\4]
DEBUG STR buffer\4, CR
Simple error, easy to catch & correct.
So I correct it. Control R to load it, editor reports No Basic Stamps Found.
"Odd", I think. So I do the Run>Identify thing again. System reports BS2px, etc. All good. Go to load the code again, No Stamps Found.
Powered the PDB off & on - Run>ID sees the stamp; code load - does not.
Powered down PDB, quit editor, pulled the USB to Serial (Parallax brand - always worked), waited 30 seconds, plugged it all back in, started up the editor, powered up the PDB.
Run>ID - stamp there.
Code load - no stamps found.
Finally, I pulled the stamp and put another one in and the code ran fine.
I pulled THAT stamp and put the original back in and IT ran fine.
Purposely recreated the same error by mismatching the bytes to get versus the bytes to receive and voila, no stamp found on code load.
Repeatable oddity.
Question is: Under what circumstances can the program running on the stamp prevent the stamp from being seen by the editor when loading code only?
Note that I have specified my TX & RX pins as 10 & 11, so no conflict with the stamp's "system" serial port... but something about that that SERIN command hanging waiting for that missing byte prevents the stamp from accepting a new code load.
I've been working with stamps for YEARS and never encountered this before.
Any ideas?
Here's the full code - I'm just messing with reading data from a text file on the memory stick - very basic (no pun intended). The datalogger has been firmware set to 4800, SCS, etc., hence the abbreviated init section for it. The text on the stick in PCODE.txt is:
2133
8740
8729
1741
9870
6262
6500
' =========================================================================
'
' {$STAMP BS2px}
' {$PBASIC 2.5}
'
' =========================================================================
' -----[ I/O Definitions ]-------------------------------------------------
DLTX PIN 10 ' RXDATA (4) on Datalogger
DLRX PIN 11 ' TXDATA (5) on Datalogger
' -----[ Variables ]-------------------------------------------------------
buffer VAR Byte(4)
FILESIZE VAR Word
fs VAR Byte ' Read step counter
' -----[ Constants ]-------------------------------------------------------
#SELECT $STAMP
#CASE BS2, BS2E, BS2PE
T2400 CON 396
T9600 CON 84
T19K2 CON 32
#CASE BS2SX, BS2P
T2400 CON 1021
T9600 CON 240
T19K2 CON 110
#CASE BS2PX
T1200 CON 3313
T2400 CON 1646
T4800 CON 813
T9600 CON 396
T19K2 CON 188
T38K4 CON 84
#ENDSELECT
DBaud CON T4800 ' Datalogger baud rate of 4800
' -----[ Initialization ]--------------------------------------------------
DEBUG "Starting", CR
SERIN DLRX, DBaud, [WAIT("DD")]
DEBUG "> DD", CR
SERIN DLRX, DBaud, [WAIT(">")]
DEBUG "> Rx", CR
PAUSE 400
' -----[ Program Code ]----------------------------------------------------
Main:
DO
GOSUB Size
SEROUT DLTX, DBaud, [$0E, $20, "PCODE.txt", CR]
SERIN DLRX, DBaud,[WAIT (">")]
DEBUG "Open", CR
FOR fs = 0 TO FILESIZE STEP 6
SEROUT DLTX, DBaud,[$0B,$20,0,0,0,$04,CR]
SERIN DLRX, DBaud, [STR buffer\4] 'Change to \5 to get it to hang & disappear from the loader!
DEBUG STR buffer\4, CR
SEROUT DLTX, DBaud,[$0B,$20,0,0,0,$02,CR] ' Trash characters LF & CR and increment the pointer to the next 4 characters
PAUSE 10
NEXT
PAUSE 1000
SEROUT DLTX, DBaud,[$0A, $20, "PCODE.txt", CR] ' Close file
SERIN DLRX, DBaud,[WAIT (">")]
DEBUG "Closed",CR
PAUSE 2000
LOOP
' -----[ Subroutines ]---------------------------------------------------------------------------------------------------------
Size:
SEROUT DLTX, DBaud, [$01, $20, "PCODE.txt", $0D]
SERIN DLRX, DBaud, 5000, No_Data, [WAIT (" "), HEX2 FILESIZE.LOWBYTE, HEX2 FILESIZE.HIGHBYTE]
SERIN DLRX, DBaud, [WAIT (">")]
DEBUG "File size ", DEC FILESIZE," Bytes", CR
RETURN
No_Data:
DEBUG "Nope...", CR
GOTO Main
Comments
That is an odd one for sure. I am going to see if I can get our BASIC Stamp Guru to have a look at this thread. Stay tuned...:cool:
Is there anything different about the NEW BS2px chips that might come into play here? These are both from the new "generation" of that chip. And I'm sure you can imagine that in the years I've been using Stamps, I've managed to hang a BS2 and all of its variants in just about every way possible, and not once have they ever ignored a reset and reload of the code. But I can get these to do it on command!
Thanks for the info... staying tuned.
Chris, I thought YOU were the BS2 Guru! Between you and JonnyMac all problems can be solved.
Dave,
Does this happen when the Datalogger is connected or disconnected, or both.
Jim
Even when the datalogger is disconnected. Once that code was loaded, disconnecting the datalogger and powering down the whole board, waiting, and re-powering, without reconnecting the datalogger, the editor sees the BS2 under the Run>ID thing, but not when I Ctrl R or click the arrow to load code... it scans and reports no stamp found. With nothing at all connected to the stamp - just the stamp, sitting in the socket.
Dave
Yes, I actually did that, and also tried hitting the reset button at various millisecond intervals before or after hitting the code-load button, just to see. I played with this one quite a while and couldn't figure it out. Like you, I thought that if I could sneak the code in fast enough before the program started, I might get lucky. Plus I was using pins 10 & 11 as my serial lines, not the "system serial" port - for just the reason you specify, I don't want to block editor access by using the system port.
The odd thing in this whole odd thing, is that the code executes normally while ignoring the loader. I can see the debug stuff come up when I've powered down & back up (won't get the debugs on a simple reset because the power doesn't cycle on the datalogger, so the program hangs there waiting for the DD and the >. And yes, I even tried loading the code at that point as well!
The only thing that seems to make a difference is literally removing the chip for about 10 minutes. When I put it back in, I can load code. And if I purposely recreate that \5 instead of \4 error on the SERIN/SEROUT commands, I can reproduce the results. It seems to be that it hangs the whole chip waiting for that byte that never arrives. Baffling (not baffling that it hangs waiting, but that it has seemingly an effect on the chip outside normal program execution).
At first I thought I had done something to fry the poor thing... glad it turns out it just needed to get a 10 minute vacation!
What baffles me the most is how the run>id routine DOES get a response, but the code load does not. How do those two things differ? What's the difference at the actual serial comm level? What command is issued when you're just asking the chip to identify, vs. when you're looking to load code from the editor? Say for example, I wanted to program up another stamp to simulate being the editor - what would I send to the stamp under test to have it report back that it was a BS2px, with loopback & echo?
Start --> Control Panel --> System --> Hardware --> Device Manager --> Ports (COM & LPT) ... Find the Port that enumerates to the BS2 on your system ... Right click and select "Properties" --> Port Settings --> Advanced --> Latency Timer (msec)
On my system the Latency Timer is set to 16 ... when I increase it to 100 or so I see the same errors that you are describing.
You had to leave it off for 10 minutes?!? I think a quick power cycle was good enough for mine.
I found a stack bug in your code, although I have no idea how the BS2 stack works (if it even has a proper one). No_Data should RETURN, not GOTO Main.
I discovered that interesting things get written to the bottom of EEPROM after the programming failures I was having. If you can, run this on a BS2px (untested!) immediately after your download problem happens, and you should get some interesting text at the bottom of memory pertaining to the error:
'{$STAMP BS2px} '{$PBASIC 2.5} x VAR byte i VAR word DEBUG CLS FOR i = 0 TO 2047 READ i, x IF x>=31 DEBUG x ELSE DEBUG "?" END i=i+1 IF i.NIB0 = 0 THEN DEBUG CR END NEXTHi Beau,
I'll try playing with different settings in there. Right now, my latency was set to 16. See photo attached for all settings for my port.
Thanks... this could be interesting.
Dave
Hi Electrodude,
Thanks for the info. The GOTO was in there for a reason that was no longer being used in the code as it stands - previously (on another program with a completely different function for that timeout, I couldn't return to the spot on no_data, I actually needed it to then go to the main loop... in this program, the only timeout ref is in the size subroutine, and it gets through that properly without accessing the no-data sub.
I'll try running that code - it'll be interesting to inspect all eeprom locations after running various programs!
Dave
You can consider me Tier 2 Tech Support if you like. :nerd: Thing is, when something defies logic (as this does) I get a hold of the only person I know who deals with BASIC Stamp Modules at the firmware level, which is Jeff Martin. He is currently looking into this issue.
I was wondering if this was fixed, I have a bs2px which does the exact same thing, my legacy timer is set to 16
my software version is 2.5.3, the board is a board of education USB, the identify works fine, when you try to load code it fails "with not found"
regards
Jeff
I haven't heard back, I know they had the Expert looking into it
It's odd, but it's workable. Not sure where the good folks at Parallax are at looking into this one, but I'm sure they'll let us know when they find anything.
Dave
it now works, the changes were in the device settings of windows 7 (which is the one I have) for the com port of the interface (under device setting) i set the latency to 50, then it seems to work fine.
regards
Jeff
Dave - I noticed your code immediately starts sending serial data when executed, and it made me think of a note in the PBasic IDE "ReadMe.txt" file:
KNOWN PROBLEMS False-Positive Detection of Plug and Play Devices: Some PBASIC programs may cause Windows to think it has detected a Plug and Play serial device when the BASIC Stamp which is running that PBASIC code is plugged into the PC via USB cable while the BASIC Stamp is powered. In typical BASIC Stamp use, it is very rare that false-positive Plug and Play device detection occurs, however, the chances are increased when all of the following items are true: [B] 1) The PBASIC code in the BASIC Stamp outputs serial data within approximately 650 ms of power up/reset.[/B] 2) The BASIC Stamp is powered up before connecting it to the computer. 3) The BASIC Stamp is then connected to the computer via a USB cable. When a BASIC Stamp is plugged into a computer via a USB cable, a Virtual Serial Port is created. Upon detection of a new Virtual Serial Port, the Windows Operating System scans the port for potential Plug and Play serial devices such as serial mice, pens, printers, and modems. During this scanning process, Windows toggles the serial port's DTR line multiple times, causing a connected, and powered, BASIC Stamp to reset multiple times. [B]If that BASIC Stamp Module's PBASIC program is designed to transmit serial data within about 650 ms after power-up/reset[/B], Windows might misinterpret these messages as coming from a Plug and Play serial device, and automatically install a driver for the device it believes it detected. [B]At the very least, this causes the port to be unusable by other programs, such as the BASIC Stamp Editor.[/B] At the worst, it may cause a system lock-up that requires a computer reboot. To prevent this from happening: [B] Recommended Method : Insert a delay, such as PAUSE 1000, at the start of your PBASIC program.[/B] --or-- Alternative Method : Ensure the BASIC Stamp is unpowered before connection to a computer via a USB cable. --or-- Alternative Method : Connect the BASIC Stamp to the computer via a standard, DB9-style, serial cable.The example code I gave is just the prescient parts - the issue happens whether my SERIN happens right away, or at a point several seconds into the program execution. And the stamp is definitely not resetting repeatedly, as the debug lines would have shown that data flow was not happening elsewhere in the program.
In the original program in which I found the issue, the SERIN it was waiting at was after a number of other sensor readings had been acquired and sent via SEROUT, with the program waiting for a SERIN response. Once it hit that, with no device present on the remote side to talk back and fulfill the waiting SERIN... that's when the issue arises. Any time that SERIN sits, waiting, indefinitely (of course if there's a timeout, then this isn't an issue, but for some of my applications, there can't be because the incoming data can be significantly delayed - by hours - depending on the particular device I am interfacing to.)
Latencies don't seem to be an issue. And it seems to only be the new BS2px chips - I ran the program on an older BS2px and did not have the same experience.
But again - it does not seem to be a truly significant issue, just an anomaly that seems to point up that there is some difference in the new chips, and as yet, I haven't seen that that difference, whatever it is, has adversely affected the running of the chips in any of my field applications... which is a very good thing!
And considering I'm finishing design of a project that uses six of these items...
Dave
Lol... you're in good company, I have that experience frequently!