flow control problem with usb/rs-232 converter

[dan king]

I hope this isn't too far off topic, butttt I'm having flow control problems using my bootloader when I use usb to rs-232 converters. I have been using a modified bootloader from the Microchip AN that was written in assembly for a few years now.

;Author: Mike Garbutt
; Company: Microchip Technology Inc.
; Revision: 1.00
; Date: 26 June 2000
; Assembled using MPASM V2.40

Unfortunately, my laptop is being replaced with a model that doesn't have a serial port so before the transition takes place I wanted to test my development environment (16F877 with max232 transceiver). Glad I did because I can no longer send code to my target boards and it appears that the flow control isn't working properly.

I use Hyperterm for sending the code, and nothing has changed here, essentially only the cable. When I send the code to the target I continually get errors with the transfer and I can see that the flow control on the ATEN UC-232A continues to blink after the error occurs. Also, if I change the ASCII properties to delay 1millisecond between characters the transfer happens successfully but also painfully slow :( Many other changes were tried as well, all seem to be masking the fact that data is being sent even though the PIC is trying to stop the flow.

I have tried reducing the buffer settings for the PC in hopes that this would help but still no luck.

Any insight/suggestions would be appreciated.

BTW, my compiler version is CCS PCM C Compiler, Version 3.130
for what it's worth.

Rgds,
Dan

[PCM programmer]

This appnote may be helpful in explaining the problem.
http://www.ftdichip.com/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf

Is this bootloader used entirely for software development ?
If so, try a different bootloader. Try the one from:
http://www.microchipc.com

[dan king]

Thanks for the info. I'll need some time to review. The BL from Microchip has been really convenient as it has worked well with Hyperterm. This really has been helpful as it doesn't require an app to be installed, this is almost required in my line of work as lots of various computers can/will interface to the target boards but on occasion are required to update the code. My final codes don't make use of flow control so in those cases the usb/232 converters have worked just fine.

Anyhow, I'll have to review and re-assess my options.

Thanks for all your help.

[PCM programmer]

The Microchipc.com bootloader uses software flow control (or at
least the version that I looked at in the past did this).
The Windows application communicates with the bootloader code
in the PIC by sending control codes (bytes) to "ACK" the receipt
of data and tell it when to send more. I haven't tested it with
a USB-to-serial converter but because of the software flow control,
I think it would likely work.

[dan king]

Why do you think sw flow control would work when hw flow control doesn't? I would expect the same issues to be present since the buffers that are working against the PIC stopping the flow of data would still be present. It seems that the larger issue to overcome is that the USB data transmission isn't really designed for byte communications but packets of data(many bytes). I'd like to modify the BL I'm using, if possible, because I have been very happy with the performance and convenience. Obviously if the time has come to move on to another flavor, I can handle it.

Again, thanks for your input.

Dan

[dan king]

Well, after a bit of research (Thanks to PCM programmer for some info) and a little investigative work with the scope I have resolved my code transfer issue using a usb serial converter. The short of it is that the problem wasn't flow control at all. After connecting a scope to all of the uart lines I could see the flow control was happily stopping the transfer of data from the PC to my pic. The problem actually ended up that the ATEN USB serial converter cable started sending corrupt data, most likely due to issues covered in the FTDI app note. I had a few ftdi FT232BM chips lying around and cobbled up my own converter cable and low and behold the system(bootloader) works beautifully again.

I just ordered a few usb converter cables that use the ftdi parts so I guess I'm all set. Everyone beware All USB serial converter cables are not created equal !!!!!