Loader Protocol: Command 09

I looked quickly at existing open source loaders, and I noticed that all of them use constant strings to erase data. What I have found is gathered at http://www.astro73.com/wiki/IFI_Loader_protocol#Sample_data.

On that page, it’s evident that the most common data (for OSS apps) is:

E0 00 08 00 00
E0 00 40 00 00

However, if you look at data from the official loaders (gathered using sysinternal’s portmon), it’s evident that this is not the only set of data, at least for EDU and Vex controllers.

Does anyone have any insights into this? Any additional data points? I have not had the opportunity to analyze data from loading the RC.

As far as I can tell, it’s basically a “row write” (think memset) command. In my implementation of AN851 0x09 is defined as IFI_WR_ROW.

It seems to write whatever number you specify to a fixed number of rows on the robot controller. Internally, it most likely erases the rows and then writes to them.

09 E0 00 08 00 00
In terms of the AN851 documentation, this would be


Where LEN is the number of rows (1 row = 64 bytes, same as in ER_FLASH) and VAL is what is to be written (0x00 in this case). So the above data represents:
Erase 0xE0 blocks (224 * 64 bytes = 0x3800 bytes total) starting at 0x000800 (to 0x004000) and write the value 0x00 to them. Then it does the same for the next 0xE0 blocks.

I have no idea why IFI implemented it, maybe they didn’t like that erasing flash sets all the bits instead of clearing them? :stuck_out_tongue:

EDIT: Looking at the other bot’s data, it’s a little weirder.
01 C0 7F 00 00 - set 0x007FC0 - 0x008000 to zero. This is the last row on a PIC18F8722’s flash mem, this may serve a special purpose on that RC.
01 00 00 20 00 - set 0x200000 - 0x200040 to zero. This would be the user ID registers of the PIC18F. See the data sheet.
01 00 00 30 00 - set 0x300000 - 0x300000 to zero. These are the configuration registers, which are write-protected on the FRC.
10 00 00 00 00 - set 0x000000 - 0x000800 to zero. this is the boot sector of the FRC, which is where AN851 resides and is also write protected on the FRC.

Seems a little odd to me, but it all makes sense in terms of the “official” Microchip protocol.