Flash Image...

Is there a way to create just a binary flash image and download it to the Rabbit without using Dynamic C?

I need to send binary updates to my customer, and I sure don’t want to send them the source code and a copy of Dynamic C!

Rabbit field utility, installs with DC as far as I am aware :slight_smile:
But this way you’ll still need to supply your client with a programming cable, and he’ll have to plug it directly into your rabbit.
Otherwise you can use a serial/TCP IP bootloader. But since you didn’t do that, that is not an option anymore. (Code needs to reside on your processor already)

I’m interested in the possibility of field upgrade of Rabbit firmware BIN files.

Typically in our lab we’d use the RFU utility, and connect the serial PROG cable to the programming port of the Rabbit circuit, and load a new BIN file.

My Rabbit module is the RCM4400W, which has a WiFi port but no cabled LAN port. When a firmware update is needed, I want to avoid having the customer opening my enclosure containing the Rabbit. We don’t want to use the Rabbit serial programming cable or RFU. I want to load a BIN file using some other means. I figured one possibility was to go through the network port (in this case, the WiFi port).

kobuseng, you mentioned a serial/TCP-IP bootloader? Is there a Rabbit example of how to do this? I have not found such an example, nor a mention of it in the documentation.

I also welcome a response from Rabbit tech support.

Hello cpu

We used a software module from SHDesigns. Here is the link.

The ethernet download manager should work for you, I used the serial download manager. Unfortunately it is not free, but not that expensive.

You could always write your own network download manager if youve got the time. At the time I don’t think Rabbit semiconductors has got an in-house download manager, though I could be wrong.

Hope this helps.

As another take on the “boot loader” idea, I’m looking at a truncated version of my main application that runs out of Flash and reads a BIN file from a FAT partition on serial flash (of a RCM3315).

“All I need to do” is get the BIN file loaded into program RAM, and longjump to it. The main BIN would be linked for “Load to Flash, Run from RAM”.

Can you point me to a reference that tells how that works?


lslarry86, unfortunately I haven’t tried something like that before. Why do you want to do that, is the program memory too small on the rabbit?
Perhaps someone else has experience with this.

I have a fairly large application, but it’s not bigger than program size. Remote firmware update was added as a requirement recently, i.e. right before delivery. The application has configuration files on serial flash FAT partition that specify the IP, netmask, and other important parameters.

Reading through the various network update schemes, it seems like most of them require dual Flash chips. Since I’m working with an RCM 3315, I don’t have that. But I have a FAT partition that’s more than big enough to hold the DynamicC BIN file of my main application.

So, I’m exploring the possibility of using a stripped down version of my main application, compiled to run out of Flash, as a boot loader. If it finds a good BIN file in the FAT partition, it should somehow load that BIN file into program SRAM and jump to it, as if the BIN file had been written to Flash by RFU. If there is no BIN file, or it’s bad, or maybe if it hangs up and causes a watchdog reset, the Flash-only application keeps control. It has enough network smarts to alert someone of the failure and wait for a new load, but doesn’t have any of the main application’s “business logic” which is the most likely candidate for update.

It seems like that would be a reasonable design based on what I’ve read about the Rabbit architecture so far, but I can’t find the background docs on how BIN files, linked to run from RAM, are loaded there at boot time.


Yes I remember seeing some application notes referring to needing two flash chips for bootloading capabilities.

I remember something about SHDesigns serial bootloader not having that limitation. See if they will provide you with the documentation for their TCP/IP bootloader and if it will do the job. I believe this approach will be much quicker for your needs, since your program still “fits” on the device.

But I could be mistaken and thinking about another micro?

Are you running an RTOS?


I’ll take another look at SHDesigns, but I like my idea for other reasons.