IFI Loader problem - "Invalid HEX file"

[wun]

I was just trying to download our code to the robot, but when I opened up IFI_Loader, it said "Invalid HEX file - Unable to download...". I'm sure the hex file is valid, and I have also tried using the default hex files... Any ideas?
[edit]
I was originaly using version 1.0.2, but I get the same thing with 1.0.7
[/edit]

[Mark McLeod]

Originally Posted by wun

I was just trying to download our code to the robot, but when I opened up IFI_Loader, it said "Invalid HEX file - Unable to download...". I'm sure the hex file is valid, and I have also tried using the default hex files.

I tested quickly and can get that to happen by cutting off a line of the hex file, e.g., the last line, and by dumping random characters into it.

If you would like a second tester email or post the hex file and I'll try it too.

[edit] got the error with certain random characters

[wun]

Allright, thanks.
Any idea how that could have happened thou? I did a freash compile of one of the files, and the other is the default...
Ill take a look at it when I go in tomorrow thou, thanks.

[Mark McLeod]

Originally Posted by wun

Allright, thanks.

Originally Posted by wun

Any idea how that could have happened thou? I did a freash compile of one of the files, and the other is the default...
Ill take a look at it when I go in tomorrow thou, thanks.

No idea why the default hex file would have become corrupted, but there are lots of ways. What you really want to do at this stage is to continue to break the failure down into discrete tests to localize the problem. Your testing the default hex file was one. Trying different IFI_Loaders was another. I'd test the two hex files on a different computer (that you know works correctly, like mine) to determine for sure if it’s the hex files or a computer/IFI_Loader problem. You can also visually inspect the file, it's ASCII, but only gross problems will be obvious. If the hex file still doesn’t work I’d download the default code again to be sure of having a pristine hex file and try loading the FRC_default.hex file again.

I’ll also try to repeat the error in other ways.

[Greg Ross]

At what point does the error appear? If it's after you tell the loader to download the program, it could be that either the controller is reporting a problem with the checksum, or the loader is detecting a discrepancy in the data echoed back by the controller. (I don't remember, for sure that the controller echoes the data, but I think it does.)

In either case, it could be a communications problem. If you are using a USB/serial adapter, that is a potential error source.

[wun]

I get the problem as soon as I click "Ok" when I'm selecting the hex file (via the "BROWSE" button). The combo-box does not even change to the path of the hex file (I get the same message when I type the file path by hand).
I also just had the guy send me the files from his laptop (the one I was using today) and they seem to work just fine on my machine.
I will work more on it when I get back to school on thursday thou,
Thanks for all your help

[Alan Anderson]

Just a thought -- had you ever done anything with the problematic files using a Linux or Macintosh system? I don't know the loader's quirks, but it's possible that it requires a CR/LF pair between lines, and the files you're trying to use might have only a CR (Mac convention) or LF (Unix convention).

I mention this mostly because of the prominent penguin avatar.

[Mark McLeod]

Originally Posted by Alan Anderson

I don't know the loader's quirks, but it's possible that it requires a CR/LF pair between lines, and the files you're trying to use might have only a CR (Mac convention) or LF (Unix convention).

One of the tests I ran was binary ftp'ing the file between UNIX and Windows machines to get the change in control characters at the end of the lines and it didn't seem to matter to IFI_Loader. I didn't test between old/new Mac and Windows though.

[Alan Anderson]

Originally Posted by Mark McLeod

One of the tests I ran was binary ftp'ing the file between UNIX and Windows machines to get the change in control characters at the end of the lines...

Doing the ftp in binary mode is guaranteed not to modify the end-of-line characters. You'd have to do it in text mode.

A cheaper way to convert Unix-style line breaks to Windows-style is to use WordPad. It will recognize LFs alone, and will write out CR/LF pairs when saving the file.

[Mark McLeod]

Originally Posted by Alan Anderson

Doing the ftp in binary mode is guaranteed not to modify the end-of-line characters. You'd have to do it in text mode.

I was attempting to recreate David's problem and so tested windows and unix style files.

I chose binary on purpose to test the various CR/LF mixes in IFI_Loader on a windows machine. I used ftp in ASCII mode transferring to UNIX and binary coming back to maintain the UNIX style. I verified the file difference on windows. I didn't want ftp changing the UNIX style I'd created back to Windows style.

P.S. I was able to get identical symptoms to the ones David described, where the file path doesn't even appear, when I used non-ASCII characters at the beginning of the file. A pure ASCII corrupted file still displays the filename path while showing the error message.