▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi all!
I'm trying to upgrade the software of my 41 CL, but there's no way to overcome the "TIMEOUT" problem.
I tried with different PC (all running XP) but there's no way, even if I change the time delay in the transfer from 2 up to 10 ms (max allowed).
Sometimes the display show "TIMEOUT", sometimes the calculator just switches off.
I changed even the batteries just to be sure and I prepared the 41 CL with a memory reset (backspace ON) and then performing:
xeq alpha "MMUCLR" alpha
alpha "YFNS" alpha xeq alpha "PLUG1L" alpha
xeq alpha "MMUEN" alpha
xeq alpha "TURBO50" alpha
xeq alpha "SERINI" alpha
xeq alpha "BAUD12" alpha
(thanks to Peter for his newbie guide)
Actually I cannot understand where I'm wrong.
I think I've properly assembled the calculator (I mean the serial cable plugged into the board), one year ago, but actually this is the first time I'm trying in flashing it.
Before to open it and to risk any re-opening issues (read it as "BROKEN POSTS"), or to decide for a clonix approach, in way aof the cable transfer, I would like to know your opinion and I'll appereciate any advice.
Thank-you in advance and cheers from Italy, where the good season is still far to come, dispite of the calendar.
▼
Posts: 267
Threads: 27
Joined: Jul 2005
Hi aurelio,
I also used Peter Laur's guide and had timeout issues using 1200 baud. In my case, the solution was to speed up the transfer using 4800 baud. For example:
On the 41CL side, the command should be: xeq alpha "BAUD48" alpha
On the PC side, the CLWriter comand should be similar to: CLWriter <filename> com<X> 4800 8.
Hope that helps,
Matt
Posts: 1,253
Threads: 117
Joined: Nov 2005
Can you test the COM port on the PC? This may also be the issue, just make sure you´re using the right COM port and that it´s sending the data. Do you see the byte stream on the COMMAND DOS window?
I understand your apprehension about reopening the machine, the Damocles sword of the broken posts is a constant threat.
Maybe also worth trying the inverse operation, transferring from the CL to the PC using CLREAD. Just to eliminate another variable.
HTH,
ÁM
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Thank-you Matt, thank-you Angel!
I've changed the speed parameter, on the COM, on the CL, in the box, but still nothing.
In the last PC the com1 is the only one so that I can't confuse it and I see the byte stream on the COMMAND DOS window...
The display doesn't show any TIMEOUT message, simply it blanks out after a few seconds and I must key twice on the on toogle to switch the CL on
EDIT: at the fifth attempt, without any change it shows a TIMEOUT message.............
Edited: 15 June 2013, 10:37 a.m.
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Trying to understand something more..........
Changed the parameters ad the time delay, but nothing of good.
Sometimes the display shows TIMEOUT, but mostly it is blank (calculator off).
The connector, I'm pretty sure, is plugged properly into the CL
I don't understand why there's a byte stream on the COMMAND DOS window till the end even if there is something wrong in the connection which causes the TIMEOUT of the transmission or the shut-off of the CL, then the data flow should be interrupted, 'cause there's a control at the destination: parity, sum, and what else.........instead the data flow is continuous even if the feedback is not (I assume) good or the calculator is off
As we said laughing at school years ago, "if datas don't reach the destination, it means they drop on the floor or on the table"...and I see nothing, but sure they are not in the CL's RAM!
What is determining the shut-off of the calculator? Batteries are in a perfect shape, I drop into new cells
Well, I tried the reverse operation, assuming that in the ram there is nothing.
I set the YEXP on the CL and CLReader on the PC, the display show continuously the message SENDING, although there's not the target to be sent and only after a certain time the DOS window prompts again on the CLStuff directory.....This sound like was not requested effectlively a feedback on the transmission, maybe there's a fixed timeout for both the destination sides.
To stop the "SENDING" state of the CL I had to get a MEMORY LOST, by removing the batteries....
Edited: 16 June 2013, 8:03 a.m.
▼
Posts: 72
Threads: 2
Joined: Nov 2011
At this point, I assume it's not a simple configuration issue.
Then, if I where you, I would make sure my serial ports are working correctly.
I understand that some of the following suggestions may be out of reach money wise or technically to advanced but it's what need to be done (from my point of view of course) to be sure to pinpoint the problem.
You need two have native serial ports or usb-to-serial dongles and a null serial cable to do this test.
Hooked up the two serial ports on the same pc with the null cable.
Start two communication terminal applications: Windows Terminal or unix screen,
with the appropriate configuration.
Type into one terminal and see if the characters are showing on the other terminal.
If you are not seeing any characters then it's either a defective port, a bad cable or a configuration issue.
If it's working then the next step will be to monitor what's happening on the cable.
To do this you need a breakout box with led's.
You hookup the box between the PC and the CL with direct serial cables and then monitor the RX and TX lines.
If the PC-TX/CL-RX are flashing then the PC is sending something.
If the PC-RX/CL-TX are flashing then the CL is sending something.
If it's working then the next step will be to monitor what's happening in the cable.
To do this you need either a hardware or a software serial sniffer.
You hookup the sniffer between the PC and the CL,
start a sniffing session, do a communication between the PC and the CL, stop the sniffing session and then analyses the data.
Sylvain
Posts: 54
Threads: 6
Joined: Sep 2010
What are the actual parameters you're using on the 41CL side (for YIMP/YEXP)?
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi Raymond, I set the parameters as follows:
BAUD12 (or 48, or 24)
SERINI
of course TURBO50 enabled
Cheers
Edited: 16 June 2013, 12:12 p.m.
▼
Posts: 267
Threads: 27
Joined: Jul 2005
I believe Raymond is asking what address and data length parameters did you store in the alpha register before issuing the YIMP (or YEXP) command?
Edited: 16 June 2013, 3:39 p.m.
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Posts: 267
Threads: 27
Joined: Jul 2005
Quote:
Sometimes the display shows TIMEOUT, but mostly it is blank (calculator off). The connector, I'm pretty sure, is plugged properly into the CL
I have to ask the simple (hardware) questions.. Is the small serial cable fully plugged into the CLPD connector? It's not plugged into the FPGA connector, is it? There should be a plastic plug to keep one from plugging into the wrong connector. If this is correct, then maybe the small serial cable has a problem with it's Rx or Gnd connection. Are you using the RS232 cable that Monte sells, or did you build your own? Maybe this cable has an issue. You would need to test continuity using an ohm meter against Monte's pinout description in the manual. Otherwise, have you tried issuing the YIMP command on the CL with the RS232 cable unplugged? If so, you should only see the TIMEOUT message (the calculator should not turn off). Lastly (firstly?), make sure the CL board has a secure connection without breaking the posts.
Quote:
I don't understand why there's a byte stream on the COMMAND DOS window till the end even if there is something wrong in the connection which causes the TIMEOUT of the transmission or the shut-off of the CL, then the data flow should be interrupted, 'cause there's a control at the destination: parity, sum, and what else.........instead the data flow is continuous even if the feedback is not (I assume) good or the calculator is off
The TIMEOUT message is generated when no, or too few, characters are received. If the CL's input buffer were not able to keep up with the data stream, the CL would display OVERRUN. I'm not sure, but this message gives me the impression that the CL does not issue an XOFF (on the Tx line) to stop the data flow at the PC.
Matt
Edited: 16 June 2013, 3:27 p.m. after one or more responses were posted
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi Matt, I'll try to respond to all:
1)when I talk about the cable connector I mean the RS232 cable that Monte sold me of course and the connection into the femal jack mounted on one of the modules' cover.
2)I think, without re-opening the calculator (for the obvoius and wellknown reason), that the serial cable was fully plugged into the CLPD connector and not plugged into the FPGA, 'cause this one was busy (plastic plug)
3)issuing the YIMP command on the CL with the RS232 cable unplugged I only see the TIMEOUT message.
4)the CL board has a secure connection (without breaking the posts), I'm sure of that 'cause my CL works always properly.
But if I must check the continuity of the small Monte's cable I have only one choice: opening the calculator....aaaaargh!
Hope this can help you to help me =:)
Ciao
Regards
Edited: 16 June 2013, 1:34 p.m.
▼
Posts: 267
Threads: 27
Joined: Jul 2005
Quote:
3)issuing the YIMP command on the CL with the RS232 cable unplugged I only see the TIMEOUT message.
Good. It appears to be a hardware issue, hopefully outside of the CL. Something is pulling it down (too much load on the CL's power supply). Just to rule out a short circuit in the RS232 cable, can you issue the YIMP command with the cable plugged into the CL, but unplugged from the PC? Same result (TIMEOUT, but not turning off)? If so, do the same test again with the cable plugged into the PC (don't issue the CLWrite command). Does the CL turn off? If so, it points to an issue either on the PC com port, or possibly a problem with CLPD port on the CL (unlikely since Monte used this port to program the CL before you ordered the board). To verify your PC's com port(s) are working, I suggest you attempt Sylvain's tests above.
Matt
Edited: 16 June 2013, 3:09 p.m.
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi Matt, I assume (from the beginnig) that should not be a problem of RS232 in the PC, 'cause I ve tried with at least five differents PC!
by the way I will take soon the time and the instruments to do at least in the first one all the Sylvain's tests.
But following your advice I performed all the test and without any CLWriter command the only problem is the TIMEOUT message, I mean the calculator is always on: unplugged from the PC. Same result (TIMEOUT, but not turning off)even with the cable plugged into the PC
Now , back to the first PC 4800 speed 10ns delay, with CLWriter.exe. sending the IMDB.rom, I get just a timeout, after a few seconds,while the stream is still running in the DOS window.
the calculator is still ON
EDIT: I realize now that on all the PC tested are installed both the Microsoft.NET Framework 3.5 and the Framework 4 (client profile and extended), this could be a problem?
Edited: 16 June 2013, 5:12 p.m.
▼
Posts: 267
Threads: 27
Joined: Jul 2005
It's not turning off now? Hmm. Do your PCs have physical DB9 connectors, or are you using a USB-to-RS232 dongle? I'm doing this from memory, but did you go into Control Panel | System | Hardware Manager | Ports | Com<X> | Properties and set the port to match your CLWriter command line parameters? Also, in the same area, under Advanced, are the buffers set down to a low number, like 128 bits (vs the default 4096 size), per Peter Laur's recommendation? Had to ask. In my case, Monte's RS232 cable is plugged into an FTDI dongle (same as hpcalc.org sells) on a Win7 machine.
I use the free wireshark application for packet sniffing on Ethernet networks. Don't know if it can monitor serial conections? It should, it does just about every thing else.
Matt
p.s. I think Raymond will have to answer your Framework 3.5 vs 4.0 question.
Edited: 16 June 2013, 5:39 p.m.
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi Matt, thank-you, thank-you a lot for your care!
I use a phisical 9 pin connector on board.
Strange maybe but in the advanced properties I dont see a range from 128 up to 4096, like in Peter's documentation but I see just
"use buffer FIFO"
and then I can modify two parameter (TX and RX buffer) to set with a cursor in four steps
step from 1 to 14 and from 1 to 16
I think this is the XP interface 'cause is the same in all the PC I tried.
Edited: 16 June 2013, 6:01 p.m.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
It looks like you're ruling out every other possibility, which would lead to believe the installation on the CL may be defective. In my experience there's little thing that go wrong, the connector on the CL board is very small but reliable. Sometimes obvious things may be at fault, have you checked the serial cable and its own connectors?
Posts: 54
Threads: 6
Joined: Sep 2010
What kind of cable do you use from the PC to the 41CL? I think that some people have had similar problems that were caused by either a broken or incompatible cable.
▼
Posts: 312
Threads: 25
Joined: Sep 2009
The CableClub serial cable supplied by Monte with the CL.
▼
Posts: 54
Threads: 6
Joined: Sep 2010
Ok.
There is one more thing you might want to try:
If you run CLWriter (or CLReader) without any parameters, it should list all available serial ports. It could be that your motherboard has more serial ports than you think (there might be some that have not been brought to the outside).
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi Raymond!
C:\CLStuff>CLWriter.exe imdb.rom
Usage:
CLWriter file port [baudrate [delay]]
Where baud defaults to 1200
and delay defaults to 0
Available Ports:
COM15
COM16
COM17
COM18
COM19
COM20
COM21
COM22
COM27
COM28
COM29
COM81
COM3
COM1
C:\CLStuff>
The COM1 is the only 9 pin phisical serial port available on the mainboard and it is tested 'cause I use it frequently to connect my handheld sitemaster to this PC
Except the COM3, the others ae all used by the BT device.
The COM3 is used but I don't understand for what.
Edited: 17 June 2013, 4:34 p.m.
▼
Posts: 193
Threads: 10
Joined: Aug 2009
Quote: The COM1 is the only 9 pin phisical serial port available on the mainboard and it is tested 'cause I use it frequently to connect my handheld sitemaster to this PC.
Hi:
Just a shot in the dark. Have you used COM1 successfully for anything besides sitemaster? If not, is it possible that the software for that device is starting a program on boot that's causing the problem (e.g. something that senses when the sitemaster is connected, etc.)?
If possible can you temporarily reconfigure the sitemaster program to use another port, reboot and see what happens?
Regards,
Bob
▼
Posts: 312
Threads: 25
Joined: Sep 2009
Hi Bob, removing the software did not help me in te enterprise.
thank-you
Edited: 18 June 2013, 4:10 p.m.
|