Using Bootloader

SeeCwriter · Joined: 18 Nov 2013 Posts: 159

If you set the per character delay to 10ms, and are running at 9600 baud, you are basically running at 960 baud. Add to that 100ms per line, and my program of 142K, with 3200 lines, will take just over 31-minutes to transfer.
Shouldn't the bootloader be using Xon/Off to throttle data?

I've use the bootloader on other pics with programs of a similar size and they took less than a minute to download. What is different about the 18F67K22?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I only picked those numbers because I wanted to solve the problem
quickly. I wanted to post some answer quickly. I didn't try to fine-tune
the delays or investigate why it works. It was the middle of the night and
I wanted to get it done and go to sleep.

If I have time, I may now investigate it further. Or I may put it off.
Remember, I don't work for CCS.

SeeCwriter · Joined: 18 Nov 2013 Posts: 159

PCM Programmer, I wasn't being critical of you. Thank you for your work.

I'm going to experiment with TeraTerm, since that seems to be where the problem is.

Ttelmah · Joined: 11 Mar 2010 Posts: 19221

It suspiciously sounds as if TeraTerm is not handling XON/XOFF correctly.
10mSec would be long enough for the block write to work between bytes
on the serial. Is this enabled in the Windows device manager settings as well?.
Problem is that if it is not 'on' in the hardware, and the serial code tries to
handle it in software, even with the default buffering there can be several
bytes already in the buffer.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Yes, I made sure that Xon/Xoff is enabled in Windows Device Manager
for Com1. I also enabled it in TeraTerm, and I would check it periodically
to make sure of that.

Ttelmah · Joined: 11 Mar 2010 Posts: 19221

I remember seeing an issue like this with some USB adapters, but not with a
'real' port. Do you have any form of RS232 monitor hardware?. If so it'd
be really interesting to see if data is being sent after the XOF byte.
There doesn't seem to be anything about the UART on this chip that
would cause problems. No errata except one in synchronous mode.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I will obtain one. Might not get it until Monday.

SeeCwriter · Joined: 18 Nov 2013 Posts: 159

I found out how to use SIOW and it provides from interesting information. It has a logging feature that will log everything it receives and transmits on the serial port. The full log to upload my program using the bootloader is below. It fails after sending 2-lines. Notice that the PIC bootloader never sends an XOFF or XON, only an ACK after each received line. I've looked at the loader in loader.c, and it clearly shows that it's sending an XOFF when it gets a complete line. I can't explain why it doesn't.

Receive:
[0D][0A]PIC[20]Bootloader[20]v1.0[0D][0A]Waiting[20]for[20]download...

Transmit:
:040500003AEF66F078[0D]

Receive:
[06]

Transmit:
:040500003AEF66F078[0D]

Receive:
[06]

Transmit:
[15]

Ttelmah · Joined: 11 Mar 2010 Posts: 19221

One possibility.
If you have hardware XON/XOFF enabled, the UART may be responding
and filtering these out.

SeeCwriter · Joined: 18 Nov 2013 Posts: 159

I thought hardware flow control is RTS/CTS and that XON/XOFF is software flow control. How would a UART even know whether 0x13 was an XOFF or a binary byte?

SeeCwriter · Joined: 18 Nov 2013 Posts: 159

I've been working with CCS tech support today to try and figure this out. It turns out that Xon/Xoff have to be disabled in order for it to work. Tera-Term doesn't work with Xon/Xoff enabled or disabled. But SIOW works with it disabled.

Ttelmah may be right about the UART filtering out those chars. If true, Tera-Term may be looking for those chars to control sending, but it never sees it, so it keeps going. Just guess.

temtronic · Posted: Thu Jul 25, 2019 4:22 pm

Arrgh... something so simple is causing a lot of headaches..
things were easier when REAL comports where on PCs....

Suggestion. Try using RealTerm. I've got version 200.0.07 and it has options for hardware (RTS/CTS..etc) AND XON/XOFF. You can even control which characters are XON and XOFF !

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19221

There is a complexity with the terms 'hardware flow control', and 'software
flow control'. Generally the term 'hardware flow control' is used for
a method that has a physical line (like RTS/CTS). However on modern
UART's, 'software flow control', can be done in hardware!...
On a lot of the later UART chips, because there are issues with their
large buffers if you leave it to the application to actually respond to the
control character, you can program the UART chip itself to react to
the control characters. However I don't think the UART removes the
characters when it does this. Not sure though. Datasheet read needed.
Fun. Smile