Hi all, I have a few questions for the programmers from AdamBots or anyone else who knows anything about the IFI_Loader protocol, especially in regards to the ifipictools program. I’m sorry this post is so long, but
I am in the process of writing a portable program loader specifically for the FRC. I’ve written the Intel HEX file reader and I know how I’m going to go about working with input and output from the serial port, but I have really no idea what I’m sending to the FRC’s program port. I was originally just going to extend ifipictools, since it has an open license, but upon looking at the code, I have absolutely no idea what’s going on, as nothing in the code lends to figuring what exactly it DOES.
Basically, all I really get out of it (based on the variable names in the program, since there are no useful comments) is that to load the program, you have to:
Send version information to the PIC.
Send a “base read” command to the PIC.
Send two commands that erase whatever is currently in flash program memory.
“Splice” blocks of memory read from the HEX file into a command that tells the PIC to write that block to whatever address.
Close and reopen the connection to the controller
Send the reset command to the controller.
And in between reads and writes to /dev/sttywhatever you need to wait a few milliseconds to let the FRC write to the user PIC18 before sending more data.
Could anyone involved in the project please help me understand what exactly is going on in that code sequence? Did you get help from IFI or did you just try to pick apart the data going between the FRC and IFI_Loader by monitoring the serial port? Any help would be GREATLY appreciated.
All the work I’m doing on this project will be released under the GPL and will hopefully be cross-platform, so that any team can use our program loader, whether they’re using Linux, Solaris, OSX, Windows, or whatever. Attached is the latest version of ifi-pictools and what I’ve got for the HEX reader right now, which is mostly useless by itself.
I’m not sure if you’ve seen this yet, but a while back someone made a program called IFI Loader Reloaded which I think does about what you’re doing. The source code is included (here), and that should help you; you could also contact the guy who made it.
Wow, thanks a million for the quick reply! The source code to that programmer is much easier to understand. I also found a reference to AN851, a white paper supplied by Microchip for a special bootloader and serial protocol, which is what IFI uses in their FRC (slightly modified, though). It would’ve been nice if IFI supplied that information on their website
Thanks so much again for the help, and especially to Phil Baltar and John Dong for their original work on this
I’ll make sure to post more info when I’ve figured things out a little more and written the base code. I want to make this worthwhile for more than just our team in the end.
You’ll probably want to look at my Python port of IFI PICLoader, which I called “pycloader”.
I tried to make the modules which handle reading of the HEX file (which is based on a spec from Intel) and interfacing with the controller as usable as possible.
The Intel Hex reader interface is more hackish than I’d like, but it works. It supports more record types than is actually used.
The PIC interface (what you’re interested in) is a little more manageable, IMHO. I’ve tried really hard to make sure it’s all documented and laid out nicely and…
The C version is not really readable. I first tried porting it by doing a line-by-line port and simplifying. I then grabbed PortMon from Sysinternals and just figured it out. The resultant protocol I documented (or tried to) on my website. (Also in CVS.)
Any suggestions would be appreciated.
And no, I don’t understand the parameters to the ERASE command, yet.
Hey all, thanks for the help I’ve got just about everything implemented on the basic API level- serial I/O, transmitting and receiving command packets (including EEPROM read/writes and the repeat and replicate commands), and Intel HEX reading.
Soooo what I am probably going to do is use that code as a shared library (how does libfrcloader.so sound? ) and make a terminal-based loader first (to test) and if that goes over well, a GTK+ version. A shared or static library would be good if someone wants to write an ncurses or plain X version or something… I dunno.
Phil, you mentioned in your ifi-reloaded thread that you had the white paper for the IFI modifications to the AN851 bootloader. Do you still have it? I noticed in your code that you never actually use ifi_prep(), did that ever affect program loading? I think I’ve got at least part of what the weird packets being sent mean.
“erase1” = STX STX 0x09 0xE0 0x00 0x08 0x00 0x00 DLE 0x0F ETX
“erase2” = STX STX 0x09 0xE0 0x00 0x40 0x00 0x00 0xD7 ETX
Taking out the control characters, it looks like it could be this:
Command 0x09
Rows 0xE0
Address 0x000800 (and 0x004000)
Data 0x00
and then the usual checksum.
I think command 0x09 is basically just a mass row write to whatever byte data is (in this case, 0x00). Since one row is 8 blocks or 64 bytes, I guess it’s writing E0 rows of 0x00 (0x3800 bytes) to 0x0800 (Which accounts for the range 0x0800 - 0x4000) and the same amount to 0x4000 (0x4000-0x7800). From the looks of it, it’s just doing a bulk erase to the upper limit of a device’s program memory (3FFF is the limit on the PIC18F442, 7FFF on the 18F8520, etc.) in parts since it can only write/erase 256 rows at one time. Seems kind of redundant to me (why not use the regular row erase command?). Also, I think the second E0 should be FF (write from 0x4000-0x8000), I’ll check that once I actually get a controller to test it on.
Wow, that was way more than I thought I was going to type. Sorry!
I never used ifi_prep() because I couldn’t figure out what the command did. From what I can gather, it does some sort of erase. However, just using the normal erase commands works fine.
I’ve finished the entire backend interface and have been working on the terminal version on and off for a week or so. So far, everything works just fine - erasing the device, loading programs, dumping user memory, reading configuration memory, etc. all have been tested on the PIC18F8520 controller (2005).
I need some brave souls with access to the 2004 and 2006 controllers to help me out by figuring out the device ID for them using my program, since the program’s configuration file relies on device IDs and I only have the 2005 ID (0x0B01). The program will run fine without the correct IDs, it just will assume the memory bounds of the PIC18F8520 which may prevent some programs from loading completely.
Here is the current source tarball: http://lights2dx.net/source/other/frcprog.tar.bz2
Compile it using the make.sh script (I’ll get around to a Makefile later). To get the information needed, run it like so: ./frc -i -c --device /dev/ttyS0 (replace ttyS0 with whichever port you actually use)
The Device ID is broken up into 2 parts. Only the first is used to identify the processor. For the 8520, it’s B00h. For 8722, it’s 1400h. See tty.py, VersionMask, RevisionMask, and Processors.
