Bootloader - Updating FW - SIOW works, TeraTerm doesn't

[Ttelmah]

Linux has had this fixed for a very long time. If you are seeing this in
Linux as well, then something else is wrong. On the EasyPIC, you need to
explicitly load the FTDI drivers. By default Windows loads it's own, and
these don't have the fix.

[Milentije89]

I already have version 2.12.28 from 16.8.2017. Acording to FTDI website it is the latest one for FT232RL.

It does not work with TeraTerm, but with SIOW does.

[Ttelmah]

OK. That is very peculiar. I know I have found in the past that the FTDI
did not show this issue.

[Milentije89]

Hmmmm, few new things.

With FTDI chip on its latest drivers I see the difference in comparison with MCP2200.

When using MCP2200 DC3 and DC1 are passing through. But, with FT232RL they don't.

With MCP2200 I see: DC3 ACK DC1
With FT232RL I see: ACK

So, FT232RL with drivers that I have works, it recognize DC3 and DC1 (XON/XOFF) correctly, but RealTerm and TeraTerm do not stop sending data after FT232RL receives XOFF command.

I just double checked and XON/XOFF control is set in both device manager and terminals.

This is a nightmare.

[Ttelmah]

What that means is that your terminal program is ignoring the handshake
that is then sent from the driver. The status of the UART should be changing
to say not to send.

[Milentije89]

That would mean there are two problems.

1. MCP2200 driver which doesn't work with XON/XOFF
2. TeraTerm and RealTerm do not work with XON/XOFF

I can't believe that Microchip has this kind of problem with its chip that is on the market for so many years.
Also, it is unbelievable that terminals have same kind of a problem.

Is this for real?

EDIT:
As I said previously it doesn't work even from command prompt.

That would suggest it might be the problem on OS level?

Than we can imagine that SIOW has that done on software level. Probably parsing received string and looking for 0x11 and 0x13 in it to control the flow, while in "programming mode". Because, what else could explain SIOW working even when XON/XOFF is turned off in device manager and SIOW itself.

[Ttelmah]

Have you tried from the command prompt with the FTDI driver now
handling XON/XOFF?.

[Milentije89]

I did, doesn't work, as I wrote in previous post.

[Ttelmah]

That is surprising.
The point about SIOW, is that it turns this on. Remember all the serial
programs merrily change the settings while they are running.

[Milentije89]

[temtronic]

yeesh, I feel your pain and frustration.
Any chance you've got one of the 'TTL-USB' $2 modules you could easily try 'on the bench'? I've used them for years,never had a problem, though I don't use a bootloader.
When I first got the 18F46K22, I used two of them..
confgured as ....PC->module 1-> PIC UART1-> PIC UART2-> module 2->PC
used Realterm to send/rcv a huge datafile,fast (115k200) , no problems
Sorry can't offer anything else to try.
I sure hope you solve this before you go bald

Jay

[Milentije89]

Hi temtronic,

I only have FT232 and MCP2200 chips on hand.
I do not have any problem using them except this XON/XOFF thing in combination with TeraTerm, RealTerm or any other serial port except SIOW.

I am using FT232 and MCP2200 for years, and never had any problem.

Just to recap:

SIOW works with FT232 and MCP200
TeraTerm, RealTerm, YAT, and so on... doesn't work with FT232 nor MCP2200 (regardless of flow control settings).

Also, we know that MCP2200 driver is passing through XON/XOFF commands.

Just for those who could ask why I don't then use SIOW. It's not about me, its about end user.

EDIT:

I am losing my mind.
SIOW can't be used without CCS C, so it is not an option for end user. Correct me if I am wrong.
I will pass this problem to my girlfriend who will make a small app that will load hex file and upload it to device.
We already tried that, and it works. Only thing left is to give it usable GUI.

XON/XOFF is disabled in device manager (and is not used when opening COM port), we are sending row by row, and waiting for 0x13 and ox11 as ASCII characters in between.

We already did this when we made Mobile App for Android and iOS to update firmware via Bluetooth.

There is no point in wasting time any more with terminals.

[Ttelmah]

As a comment, have you considered just using the hardware handshake?.

SIOW, certainly in the past could just be run as a standalone program.

[temtronic]

Overall, probably a 'good business decsion' to make your own app. that way YOU have control over 100% of it...and.. of course IF it should ever fail, then the GF can be blamed....
I hate to think of the time WASTED on this 'simple' problem.....
..and I miss Not having REAL hardware 'RS-232- comports on a PC
Yup, the dinosaur still moans about 'new and improved'....

[benoitstjean]

If I can add my two cents, I've been using Tera Term for years without much problems. Please note here I haven't read the entire thread but what I do and have been using for years is the following:

Setup > Terminal then put a checkmark in Local Echo to see what you send to Tera Term.

Setup > Serial Port then set it to your speed and make sure you have XON/XOFF enabled for the flow control.

Then, this is the key part: take your HEX file and **drag** it to the Tera Term window... don't use the menu options... just drag it. It'll then pop-up a window asking "Are you sure you want to send the file content?" and then click YES.

Then you will see your hex data in the Tera Term screen all beeing written to the same line but you will also see a progress bar in a pop-up window.

I use the FTDI 232 chip on my current circuits but used to use USB to serial FTDI cables with built-in chips and it has always worked.

I use Tera Term 4.73 because I've had problems with more recent versions.... so if it works, why change it. I use PIC24 MCU's, never tried bootloader and FW update on other PIC devices.

Ben