The BL4S200 is based on the RCM4310, a module with serial flash and support for RemoteProgramUpdate. I would advise developing an update process using the “power-fail safe” version of RPU, possibly using a protocol like XMODEM over the serial port. The power-fail safe version stores two copies of firmware (images A and B) so they device can always boot (if booting from A, updates stored as image B; once validated, module will boot from image B).

If you did that, the device could still boot after a failed update. I believe you’d even have the option to flag the previous image as the one to boot from if you wanted to revert.

I wouldn’t recommend any technique that requires extracting the current firmware from the device as a method of reverting to old code. If a user wants to revert, they can download an older revision from your support website.

-Tom
> On Mar 20, 2017, at 10:58 AM, y...@omniverter.com [rabbit-semi] > wrote:
>
> I appreciate your answer. However, I don't have TCP/IP ready. I only use serial port. My idea is to update old firmware from controller to PC and then download the new firmware from PC to controller. If user or programmer would like to roll back old version, they only need download old version to controller again.
> Start a New Thread

Hello, Tom:

I appreciate your answer. However, I don't have TCP/IP ready. I only use serial port. My idea is to update old firmware from controller to PC and then download the new firmware from PC to controller. If user or programmer would like to roll back old version, they only need download old version to controller again.

Thank you for your answer again. Start a New Thread

Take a look at Samples/tcpip/http/download_flash.c from the 10.72B release, or you can pull it from the GitHub repository:

https://github.com/digidotcom/DCRabbit_10/blob/master/Samples/tcpip/http/download_flash.c

It provides a way to download a binary image of the entire boot flash as a file called “boot.bin”.

I had planned to write some command-line Windows programs for public release that would work with that downloaded boot.bin file, reporting on the firmware_info_t embedded in the BIOS, and splitting the file out into separate pieces (firmware image(s), UserBlock, SystemIDBlock, embedded file system).

Of course, other priorities arose and I never got around to it, so you’ll need to make use of another sample (Samples/RemoteProgramUpdate/firmware_report.c) to determine the size of the firmware, and then truncate the boot.bin file you download via that first sample.

If you’ve used Remote Program Update on that hardware, there’s a chance the boot.bin starts with a 1K bootloader followed by two firmware images, making it somewhat more complicated to extract a .bin. If you have trouble with this step, you can email me the .bin file and I’ll extract the firmware binary for you.

Note that for both of these programs you want to “Compile to RAM” so you don’t alter the contents of the boot flash.

-Tom
> On Mar 20, 2017, at 7:56 AM, y...@omniverter.com [rabbit-semi] wrote:
>
> I am using BL4S200. I have some old version program stored in the flash memory. I check DC10.72. It looks DC10.72 only can down load combined code to controller. Is it possible to upload the code from controller to PC? Start a New Thread

Hello,

I am using BL4S200. I have some old version program stored in the flash memory. I check DC10.72. It looks DC10.72 only can down load combined code to controller. Is it possible to upload the code from controller to PC?

Thank you for your help Start a New Thread