I'm still unable to program an RCM6700 using the GUI RFU on a PC that
doesn't have Dynamic C 10.xx installed. So I moved on to the
Commandline RFU, which is actually more important since that is what
our production line uses to program rabbits. And it too doesn't work.
As we do with the RCM3000 series, we put the following files in a
local directory:
coldload.bin
pilot.bin
flash.ini
clrfu.exe
myapp.bin
Then at the cmd window prompt enter the following command:
clrfu myapp.bin -s 1:115200 -cl .\coldload.bin -pb .\pilot.bin -v -vp-
Then it gives error message: Unable to open cold loader file.
It seems like the clrfu is looking for files in places other than what
I specified on the command line.
Is there something new about the clRFU that comes with DC 10.xx? As
usual I can't find any documentation on the digi website.
Especially since there is more than one pilot.bin and coldload.bin
file in the DC 10.xx installation.
Steve
Commandline RFU
Started by ●July 20, 2011
Reply by ●July 21, 20112011-07-21
Hi Steve,
What has always worked for me for making stand-alone RFU "installations" from DC 10 and earlier versions is to create a hierarchical ZIP archive containing the following files in the same relative positions as in the original DC installation:
<top level DC installation>
flash.ini
Bios <subfolder>
<all .BIN files from the Bios subfolder, varies by DC version>
Utilities <subfolder>
clrfu.exe
rfu.exe
rfu.ico
rabfield.cnt <optional, help file>
rabfield.hlp <optional, help file>
roboex32.dll <optional, help file>
After unzipping the stand-alone RFU "installation" archive somewhere on the destination PC, start up rfu.exe and then confirm that the file locations are correct via the "Setup > File Locations..." menu item. If this is the case, then clrfu.exe should work as well, without requiring any custom file location specifications.
If the RFU's file locations are not correct for some reason, the quickest way to update them is to quit the RFU, then start up regedit.exe and rename (or delete, depending on your confidence level) the entire RFU-related Windows' registry key. For example, Windows' registry key associated with DC 10.66's RFU version is: "HKEY_CURRENT_USER\Software\ZWorld\RFU\4.62" and you could rename the 4.62 key to e.g. 4.62_old. When the RFU is restarted, a new registry key will be created with pathlists relative to rfu.exe.
Hope this helps,
Bruce
What has always worked for me for making stand-alone RFU "installations" from DC 10 and earlier versions is to create a hierarchical ZIP archive containing the following files in the same relative positions as in the original DC installation:
<top level DC installation>
flash.ini
Bios <subfolder>
<all .BIN files from the Bios subfolder, varies by DC version>
Utilities <subfolder>
clrfu.exe
rfu.exe
rfu.ico
rabfield.cnt <optional, help file>
rabfield.hlp <optional, help file>
roboex32.dll <optional, help file>
After unzipping the stand-alone RFU "installation" archive somewhere on the destination PC, start up rfu.exe and then confirm that the file locations are correct via the "Setup > File Locations..." menu item. If this is the case, then clrfu.exe should work as well, without requiring any custom file location specifications.
If the RFU's file locations are not correct for some reason, the quickest way to update them is to quit the RFU, then start up regedit.exe and rename (or delete, depending on your confidence level) the entire RFU-related Windows' registry key. For example, Windows' registry key associated with DC 10.66's RFU version is: "HKEY_CURRENT_USER\Software\ZWorld\RFU\4.62" and you could rename the 4.62 key to e.g. 4.62_old. When the RFU is restarted, a new registry key will be created with pathlists relative to rfu.exe.
Hope this helps,
Bruce
Reply by ●July 22, 20112011-07-22
Bruce,
I tried your suggestion and it did make a difference. I still can't
program my module, but it does operate differently.
The error about not being able to open cold loader file went away.
I must say that it bothers me that the clrfu commandline arguments
specifying where to find the coldloader.bin and pilot.bin files are
absolutely ignored.
What happens now is this for the commandline rfu:
Sending Coldloader
363 of 254129 bytes sent
Sending Pilot BIOS
3887 of 254129 bytes sent
Elapsed Time: 9.578 seconds
It never sends my bin file. And there are no error messages. Does it
matter that the size of pilot.bin is not 3887 bytes? It should be
3852. The coldloader.bin size is correct.
Also, doesn't 9.5 seconds seem like a long time to download 4.2k
bytes at 115k baud?
If I use the gui RFU, it too fails, but with error message -
downloading image failed.
I've tried this on two different PCs with the same results.
Steve
I tried your suggestion and it did make a difference. I still can't
program my module, but it does operate differently.
The error about not being able to open cold loader file went away.
I must say that it bothers me that the clrfu commandline arguments
specifying where to find the coldloader.bin and pilot.bin files are
absolutely ignored.
What happens now is this for the commandline rfu:
Sending Coldloader
363 of 254129 bytes sent
Sending Pilot BIOS
3887 of 254129 bytes sent
Elapsed Time: 9.578 seconds
It never sends my bin file. And there are no error messages. Does it
matter that the size of pilot.bin is not 3887 bytes? It should be
3852. The coldloader.bin size is correct.
Also, doesn't 9.5 seconds seem like a long time to download 4.2k
bytes at 115k baud?
If I use the gui RFU, it too fails, but with error message -
downloading image failed.
I've tried this on two different PCs with the same results.
Steve
Reply by ●July 27, 20112011-07-27
I'm still not able to program an RCM6700 with RFU or clRFU from a PC
that doesn't have Dynamic C v10.66 installed on it.
Rabbit Tech Support is now telling me that I need to install FTDI
serial drivers on the PCs. This, after they originally told me there
is nothing that needs to be installed for the RFUs to work.
I'm not using USB or USB-to-serial adapters for programming. I'm
using a standard RS232 port on the PC connected directly to the
Rabbit module through a NULL modem serial cable (with the relevant
level shifters). Does it make sense that I would need to install a
special serial driver to use the serial port? Windows XP doesn't
provide a serial driver? None of the RFUs that came with DC v7.xx,
8.xx, or 9.xx, needed a special serial driver to work.
But Tech Support will hear none of it. They close my support
requests as soon as I open them with the same response.
Steve
that doesn't have Dynamic C v10.66 installed on it.
Rabbit Tech Support is now telling me that I need to install FTDI
serial drivers on the PCs. This, after they originally told me there
is nothing that needs to be installed for the RFUs to work.
I'm not using USB or USB-to-serial adapters for programming. I'm
using a standard RS232 port on the PC connected directly to the
Rabbit module through a NULL modem serial cable (with the relevant
level shifters). Does it make sense that I would need to install a
special serial driver to use the serial port? Windows XP doesn't
provide a serial driver? None of the RFUs that came with DC v7.xx,
8.xx, or 9.xx, needed a special serial driver to work.
But Tech Support will hear none of it. They close my support
requests as soon as I open them with the same response.
Steve
Reply by ●July 27, 20112011-07-27
If it is a laptop, then the FTDI drivers may be needed. The only serial
ports
that you can guarantee are not USB these days are plug-in PCI cards.
Still if you can use the ports for other things, then you should not need a
driver.
The FTDI drivers do allow you to set the latency that does make DC and ST work
better.The stock Windows drivers don't.
Since you are using your own programming hardware, I'd expect them to offer
little support.
that you can guarantee are not USB these days are plug-in PCI cards.
Still if you can use the ports for other things, then you should not need a
driver.
The FTDI drivers do allow you to set the latency that does make DC and ST work
better.The stock Windows drivers don't.
Since you are using your own programming hardware, I'd expect them to offer
little support.
Reply by ●July 27, 20112011-07-27
Not a laptop.
I'm not sure what "hardware" you're referring too. The RCM6700 is
their hardware. The RFUs are their hardware. Do you mean the serial
cable from the PC to the RCM6700? The same serial cable used on all
Rabbit modules we've ever purchased? The cable that works fine when
the PC has DC v10.66 installed?
FYI, after installing the FTDI USB driver on a desktop PC (FTDI
doesn't have just a serial driver), the RFU still doesn't work.
Exactly as I thought would happen. If no USB is used, there is no
need to use a USB driver!
We are having a meeting later today, and I fully expect that we will
decide to drop the RCM6700 and stop using any Rabbit processors
beyond the R3000. We're already working on a PIC32 design to replace
the rabbit.
Steve
I'm not sure what "hardware" you're referring too. The RCM6700 is
their hardware. The RFUs are their hardware. Do you mean the serial
cable from the PC to the RCM6700? The same serial cable used on all
Rabbit modules we've ever purchased? The cable that works fine when
the PC has DC v10.66 installed?
FYI, after installing the FTDI USB driver on a desktop PC (FTDI
doesn't have just a serial driver), the RFU still doesn't work.
Exactly as I thought would happen. If no USB is used, there is no
need to use a USB driver!
We are having a meeting later today, and I fully expect that we will
decide to drop the RCM6700 and stop using any Rabbit processors
beyond the R3000. We're already working on a PIC32 design to replace
the rabbit.
Steve
Reply by ●July 27, 20112011-07-27
> Not a laptop.
>
> I'm not sure what "hardware" you're referring too. The RCM6700 is
> their hardware. The RFUs are their hardware. Do you mean the serial
> cable from the PC to the RCM6700? The same serial cable used on all
> Rabbit modules we've ever purchased? The cable that works fine when
> the PC has DC v10.66 installed?
You mentioned a "NULL modem serial cable (with the relevant level shifters)".
Their cable does not require a null modem cable or level shifters. Why not call
it their programming cable?
>
> FYI, after installing the FTDI USB driver on a desktop PC (FTDI
> doesn't have just a serial driver), the RFU still doesn't work.
> Exactly as I thought would happen. If no USB is used, there is no
> need to use a USB driver!
Yes, but installing the driver may get you past the next step in dealing with
their support idiots.
>
> We are having a meeting later today, and I fully expect that we will
> decide to drop the RCM6700 and stop using any Rabbit processors
> beyond the R3000. We're already working on a PIC32 design to replace
> the rabbit.
Yes, have long dropped the idea of any rabbit stuff beyond the 3k. Just not
worth the hassles. The documentation is now more a sales brochure than any real
info.
The PIC32 stuff looks great. Looking at one, 512k flash, 100MIPS, 6 serial
ports, SPI, I2C, 10/100 ethernet all for about $15 in parts.
Been using the PIC16 stuff for a long time with ASM code. The PIC32 looks good
but would need a C compiler. Can't justify dev tool cost right now (compiler is
$900.) Would also need to test their TCP/IP stack.
I have also used the Netburner stuff with good results.
>
> I'm not sure what "hardware" you're referring too. The RCM6700 is
> their hardware. The RFUs are their hardware. Do you mean the serial
> cable from the PC to the RCM6700? The same serial cable used on all
> Rabbit modules we've ever purchased? The cable that works fine when
> the PC has DC v10.66 installed?
You mentioned a "NULL modem serial cable (with the relevant level shifters)".
Their cable does not require a null modem cable or level shifters. Why not call
it their programming cable?
>
> FYI, after installing the FTDI USB driver on a desktop PC (FTDI
> doesn't have just a serial driver), the RFU still doesn't work.
> Exactly as I thought would happen. If no USB is used, there is no
> need to use a USB driver!
Yes, but installing the driver may get you past the next step in dealing with
their support idiots.
>
> We are having a meeting later today, and I fully expect that we will
> decide to drop the RCM6700 and stop using any Rabbit processors
> beyond the R3000. We're already working on a PIC32 design to replace
> the rabbit.
Yes, have long dropped the idea of any rabbit stuff beyond the 3k. Just not
worth the hassles. The documentation is now more a sales brochure than any real
info.
The PIC32 stuff looks great. Looking at one, 512k flash, 100MIPS, 6 serial
ports, SPI, I2C, 10/100 ethernet all for about $15 in parts.
Been using the PIC16 stuff for a long time with ASM code. The PIC32 looks good
but would need a C compiler. Can't justify dev tool cost right now (compiler is
$900.) Would also need to test their TCP/IP stack.
I have also used the Netburner stuff with good results.
Reply by ●July 27, 20112011-07-27
Hi Steve,
I sent directly to you a tested-working stand-alone RFU ZIP archive, extracted from DC 10.66. I didn't want to post it here, because it won't necessarily work for future Rabbit boards.
The coldloader and pilot BIOS file sizes you report are not what I'd expect for the serial boot flash versions included in DC 10.66, but I can tell you that the number of bytes sent by the RFU is cumulative.
That is, if the cold loader is 363 bytes per below, then the pilot BIOS size would be 3887-363524 bytes. I suggest not specifying the cold loader and pilot files, at least to start with. If you do specify these files, the RCM67xx family requires the serial flash versions, i.e. coldloadserflash.bin and pilotserflash.bin.
So far as the time do download 3887 bytes is concerned, the cold loader is tripleted in at 2400 bps using Rabbit's cold boot method. Then the pilot BIOS is loaded at 57600 bps. After that, if it had progressed further, a higher bps rate may be used to load the application code. There are also some small delays inserted after loading each piece of code to give Rabbit time to actually get the newly loaded code up and running. I presume the 9.5 seconds you mention includes the couple seconds it takes for the RFU's target communication to give up on a non-responsive target.
To get more detail, with the RFU closed, via regedit.exe you can enable the DC 10.66 version's RFU target communication logging in "HKEY_CURRENT_USER\Software\ZWorld\RFU\4.62\Communications." For test purposes, you will want to ensure that both "Enable TC Logging" and "Log Verbose" have values modified to 1. To disable the RFU's TC logging, restore "Enable TC Logging" to its original 0 value. None of the other TC logging items' values are used when TC logging is disabled.
After enabling TC logging, the log will be in a tcout.txt file in the RFU's current working directory. The cwd will likely be either the folder where rfu.exe is found or the folder where the .BIN file is found.
- Bruce
I sent directly to you a tested-working stand-alone RFU ZIP archive, extracted from DC 10.66. I didn't want to post it here, because it won't necessarily work for future Rabbit boards.
The coldloader and pilot BIOS file sizes you report are not what I'd expect for the serial boot flash versions included in DC 10.66, but I can tell you that the number of bytes sent by the RFU is cumulative.
That is, if the cold loader is 363 bytes per below, then the pilot BIOS size would be 3887-363524 bytes. I suggest not specifying the cold loader and pilot files, at least to start with. If you do specify these files, the RCM67xx family requires the serial flash versions, i.e. coldloadserflash.bin and pilotserflash.bin.
So far as the time do download 3887 bytes is concerned, the cold loader is tripleted in at 2400 bps using Rabbit's cold boot method. Then the pilot BIOS is loaded at 57600 bps. After that, if it had progressed further, a higher bps rate may be used to load the application code. There are also some small delays inserted after loading each piece of code to give Rabbit time to actually get the newly loaded code up and running. I presume the 9.5 seconds you mention includes the couple seconds it takes for the RFU's target communication to give up on a non-responsive target.
To get more detail, with the RFU closed, via regedit.exe you can enable the DC 10.66 version's RFU target communication logging in "HKEY_CURRENT_USER\Software\ZWorld\RFU\4.62\Communications." For test purposes, you will want to ensure that both "Enable TC Logging" and "Log Verbose" have values modified to 1. To disable the RFU's TC logging, restore "Enable TC Logging" to its original 0 value. None of the other TC logging items' values are used when TC logging is disabled.
After enabling TC logging, the log will be in a tcout.txt file in the RFU's current working directory. The cwd will likely be either the folder where rfu.exe is found or the folder where the .BIN file is found.
- Bruce
