View previous topic :: View next topic |
Author |
Message |
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Tue Jul 23, 2019 3:21 pm |
|
|
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
|
|
Posted: Tue Jul 23, 2019 6:11 pm |
|
|
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: 160
|
|
Posted: Wed Jul 24, 2019 8:57 am |
|
|
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: 19535
|
|
Posted: Wed Jul 24, 2019 10:39 am |
|
|
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
|
|
Posted: Wed Jul 24, 2019 10:59 am |
|
|
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: 19535
|
|
Posted: Wed Jul 24, 2019 11:22 am |
|
|
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
|
|
Posted: Wed Jul 24, 2019 2:37 pm |
|
|
I will obtain one. Might not get it until Monday. |
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Thu Jul 25, 2019 11:33 am |
|
|
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: 19535
|
|
Posted: Thu Jul 25, 2019 12:55 pm |
|
|
One possibility.
If you have hardware XON/XOFF enabled, the UART may be responding
and filtering these out. |
|
|
SeeCwriter
Joined: 18 Nov 2013 Posts: 160
|
|
Posted: Thu Jul 25, 2019 1:57 pm |
|
|
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: 160
|
|
Posted: Thu Jul 25, 2019 3:07 pm |
|
|
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
Joined: 01 Jul 2010 Posts: 9236 Location: Greensville,Ontario
|
|
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: 19535
|
|
Posted: Thu Jul 25, 2019 11:00 pm |
|
|
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. |
|
|
|