SEROUT Problem while writing to Memory Stick Datalogger

blackbelt

I am using bs2p with the prof dev board to datalog 3 temps, room humidity, time in hr[noparse]:min:[/noparse]sec and date mo:day

I have written a multi bank program. I am facing a problem where the program stops at the SEROUT command after working fine for 10 to 20 min. It will sit there indefinetely..
I put a lot of·DEBUG statements to locate where the program was stopping. (If you were wondering why I had to many debug statements)

Earlier Tracy Allen helped me with the format of the SEROUT command.
The SEROUT command is writing out the time and date (from DS1307) using HEX2 format. There are a total of 16 characters that the SEROUT is sending to the datalogger
14 characters for the time,·date, punctuation like "," plus 2 more for CR and LF where $10 in the SEROUT comes from.··· 16 characters==>·(05,30,15,01,21) ==> 5:30:15 Jan 21

As I said earlier program works fine for more than 1 hr collecting 100's of data points and successfully writing to the memory stick. Is there something that I am not aware of because of the HEX format in SEROUT?

The other thing I tried is·putting PAUSE statements to take care of the write delays before and after DEBUG and SEROUT commands. After adding the PAUSES the program run longer than 1 hr before stopping at the same SEROUT statement.

I am attaching the source code for the multi bank program.
0: Main controls the program banks,
1: Initializes datalogger and executed once
2: Temp and humidity data collection thru LTC 1298 ADC and write to the memeory stick
3: Time and date

Data in the memory stick looks like this at each line ---> First 3 are the temps, Rel Humidity, time and date
28.5,70.3,68.5,30.0,05,30,15,01,21



Thank you for your in advance...

··· IOTERM 0
·
··· I2COUT CPORT,DS1307,7,[noparse][[/noparse]$10]·························· ' Enable OSC @ 1Hz
··· GOSUB Get_Clock

··· PAUSE 500
··· DEBUG HEX2 hr, ":", HEX2 minute, ":", HEX2 sec, "·· ",
··· ········· HEX2 month, "/", HEX2 date, CR
···
··· DEBUG "Debug Hex2 Write is over...", CR
··· PAUSE 500
···
··· IOTERM 1
··· PAUSE 200
···
··· DEBUG "IOTERM 1 is done ...", CR
··· PAUSE 200
···
··· DEBUG "Pause is done...", CR
··· PAUSE 500

··· SEROUT TX\CTS, Baud, [noparse][[/noparse]$08, $20, $00, $00, $00, $10, $0D,
········· HEX2 hr, ",", HEX2 minute, ",", HEX2 sec, ",", HEX2 month, ",", HEX2 date, $0D, $0A, $0D]
··· PAUSE 2000
···
··· DEBUG CR, "TimeDate .... Returning to Main......", CR
··· PAUSE 2000

Mike Green

Since you're using handshaking using an I/O pin (CTS), that's what's causing the SEROUT to hang. What happens if you take that out (the \CTS)?

blackbelt

Mike,

Thank yuo for the quick reply. I started the program without the \CTS. I will let you in the result in 90 mins. Currently the program is running fine w/o the \CTS.

I thought handshaking makes the communication more robust. Could you pls explain me what is happening with and w/o handshaking?

Mike Green

The Datalogger has a buffer for command and some data information. Without handshaking, there's no way for the Stamp to know before transmitting whether the Datalogger's buffer is full or nearly full. CTS means Clear to Send, that it's ok for the Stamp to send data. When the Datalogger's buffer is nearly full, it sets CTS to false. Normally it's true. The Stamp will only send information with SEROUT when CTS is true (if it's used). For some reason, CTS is false and the Stamp hangs waiting for the Datalogger to tell it to continue sending information. There's similar handshaking available for SERIN where the Stamp will set a signal to true when the SERIN is ready for data and leave it false at other times. You have to initialize the I/O pin to false in your program and the SERIN will change it as needed.

blackbelt

So if I put·the statement like HIGH CTS at the begining let's say right after the IOTERM 0 would that be OK to put back the \CTS into the SEROUT command?

Mike Green

No. HIGH CTS would set the CTS pin to output mode and set its state to high (1). If the pin is connected to the Datalogger, you'll damage the Datalogger pin and possibly the CTS pin on the Stamp because the Datalogger pin will probably also be an output, but set to low (0). The short circuit condition will damage one or both devices. Assuming CTS isn't connected to anything, the SEROUT would set CTS to input mode and wait for it to become true regardless of its initial state.

Tracy Allen

You have to ask why CTS is saying, "not ready". If you have an LED and a 1kOhm resistor, or a voltmeter, you can hook it up to the CTS pin to visualize its level and to verify that it is sticking there with CTS high.

In my experience, one possible sticking point is, strangely enough, the state of the RTS line. That is the flow control signal that goes with SERIN. The datalogger expects that line to be low (=BS2 ready to receive data), even during the time the Stamp is sending data to the datalogger with a SEROUT. So,

LOW RTS   ' make RTS low=ready when sending data--RTS is an output from the BS2 and input to the datalogger
 SEROUT TX\CTS, Baud, [noparse][[/noparse] $08, $20, $00, $00, $00, $10, $0D,
 HEX2 hr, ",", HEX2 minute, ",", HEX2 sec, ",", HEX2 month, ",", HEX2 date, $0D, $0A, $0D]
 HIGH RTS   ' make RTS high=not ready until next SERIN or SEROUT command to datalogger

Frankly I am surprised if that resolves the problem, but please try it and let me know if it does. I know there is an issue, but in my experience it arises when a single SEROUT command has more than about 25 characters, and your string has only 16. It might happen at the sector boundaries, which would explain why it works okay 10 or 20 minutes before failing. How much data do you collect in 10 to 20 minutes?

I noticed in your LTC1298 routine

SEROUT TX\CTS, Baud, [noparse][[/noparse] $08, $20, $00, $00, $00, $14, $0D,
DEC2 Temperature1, ".", DEC1 Decimal1, ",", DEC2 Temperature2, ".", DEC1 Decimal2, ",",
DEC2 Temperature3, ".", DEC1 Decimal3, ",", DEC2 Temperature4, ".", DEC1 Decimal4, ",", $0D]

If you count the $0D at the end, there are $15, not $14 characters in the string. I don't think that would be a fatal error. The logger would interpret the $0D as a command instead of part of the string. I don't think that has anything to do with the sticking problem, although the datalogger is generally picky about getting the right amount of data and about unintentional command strings.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

blackbelt

Mike:

The version of the program without the \CTS in SEROUT that I started last night (as yousuggested) was still running this morning - collecting data. With all the PAUSE statements, I am collecting a set of data in every ~13 sec. I will check it again and let you know tonight when I get back home. THANK YOU FOR YOUR HELP...

Allen: I will implement your suggestions towards finding the root cause of handshake problem this weekend and let you know the outcome. THANK YOU FOR YOUR CONTINUING SUPPORT.

Tracy Allen

That it runs ok without \CTS shows that the BASIC Stamp is slow, not fast enough to overrun the datalogger buffer. The presumed high level on the CTS pin is an artifact, and a moot question. The LOW rts I suggested may provide an alternaive fix, maybe not. However, if you are interested in root causes, it is probably buried in the FDTI Vinculum firmware for the datalogger. I discussed this artifact and a couple of other puzzling issues with the FTDI guys at a trade show last year, but I should have had along a demo board to illustrate the effects. It is kind of hard to explain.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

blackbelt

Allen, I watched the status of RTS & CTS pins while the prgram was running. I used LED's and a scope to the this. Voltmeter was not fast enough to show the RTS level change. You can see the scope output in the attached·pdf document.

During normal operation -->

·· CTS pin stayed low at 0V and never·changed status
·· RTS pin was set to low for 56 mili seconds before jumping back to 5V·at the SEROUT command in Timedata.bsp. This happened periodically at 7.2sec - Cycle time it takes to execute the SEROUT command in Timedata.bsp

At the moment where program hung up -->

··· CTS pin was pulled high to 3.3V
··· RTS pin stayed high and never dropped to low

Seems like the issue is the CTS pin going high before the last SEROUT command execution. I can not explain why the CTS pin is going high - Is the datalogger buffer full? If it is, what is causing it to be full? It worked 30 minutes before being full!!
Do you still think that running the following may still help.

LOW RTS   ' make RTS low=ready when sending data--RTS is an output from the BS2 and input to the datalogger
 SEROUT TX\CTS, Baud, [noparse][[/noparse] $08, $20, $00, $00, $00, $10, $0D,
 HEX2 hr, ",", HEX2 minute, ",", HEX2 sec, ",", HEX2 month, ",", HEX2 date, $0D, $0A, $0D]
 HIGH RTS   ' make RTS high=not ready until next SERIN or SEROUT command to datalogger

I have a lot of datalogging projects in mind with remote data collection and transfer using the wireless receiver and transmitters. I would like to help to debug the issue· (with collecting and documenting data) if you are willing to guide me.

Thank you for yur help.

blackbelt

I also tried the LOW RTS before the SEROUT command. It has worked as well.

So far two things have worked:
1) Removing the \CTS option from the SEROUT command
2) Pulling RTS to LOW before the SEROUT command and Raising it to HIGH afterwords.

Another fact is PAUSE statements before and after the SEROUT command does not make the program work. However, 2 second PAUSE extended the program run time to mre than an hour from 10 to 20 minutes.

I am not sure about this but when I connected the scope and the LED's to CTS and RTS pins on the professional development board, it seemed like program run longer before hanging up.

Tracy Allen

The Vinculum chip that is the brain of the datalogger was designed with the idea that in serial mode it would be connected to a full duplex serial port. In a full duplex serial port, the host (the BASIC Stamp in our case) would always be ready to receive data, provided our receive buffer was not full. Now, the Stamp does not have a full duplex serial port and the Stamp is only ready to receive data when it is executing a SERIN command.

If there is a SERIN rx\rts in your PBASIC program, the rts line will be left at a high level, which says, "not ready". Okay. That brings us to the Vinculum. For some reason that is a mystery to me, the Vinculum sometimes checks the RTS line to see if the Stamp is ready to receive, and that happens even if the Vinculum is not going to send any actual data. If PBASIC tries to send something more than about 25 bytes in one string (I forget the exact number), the Vinculum will at that point check the status of the RTS line, and if it is not low=ready, then the Vinculum will set its cts high to indicate that it is no longer ready to receive data. And your PBASIC program locks up. It has nothing to do with the Vinculum buffer being full. (I don't know how big the buffer is actually, but I think it is much larger than 50 bytes). By setting rts low before the SEROUT, and high afterwards, you are fooling it into thinking that the Stamp is always ready to receive.

I have never seen the Vinculum ever actually send a byte back (look at the rx line on a digital scope), and the documentation has no mention of a handshake. I consider it a bug or annoyance in the Vinculum firmware, which, please note, would not occur if the Stamp had a full duplex serial port.

In your case, you are not sending 25 bytes at each instance and it waits 10 or 20 or 60 minutes before it locks up. But the symptom is the same. The reason I asked about how much data was sent, is that I have seen other puzzling things happen in the Vinculum firmware when the amount of data exceeds 1 sector (512 bytes).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com