Using MSComm getting system lockup

[ildenizen]

Good day. I have already been helped once here today, let's see if I can bat 1000!

I am slowly putting together a com application. I have now been able to successfully open and send a character of information to a USB device configured as a Virtual Serial Port.

However, here is the odd part. Within a command button, I send a single character using MSComm1.Output. It works great. Each click event on my command button sends out a different character successfully. But, if I try to send multiple characters one character at a time (each one using a separate MSComm1.Output line), I lock up my system completely. If I get lucky I can Ctrl-Alt-Del the application, but other times must reboot the entire system.

Personally, I can't see how this is any different except in how fast the characters are being sent, though there may be something else going on I have not considered.

Anyone have any ideas? Thanks in advance!

 

[Sheco]

Does it lock up if you send a single string of many characters?

 

[Homersim2600]

It sounds like what is happening is that the receving end is not ready for the second char so you are having a collision of data. What you could do is get a second computer together and set it up so that it peeks at the data moving to and fro on the data bus. You could also use a fast Oscilloscope if you have one available. Without knowing what communication is being sent and received it is kinda hard to tell what is going wrong. Does the application on the receiving end send any information back to the computer? If so, and again, there may be a point in time where your computer is transmitting whilst also attempting to receive the data sent back from your USB module. Hope this helps a bit...

LF

"As far as the laws of mathematics refer to reality, they are not certain; as far as they are certain, they do not refer to reality."--Albert Einstein

 

[gmmastros]

I've done this before. A long time ago. So I just looked at my code.

Suppose you have an array of characters you wanted to send, one at a time.

For i = LBound(arTemp) To UBound(arTemp)
MSComm1.PortOpen = True
MSComm1.Output = arTemp(i)
DoEvents
MSComm1.PortOpen = False
Next

For some reason, opening the port, sending the data, and then closing the port is in my code. It is significantly sower to send data this way, but give it a try.

 

[ildenizen]

Thanks for the input! I think I have half the story now. The following is a bit long, so tune out if you are not interested

First, I have a USB chip connected to my USB port. The USB chip has drivers that are supposed to make it look like a serial port (Virtual). Also, the USB chip is an FT245BM used in a USBMOD4 by Elexol, and it is supposed to make use of a 384 byte receive buffer.
Finally, I have used a simple capacitive delay that takes the Received Data line (low when data is in), to connect to the Read Data line (low to display data, low to high transition to get the next data item). The capacitive delay is just used so that the display LEDs have enough time to show the value just sent.
Putting it all together - it looks like the delay works just fine for slow data, allowing the "Received Data" line to go back high and wait for more. But if I send too much data too soon, some data is buffered, and it locks the "Data Received" pin low, since my simple circuit is only designed to "clock" one byte through.
The only question I now have is why this USB module is not making use of the receive buffer as I had expected, as my lockup happens with just 3-4 bytes of data sent, not hundreds as I would have expected.
The good news is that if I manually strobe the Read Data line low and high a couple times, the program "unlocks" for me.

I suspect that this USB chip may require the use of the DLL drivers provided to make full use of the chip's capabilities. On that note, does anyone know how I can incorporate DLLs into my application?

 

[Homersim2600]

Have you tried removing your capacitor from the Received data line? I imagine that this is creating your problem. Capacitors, as you may know, will hold a voltage level up to it's capacitance value. So, what is happening is that when the data line is high, the capacitor charges, and when this pin goes low, then the capacitor discharges through something, usually a resistor, but in this case it may be the diode. The relationship between the values of the resistance to ground and the capacitors capacitance value creates your time delay. So, what I think is happening is that your RC (resistor/capacitor) timing delay is holding your data line high for too long. I come to this conclusion because you say that you can manually trigger the read data line and get the circuit to "unlock". Remove your delay circuit and see what happens.

I hope I am on the right track here, lemme know if it don't work.

LF

"As far as the laws of mathematics refer to reality, they are not certain; as far as they are certain, they do not refer to reality."--Albert Einstein

 

[ildenizen]

It has taken a while, however, I now have the final answer to all my problems, and it was partly what all you guys said.
#1) I needed to be much more careful on how I clocked data from the USBMOD4 side. It is very finnecky. I no longer get any computer lockups, and the USBMOD4 chip now successfully uses the full 128 byte FIFO butter without any errors.
#2) Sending one byte at a time wastes the USB bandwidth, since the USB on the host PC can have approximately one millisecond latency for each block of data sent, whether that is the single byte, or the larger block send out.

Thank you all for your help. I am now able to send data using the Virtual Com Port to the USB Module at rates exceeding 1 Million bits/second. That is good enough for me, so I will forgo trying to use the DLL drivers - which at this point will only complicate my life!

Again - thanks to all, and I hope my posts and yours help someone else out.