UIRT2 - girder: "cannot set com port speed"

[levyshay]

Hi all,

I have assembled and programmed the pic, no problem. I can test it using the handy new test program and get the right response. I am using the latest girder 3.2.4, the latest uirt.dll, and the 1.7 firmware. This sure seems like a girder problem since the test applet is ok. Ideas? Oh, btw, after girder times out the test prog will no longer work until rebooting. Should I go to the older girder? From the forum it looks like the new stuff is working for you all.

Hi, Well I assembled one also (Thanks Luc), I've tested this thing for 2 days, and I've encountered thous problems also. For some reason the comunication between the UIRT2 and the PC is lost, If you program the pic to do commands by itself you'll notice that it is doing them so the pic is running.
After reading in Luc's page I've tried lifting R7, and also grounding it, but it didn't help. Finally after reading that for normal working (Not programming) you need only RxD, TxD and ground I made a cable with only those wires and it's now working good, so the problem might be DTR/RTS. I've tested it for a whole day recieving/transmitting and no problem. I've also tested it with few serial communication programs (and the UIRT2 test program, and all of them had problems when DTR/RTS is connected, on SerialWather (a great program for testing IR devices) toggeling RTS on/off allways solved the problem, toggeling DTR works only sometimes. I guess it's a problem with the PIC software.
Configurations tested on are Girder 3.1, 3.24, and PIC software version 1.7

BTW: On Luc's page kit A the leds in the picture are reversed! (but I guess most people use kit B)

Hope I helped,
Shay Levy.

[levyshay]

Hi,

I think that the problem is either with the RS232 Levels (Maybe a pulldown/pullup resistor needed) or with the PIC software.
As I founded that when I connect the RTS and DTR it will eventually crash every program using serial port (Some like girder very often, and some like windows terminal very rearly) . If I connect a modem to the same serial port I don't have this problem. I think that the PIC causes the OS to see a state on the UART pins that is not legal, and it doesn't know what to do with it. If I remmeber correctly long time ago when I built a device communicating with the PC if I sent a illegal number of bits on the serial port it hanged the program using that port.

As for people getting some random codes, I've checked jon's suggestion that there are noises from the pc power suplly and indeed there is, pc's use switched power supply this cause alot of noises. I'm gonna try putting a capacitor on the IR reciever power suply and check it.

Shay Levy.

[levyshay]

I just did some tests for this problem on a P4 1.6 running XP and Girder 3.2.4 and also have the same problem: "cannot set comm speed".
The problem is during initialisation and must be related to the speed of the PC ( a P2-350 works fine).

Well I don't get this error, just that after some time girder stop responding. (My PC is PIII-800).
I've also tried to program the PIC with jon's version 1.6 instead of 1.7, so if all lines are connected girder allways stuck after one remote code recieved, on 1.7 it holds up an avarage of 50 (but sometimes can be even 10) So it shows that a fix was done, but I guess something is still missing.


One last important remark: The UIRT2 has been designed to be compatible with the original UIRT and it's ICSP feature. Due to this configuration it will not react as a normal serial device because the modem signals are completely out of standard: like CTS connected to RXD etc...
Therefor tests with standard serial communication programs will fail, these can only work without the modem signals connected.

I don't agree on that, as if I use Danijel Pticar's PIC software as solves these problems as I described on this thread: http://www.girder.nl/phpBB2/viewtopic.php?t=2101
And then the UIRT2 works with every serial communication software. Also I've seen such configuration of RTS tied with RxD in serial cables for connecting between 2 PC's so it's can be done.
Means that the UIRT2 hardware is ok, and there's something within Jon's PIC software, I could debug it (Also compare with DP's software) if a source in assembler or higher level is avaiable.

Shay Levy.

[levyshay]

Hi,
My point is not if it can work on any serial program, But to explain why girder crash/hang, and to show that the problem is not with girder or it's plugin.

Shay.

[Robin]

I had symptoms of this with my UIRT ... it turned out to be the wire used ... I'd used unshielded cable and when I replaced it with shielded stuff everything worked brilliantly.

Also, ensure that you're not using a Sony remote ... these generate RC5 (?) codes, which differ for alternate presses of a button.

[gkour]

I have run into this as well and its not the test prog that doesn't work after, it's that the serial port is locked for all other apps that try to access the port.
I haven't found a solution to that as well... :(

[gkour]

Sony remotes don't use the RC5 standard. They use a specific coding scheme developed by sony. The RC5 code sends the same code but only chnges one bit ,the toggle bit, to indicate if a button is held down or not.

[Luc]

I noticed that on the bracket version picture the black bar on the zener diode is on the com port side, opposite the scematic. Which is right?

Yes, the picture is wrong, the parts layout is correct. I will upload a correct picture soon (I hope).
I did not yet find the time to try Girder 3.2 and thus can't comment on this.

Luc.

[Luc]

Configurations tested on are Girder 3.1, 3.24, and PIC software version 1.7.

Strange, this is the first time this problem is reported for Girder 3.1
I use 3.1 on different systems running WIN98SE and everyting works fine.
Did you use the correct plugin for the 3.1 test?



BTW: On Luc's page kit A the leds in the picture are reversed! (but I guess most people use kit B)


It might be confusing but they are not reversed, these are recuperated IR LED's and what you see inside these is different from normal. I will have to make time to put new pictures on the site.

Luc.

[Luc]

Ok, I'll reverse the diode. Another question, in the instructions it says to install the crystal after programming. I reprogrammed my pic with the crystal in place yesterday. Could that be the problem?

I don't think so, programming with the crystal in place fails sometimes but only in rare occasions.



Is there a way to totally wipe the pic and start from fresh again?

Unfortunatly not, the PIC cannot be wiped, if you want a fresh start you need a new PIC. Did you try the change in cabling mentioned in this thread by Shay Levy?

[Luc]

I installed Girder 3.2.4 on a PII-350 running WIN98SE with the 1.7 firmware and also the latest uirt plugin.
It works just fine, could it be the speed increase of the new Girder combined with the PC speed and eventually the OS used?

Luc.

[Luc]

I just did some tests for this problem on a P4 1.6 running XP and Girder 3.2.4 and also have the same problem: "cannot set comm speed".
The problem is during initialisation and must be related to the speed of the PC ( a P2-350 works fine).

When Girder initialises the Uirt: DTR goes high and RTS stays low holding the PIC in reset state.

When I remove ZD1 it works: Removing ZD1 lets the PIC run always, also when the comm port is closed.
It works also whithout R7: When DTR is set high during initialisation it pulls CTS, RXD and RB7 high. removing CTS alone does not solve the problem.

In this situation the initialistion is as follows: RTS and DTR become high, then RTS pulses low and then stays high.

I think that there is a timing problem between the PIC and the PC during initialisation because when the pic is already running before Girder starts it works, it could also be a problem with the levels generated by a high level DTR but then only on "high speed" machines.

There are several possible solutions: the cable or component workaround or a change in the initialisation procedure either in the PC or the PIC firmware.

One last important remark: The UIRT2 has been designed to be compatible with the original UIRT and it's ICSP feature. Due to this configuration it will not react as a normal serial device because the modem signals are completely out of standard: like CTS connected to RXD etc...
Therefor tests with standard serial communication programs will fail, these can only work without the modem signals connected.

Luc.

[Luc]

I don't agree on that, as if I use Danijel Pticar's PIC software as solves these problems as I described on this thread: http://www.girder.nl/phpBB2/viewtopic.php?t=2101
And then the UIRT2 works with every serial communication software. Also I've seen such configuration of RTS tied with RxD in serial cables for connecting between 2 PC's so it's can be done.
Means that the UIRT2 hardware is ok, and there's something within Jon's PIC software.
There's obviously a difference between Jon's and Danijel's serial protocol and hence the different results. Some standard serial communication software might work if they don't look at the modem signals and of course it's always possible to make non-standard connections on a serial port for dedicated purposes as long as the software is written for it.
This is what is done in the UIRT2 for the In Circuit Serial Programming.

[vbray]

Hi all,

I have assembled and programmed the pic, no problem. I can test it using the handy new test program and get the right response. I am using the latest girder 3.2.4, the latest uirt.dll, and the 1.7 firmware. This sure seems like a girder problem since the test applet is ok. Ideas? Oh, btw, after girder times out the test prog will no longer work until rebooting. Should I go to the older girder? From the forum it looks like the new stuff is working for you all.

[vbray]

I wonder if this is a circuit problem, since the folks who got the assembled version are not having this issue.. not sure. I noticed that on the bracket version picture the black bar on the zener diode is on the com port side, opposite the scematic. Which is right? Both ways I get the same result. What about the other diodes? They are assembled per the circuit layout but the picture is not clear on both. Is there any setting for the proper speed of the port? :-? :-?

[vbray]

Ok, I'll reverse the diode. Another question, in the instructions it says to install the crystal after programming. I reprogrammed my pic with the crystal in place yesterday. Could that be the problem?

Is there a way to totally wipe the pic and start from fresh again?

[vbray]

That's it!! I made a cable straight through, pin2-pin2, pin3-pin3, pin5-pin5 and that made girder happy. Thank you very much!

[vbray]

That's it!! I made a cable straight through, pin2-pin2, pin3-pin3, pin5-pin5 and that made girder happy. Thank you very much!

You must have missed my earlier post... the minimal cable fixed the comm problem. Thanks for the help everyone! Now if I can figure out why it receives a different code every time a button is pressed....

[vbray]

I had symptoms of this with my UIRT ... it turned out to be the wire used ... I'd used unshielded cable and when I replaced it with shielded stuff everything worked brilliantly

Do you mean the serial cable? I hooked up a shielded serial cable and that seemed to help some. What about the cable to the receiver? I have now soldered it to the board and it's working a little better but still weird. by better I mean it gets the 'right' code more frequently ( i think )

I started a new thread for this problem...
http://www.girder.nl/phpBB2/viewtopic.php?t=2083

[hoxford]

I'm seeing the same problem. I'm also using girder 3.2.4, the latest uirt.dll, and the 1.7 firmware. I built a UIRTB from Luc's schematic.

If I plug the UIRTB into the WOL connector and the serial port and use the test app, it works. I had an issue at first with the test app and the RTS line but thanks to a super quick fix by Jas39/Anders the test app is working beautifully.

However, I'm having the same "cannot set com port speed" from Girder. I scoped the lines while it was 'stuck' trying to initialize and it looks to me like there's a slight voltage on RXD and it's confusing either the UART or Girder or both so that initialization doesn't continue. When it's trying to initialize, RTS is still low so the PIC is reset and DTR is high which I think is causing the voltage on RXD. By momentarily shorting RXD to TXD (which was low) I could get it to unhang and initialize properly every time. My solution for now is to remove the connection to DTR and everything seems to initialize fine with no manual intervention.

I think the difference between the Test App and Girder is in the timing of the control lines being set. The Test App seems to do a better job on my hardware.

[hoxford]

It's probably an "edge condition" influenced by all those things -- OS, UART, processor speed, tolerances of the UIRT components, etc. I'm not sure how the UIRT plugin sets up the COM port control lines but there might be a more defensive way for it to initialize them that would help the problem.

Or maybe some of us just built our UIRT hardware a little oddly? :)

[andybryant9]

Hi guys,

With all this talk of DTR & CTS, a thought occurred. If Windows is having trouble handshaking & setting the port speed... why not help it out.

Windows / control panel / system / hardware / device manager / Ports / Com1 / Port Settings...

I then set them to 115200, 8, None, 1, Hardware.

The standard UIRT2 + cable shipped by Luc WORKS UNMODIFIED! Girder now starts up, loads my file, and autoenables the plugin with no problems.

Woo Hoo! Problem solved.

Andy.

[andybryant9]

Spoke too soon. Sorry. False alarm. It didn't fix it.

Andy.

[andybryant9]

Woo Hoo! Problem solved.


:D Aah. This time... It is solved! :D

Luc has posted a new .dll for girder that solves the problem.

http://users.skynet.be/sky50985/

I tried burning the 1.8 firmware (http://users.skynet.be/sky50985/UIRT_10MHZ_1_8.zip), and loading the latest V2.1 plugin (http://users.skynet.be/sky50985/UIRT_DLL_2_1.zip), but didn't get much joy. The receiver worked fine, but I couldn't get it to transmit anything. Bummer. :( :(

I went back to the 1.7 firmware (http://users.skynet.be/sky50985/UIRT_10MHZ_1_7.zip), and the previous plugin called new_uirt.zip (http://users.skynet.be/sky50985/new_uirt.zip), and all is now working.

Andy.