Tera Term binary file transfer issue/bug

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While working on my custom boot loader I stumbled upon this weird issue with Tera Term 4.105.

 

My boot loader (named "BOOTNPB" as in no-protocol binary) uses a simple text-based interface with commands being single-characters (e = erase, l = load firmware, s = start firmware). When I want to update FW I press "l" and then simply send the binary file to the boot loader through UART using Tera Term's File -> Send file. But for some reason Tera Term will keep on sending data indefinitely even though the file size is only 7724 bytes!

 

Here is the output with a slightly modified boot loader that just prints number of received bytes every 1kB boundary:

*** Starting BOOTNPB ***
BOOTNPB version   : v0.1
Valid application : NO
Force stay in BL  : NO
WDT reset         : NO

 

h - handshake
e - erase FW
l - load FW
s - start FW

RX count = 1024 bytes
RX count = 2048 bytes
RX count = 3072 bytes
RX count = 4096 bytes
RX count = 5120 bytes
RX count = 6144 bytes
RX count = 7168 bytes
RX count = 8192 bytes
RX count = 9216 bytes
RX count = 10240 bytes
RX count = 11264 bytes
RX count = 12288 bytes
RX count = 13312 bytes
RX count = 14336 bytes
RX count = 15360 bytes
RX count = 16384 bytes
RX count = 17408 bytes
RX count = 18432 bytes
RX count = 19456 bytes
RX count = 20480 bytes
RX count = 21504 bytes
RX count = 22528 bytes
RX count = 23552 bytes
RX count = 24576 bytes
RX count = 25600 bytes
RX count = 26624 bytes
RX count = 27648 bytes
RX count = 28672 bytes
RX count = 29696 bytes
RX count = 30720 bytes
RX count = 31744 bytes
RX count = 32768 bytes
RX count = 33792 bytes
RX count = 34816 bytes
RX count = 35840 bytes
RX count = 36864 bytes
RX count = 37888 bytes
RX count = 38912 bytes
RX count = 39936 bytes
RX count = 40960 bytes
RX count = 41984 bytes
RX count = 43008 bytes
RX count = 44032 bytes
RX count = 45056 bytes
RX count = 46080 bytes
RX count = 47104 bytes
RX count = 48128 bytes
RX count = 49152 bytes
RX count = 50176 bytes
RX count = 51200 bytes
RX count = 52224 bytes
RX count = 53248 bytes
RX count = 54272 bytes
RX count = 55296 bytes
RX count = 56320 bytes
RX count = 57344 bytes   <---- pressed MCU reset button
*** Starting BOOTNPB ***
BOOTNPB version   : v0.1
Valid application : NO
Force stay in BL  : NO
WDT reset         : NO

 

h - handshake
e - erase FW
l - load FW
s - start FW

RX count = 1024 bytes   <---- pressed MCU reset button
*** Starting BOOTNPB ***
BOOTNPB version   : v0.1
Valid application : NO
Force stay in BL  : NO
WDT reset         : NO

 

h - handshake
e - erase FW
l - load FW
s - start FW

RX count = 1024 bytes
RX count = 2048 bytes
RX count = 3072 bytes
RX count = 4096 bytes
RX count = 5120 bytes
RX count = 6144 bytes
RX count = 7168 bytes
RX count = 8192 bytes
RX count = 9216 bytes
RX count = 10240 bytes
RX count = 11264 bytes
RX count = 12288 bytes
RX count = 13312 bytes
RX count = 14336 bytes
RX count = 15360 bytes
RX count = 16384 bytes
RX count = 17408 bytes
RX count = 18432 bytes (and goes on forever)

 

However when I send the file with "binary" option checkbox unchecked I get almost correct number of bytes - this is expected since Tera Term modifies new-line and some control characters (which of course is disastrous for my firmware so cannot be used).

 

*** Starting BOOTNPB ***
BOOTNPB version   : v0.1
Valid application : NO
Force stay in BL  : NO
WDT reset         : NO

 

h - handshake
e - erase FW
l - load FW
s - start FW

RX count = 1024 bytes
RX count = 2048 bytes
RX count = 3072 bytes
RX count = 4096 bytes
RX count = 5120 bytes

 

I tried RealTerm which does indeed send the correct number of bytes:

 

BOOTNPB version   : v0.1
Valid application : NO
Force stay in BL  : NO
WDT reset         : NO

 

h - handshake
e - erase FW
l - load FW
s - start FW

 

RX count = 1024 bytes
RX count = 2048 bytes
RX count = 3072 bytes
RX count = 4096 bytes
RX count = 5120 bytes
RX count = 6144 bytes
RX count = 7168 bytes

 

So apparently Tera Term's binary file transfer is not working properly! Has any one else seen this problem? I searched for any similar reports but could not find any...

/Jakob Selbing

Last Edited: Wed. Jan 8, 2020 - 02:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Wouldn't you be better off using a packeted protocl like X/Y/Z modem? (actually forget X, from Y upwards it sends binary length so you know how much to expect).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not really "compiler" or "programming" related - but I guess "off topic" is the only other option?

 

jaksel wrote:
Tera Term's binary file transfer

What, exactly, do you mean by that?

 

If you're just chucking binary data out of a serial port, and expecting TeraTerm to catch it - yes, I have had problems with that:

 

https://www.avrfreaks.net/forum/...

 

It seems that TeraTerm will still interpret certain values as control codes - despite trying to disable all that.

 

frown

 

To be fair, a Terminal isn't really the right tool for this job 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
a Terminal isn't really the right tool for this job

unless, of course, you can set it to a specific "binary" mode ...

clawson wrote:
Wouldn't you be better off using a packeted protocl like X/Y/Z modem?

My thoughts exactly!

 

The advantage of X/Y/Z modem is that almost every terminal does implement them!

 

I have used them in such applications for that very reason.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Wouldn't you be better off using a packeted protocl like X/Y/Z modem? (actually forget X, from Y upwards it sends binary length so you know how much to expect).

For simplicity the boot loader receives binary data directly and writes it to flash - there is no flow control nor "protocol" implemented for this stage. This works fine at baud rate of 115,200 and even higher rates (up to around 568,000) are theoretically possible but haven't tried it. I just use a large RX buffer (256 bytes) which only reaches about 48 bytes at the most.

 

awneil wrote:

jaksel wrote:
Tera Term's binary file transfer

What, exactly, do you mean by that?

 

If you're just chucking binary data out of a serial port, and expecting TeraTerm to catch it

No, it's the other way around. Tera Term running on a PC can send the contents of a file on that PC to the serial port -- in this case to the MCU sitting in the other end of the serial port. In this case it is a binary file containing a firmware image that I want the boot loader to write into flash.

 

https://ttssh2.osdn.jp/manual/4/en/macro/command/sendfile.html

 

awneil wrote:

- yes, I have had problems with that:

 

https://www.avrfreaks.net/forum/...

Yup, I have had that problems *many* times. I just restart Tera Term and get on with life but it sure is annoying. But that is another issue, as explained above.

 

awneil wrote:

To be fair, a Terminal isn't really the right tool for this job 

Why not? I use a terminal because I wanted to implement a text-based UI that only requires a terminal running on the PC. Sure I could write a custom software to handle the communication, but it is definitely not necessary in this case. Also I have the boot loader working properly with other terminals (e.g. RealTerm) so it really isn't an issue with terminals in general - only Tera Term.

/Jakob Selbing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you tried just copying the file with COPY /B ... ?

 

 

 

jaksel wrote:
I use a terminal because I wanted to implement a text-based UI

Exactly: a Terminal is for text-based stuff - not binary!

 

This is exactly why we have things like Intel Hex - so that you do not have to rely on a transparent binary link[1].

 

it really isn't an issue with terminals in general

I would say that it's something that should not be expected of a Terminal.

 

The fact that you happen to get away with it in certain particular circumstances on certain particular programs is a matter of luck - not design.

 

only requires a terminal running on the PC.

As noted, you can do exactly that with X/Y/Z modem!

 

That really is the way to go.

 

The implementation is really not large or difficult.

 

 

edit

 

[1] Not that I'm suggesting that you do send Intel-Hex to the micro!

 

That would not be a good idea.

 

typo

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jan 8, 2020 - 01:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Have you tried just copying the file with COPY /B ... ?

No, are you saying that COPY support writing a file to the serial port? Either way I would need a terminal for the initial commands.

 

awneil wrote:

jaksel wrote:

I use a terminal because I wanted to implement a text-based UI

 

Exactly: a Terminal is for text-based stuff - not binary!

 

This is exactly why we have things like Intel Hex - so that you do not have to rely on a transparent binary link[1].

Sure, but most terminal programs support sending binary files so why not take advantage of that?

 

awneil wrote:

it really isn't an issue with terminals in general

I would say that it's something that should not be expected of a Terminal.

 

The fact that you happen to get away with it in certain particular circumstances on certain particular programs is a matter of luck - not design.

I don't agree but thanks for the pep-talk ;-)

 

Tera Term has a bug in its "Send file" feature. Other terminal programs work as they should in this respect. I can't see that my design is to blame for Tera Term's shortcomings.

 

awneil wrote:

only requires a terminal running on the PC.

As noted, you can do exactly that with X/Y/Z modem!

 

That really is the way to go.

 

The implementation is really not large or difficult.

Sure I don't argue with that. But my intention with this specific boot loader implementation was to not use a protocol but to send the binary as it is to the serial port. Which does work fine with both RealTerm and YAT and probably other terminal programs -- just not with Tera Term.

/Jakob Selbing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the nice things about Teraterm (apart from the Japanese comments ;-) is that it is open source so the 4.105 you are trying to use is here:

 

https://osdn.net/projects/ttssh2/scm/svn/tree/head/tags/teraterm-4_105/

 

It should, therefore, be possible to find the bit that does binary file transmission and look at what it's stopping condition is. Without looking I sort of assume it is just doing fgetc()s until feof() but maybe that isn't the case??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaksel wrote:
are you saying that COPY support writing a file to the serial port?

 

 Sure it does!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I sort of assume it is just doing fgetc()s until feof() but maybe that isn't the case??

and, perhaps, omitting to ensure that all the reading & writing is done in Binary mode ... ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

It's quite tricky to follow the source as the filenames are a bit cryptic (maybe because of Japanese heritage?) but I *think* the file transfer stuff is in the region of line 1194 in this:

 

https://osdn.net/projects/ttssh2/scm/svn/blobs/head/tags/teraterm-4_105/teraterm/teraterm/filesys.cpp

 

and it looks like line 1203 may be where it reads the size of the file to send. This would be best explored by loading the SLN into VisualStudio, build for "Debug" and then breakpoint around there - start a file transfer and see if it hits a breakpoint there and see what result it actually reads for file size. Also then follow the actual transfer and watch for the stopping condition.

 

I'm sure "zmatsuo" would love a patch sent back to him if you can fix a fault in the open source (the whole point of FOSS software!)

 

If there is a fault you might want to look at the SVN revision history and see when and how it was broken in the first place.

 

There also appears to be some kind of Bugzilla like ticket system on that site too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I am not sure I have the time or motivation to do the debugging, but at least I submitted an anonymous ticket:

https://osdn.net/projects/ttssh2/ticket/39911#preview

/Jakob Selbing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am a hobbyist who is weak on software but a bit better at hardware.  I am trying to restore a 1970's PDP-8f computer with 4k of ferrite core memory (althoughI have made a solid state memory for initial testing purposes).  The old Digital Equipment Corporation had diagnostic programs to load onto the machine and test the hardware.  I have attempted to use this version of TeraTerm to download the binary diagnostic files to the PDP-8.  No way to do Xmodem, etc - this old machine was designed to receive serial data from a teletype and no hand-shaking.  So I am a guy who has not written these binary files and does not have option to use more "modern" protocols for my purposes.  I would be vulnerable to the same cutting comments made by some of the above critics in this string of posts.  I would just say to jaksel: yep, I am having some troubles doing the binary file transfers with this software and may have to look for another (but have yet to find another terminal emulator that will let me send binaries without using any protocols except just sending serial data in uninterrupted fashion).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

docee wrote:
have yet to find another terminal emulator that will let me send binaries without using any protocols except just sending serial data in uninterrupted fashion

 

See #6 & #9 - you can just use COPY /B  for that.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

docee wrote:
this old machine was designed to receive serial data from a teletype and no hand-shaking.

Well is was common for them to use xon/xoff handshaking, so you would need to disable that on the PDP end so data would not be interpreted as handshake, also baud rates were pretty slow on those TT, 110 baud 7E2 being common as well, so that can also be an issue with binary, not having an 8 bit channel, not to mention its most likely a 20ma loop too.

 

Jim

who once worked briefly with a PDP-8i

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not a 20 mA loop for this board. Using RS232 into and out of the M8650 serial board in the PDP-8.  Although I could go as slow as 110, this board is set for 2400 baud (max for this board, but my M8655 boards would go up to 9600 baud), 8 bits, no parity, one stop bit.  The PDP-8 is using the DEC RIM loader hand-toggled into the front panel by me - no xon-or xoff handshaking involved or coded into those 16 hand-toggled instructions.  The memory of the computer is EMPTY except for what I hand-toggle in or what I load into it using this binary file transfer.  Basically the UART on the PDP-8 board tells it that another byte of binary serial information has arrived and my 16 lines of code deposits it into memory.  So nothing to disable on the PDP-end.

 

As for "use copy /B",  does that mean when I am in the terminal emulator, I can enter this in some way into the terminal screen?  If the file I want to send is in removable drive F and is called "ABCDEFG.rim" I just type "copy ABCDEFG.rim /B" onto the screen????  My laptop is a Windows 8 (yes) machine using the terminal software to send the binary file out a USB port through a USB to RS232 adapter cable to the PDP-8.

 

Perhaps the "use copy /B" is done in a different way that I am not familiar with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

docee wrote:
...but have yet to find another terminal emulator that will let me send binaries without using any protocols except just sending serial data in uninterrupted fashion).

Perhaps RealTerm would do? It has the same binary file transfer capability as Tera Term.

 

 

/Jakob Selbing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

docee wrote:
As for "use copy /B",  does that mean when I am in the terminal emulator

No - that's from the command line:

COPY /B ABCDEFG.rim COMx:

You will need to disconnect the terminal emulator first to make the COM port available

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

jaksel wrote:
Perhaps RealTerm

This looks hopeful:

 

 

realterm.sourceforge.io wrote:
§ Sending Files

You can dump a file directly to the port. Files are sent raw ,  the exact bytes in the file are sent out. There is no "protocol" and just sends everything. (versions before 1.14 swallowed ^Z / 0x1A). Hex values, python/c style backslash sequences etc are NOT converted to anything, just sent literal.

 

https://realterm.sourceforge.io/#Sending_Files  

 

haven't tried it myself

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Apr 29, 2020 - 07:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, RealTerm does work fine. My "perhaps" remark was not referring to uncertainty regarding the binary file transfer capability. 

 

One nice thing regarding Tera Term and RealTerm is that you can define various delays to avoid overflowing the receiver. I have used that feature a lot when transferring software from my PC to an old Apple II computer.

 

A drawaback regarding RealTerm though is that when making the main window larger it seems to update the text buffer incorrectly (or perhaps there's a setting for that?).

/Jakob Selbing

Last Edited: Wed. Apr 29, 2020 - 10:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another nice thing about RealTerm is the facility to send binary data manually - I've been using that recently.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


As well as Teraterm's "protocol transfers" it has a "raw" send file option....

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but that's what the OP was saying didn't work!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not talking to the OP. I am talking to the necromancer in #13/#16 (please try to keep up!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the "issue" would apply equally to the necromancer

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaksel wrote:

When I want to update FW I press "l" and then simply send the binary file to the boot loader through UART using Tera Term's File -> Send file. But for some reason Tera Term will keep on sending data indefinitely even though the file size is only 7724 bytes!

For simplicity the boot loader receives binary data directly and writes it to flash - there is no flow control nor "protocol" implemented for this stage. This works fine at baud rate of 115,200 and even higher rates (up to around 568,000) are theoretically possible but haven't tried it. I just use a large RX buffer (256 bytes) which only reaches about 48 bytes at the most.

The PC is way too fast for this. This is why you say the file never ends, it misses the EOF string.

In the time it takes the micro controller to deal with the data it receives from the PC,

you will have lost the next data coming in, especially at 115200 baud.

 

You need to slow the incoming data (using the line delay in Teraterm) or use some kind of flow control (using CTS and RTS).

Teraterm has been troublesome with flow control, but it does work with Silabs CP2102 and real FT232RL adapters.

I have never been able to get the flow control working with a regular RS232 serial port, even dealing directly with the 

originator of Teraterm (and the language barrier) it never worked.

I have had success with Teraterm 4.102. I am finding the newer versions are troublesome in terms of flow control.

Last Edited: Wed. Apr 29, 2020 - 08:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

newbie123 wrote:
The PC is way too fast for this. This is why you say the file never ends, it misses the EOF string.

Eh?? that doesn't make sense!

 

It's the PC that's sending - so it should not miss the "EOF"

 

In fact, as it's a binary file, there isn't an "EOF string" - it relies upon the file size from the file system.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...