RCM 3700 Bootloader

Hi all,

I'm glad I found this group.

I have seen some related threads, but they don't quite answer my
questions exactly.

Does anyone know the bootloader protocol for rabbit 3700? We have
equipment that is in very hard to get places, so what we have is a
little PC board with a pic and a 4meg memory chip. This PC board
actually mounts directly onto the rabbit programing pins.

We want to be able to receive a new program via the lan / wireless /
serial port and simply write this bin file to the 4 mb chip. When a
certain command is received by the rabbit, it must 'turn' the pic on
which will then set smode, and basically do what the rabbit
programing cable does.

In theory, this shouldn't be too difficult as this seems to be just a
serial protocol, but I don't know what they are doing.

I know that I must load the coldboot.bin, and then pilot.bin, then my
program.bin, but I don't know the exact protocol to do that, ie, how
do I send it, what replies do I receive, etc.

Any pointers here would be greatly appreciated.

Please note that I do need to use the pic (or some low cost
processor). I cannot send this program directly from a PC as not all
rabbit based boards have a direct connection with the PC. Only the
main controller does (usually LAN), and it then controls a population
by RS485, or wireless modem. The PC software should be responsible
for sending new software to the controller boards, and it will then
pass it on to the population.

Hope this makes sense.

Thanks,

John Start a New Thread

It seems that you have two alternatives to resolve the problem:
1. Use a modified version of the serial download manager provided by SHDesigns (see http://www.shdesigns.org), adapted to your needs; this involves developing a built-in loader which will be kept in the flash memory for all the firmware versions you will use (I believe Scott Henion can help you better on this matter - and trust me, i have used his loader and it works really fine)
2. Load the .bin file directly to the Rabbit, like the RFU does; this means you have to use the internal loader protocol, which, unfortunately, is not published by ZWorld, but includes:
- load the coldload.bin file at 2400 bps
- load the pilot.bin file at 57600 bps
- load your binary file at 115200 bps
- use some specific checksums, like sum8 and fletcher16
- replace the control bytes (0x7E with 0x7D and 0x5E, 0x7D with 0x7D and 0x5D)
- chunk your binary file to 128 bytes per packet, put a header which includes the length of the packet, the address where you'll be writing, etc

For the second alternative, I can help you with an application (Visual C++).
Anyway, depending on your needs, you can use one of those two alternatives, or also you can purchase the RFU source code (Borland C++) and adapt it for your pic controller.

john_sam_mc wrote: Hi all,

I'm glad I found this group.

I have seen some related threads, but they don't quite answer my
questions exactly.

Does anyone know the bootloader protocol for rabbit 3700? We have
equipment that is in very hard to get places, so what we have is a
little PC board with a pic and a 4meg memory chip. This PC board
actually mounts directly onto the rabbit programing pins.

We want to be able to receive a new program via the lan / wireless /
serial port and simply write this bin file to the 4 mb chip. When a
certain command is received by the rabbit, it must 'turn' the pic on
which will then set smode, and basically do what the rabbit
programing cable does.

In theory, this shouldn't be too difficult as this seems to be just a
serial protocol, but I don't know what they are doing.

I know that I must load the coldboot.bin, and then pilot.bin, then my
program.bin, but I don't know the exact protocol to do that, ie, how
do I send it, what replies do I receive, etc.

Any pointers here would be greatly appreciated.

Please note that I do need to use the pic (or some low cost
processor). I cannot send this program directly from a PC as not all
rabbit based boards have a direct connection with the PC. Only the
main controller does (usually LAN), and it then controls a population
by RS485, or wireless modem. The PC software should be responsible
for sending new software to the controller boards, and it will then
pass it on to the population.

Hope this makes sense.

Thanks,

John

---------------------------------
Never miss a thing. Make Yahoo your homepage. Start a New Thread

Hi everyone that responded.

Thanks to all of you

Adrian Mojoatca:
I am trying option 2, to basically follow the protocol used by dynamic c / RFU. You mention that I can purchase the RFU source. Any idea where?
fairy_dave:
Thanks, that is kind of what we do at the moment, but we need to move away all together from physically being there. Besides the access problems, we also have distance problems. Some mines are 400km away (+- 150 miles I guess), and those are the near mines. We are also in discussions with international mines, so we do need a fully remote way of updating software.
Dave Moore:
Hi Dave, Adrian above mentions that you can purchase it, so hopefully he knows where. We actually do have a meeting with the guys from Rabbit this afternoon, so I'll ask them then about getting it from the horses mouth.
Regards,

and thanks again to everyone,

John

----- Original Message -----
From: Adrian Mojoatca
To: r...
Sent: Tuesday, March 11, 2008 5:43 PM
Subject: Re: [rabbit-semi] RCM 3700 Bootloader
It seems that you have two alternatives to resolve the problem:
1. Use a modified version of the serial download manager provided by SHDesigns (see http://www.shdesigns.org), adapted to your needs; this involves developing a built-in loader which will be kept in the flash memory for all the firmware versions you will use (I believe Scott Henion can help you better on this matter - and trust me, i have used his loader and it works really fine)
2. Load the .bin file directly to the Rabbit, like the RFU does; this means you have to use the internal loader protocol, which, unfortunately, is not published by ZWorld, but includes:
- load the coldload.bin file at 2400 bps
- load the pilot.bin file at 57600 bps
- load your binary file at 115200 bps
- use some specific checksums, like sum8 and fletcher16
- replace the control bytes (0x7E with 0x7D and 0x5E, 0x7D with 0x7D and 0x5D)
- chunk your binary file to 128 bytes per packet, put a header which includes the length of the packet, the address where you'll be writing, etc

For the second alternative, I can help you with an application (Visual C++).
Anyway, depending on your needs, you can use one of those two alternatives, or also you can purchase the RFU source code (Borland C++) and adapt it for your pic controller.

john_sam_mc wrote:

Hi all,

I'm glad I found this group.

I have seen some related threads, but they don't quite answer my
questions exactly.

Does anyone know the bootloader protocol for rabbit 3700? We have
equipment that is in very hard to get places, so what we have is a
little PC board with a pic and a 4meg memory chip. This PC board
actually mounts directly onto the rabbit programing pins.

We want to be able to receive a new program via the lan / wireless /
serial port and simply write this bin file to the 4 mb chip. When a
certain command is received by the rabbit, it must 'turn' the pic on
which will then set smode, and basically do what the rabbit
programing cable does.

In theory, this shouldn't be too difficult as this seems to be just a
serial protocol, but I don't know what they are doing.

I know that I must load the coldboot.bin, and then pilot.bin, then my
program.bin, but I don't know the exact protocol to do that, ie, how
do I send it, what replies do I receive, etc.

Any pointers here would be greatly appreciated.

Please note that I do need to use the pic (or some low cost
processor). I cannot send this program directly from a PC as not all
rabbit based boards have a direct connection with the PC. Only the
main controller does (usually LAN), and it then controls a population
by RS485, or wireless modem. The PC software should be responsible
for sending new software to the controller boards, and it will then
pass it on to the population.

Hope this makes sense.

Thanks,

John

------
Never miss a thing. Make Yahoo your homepage. Start a New Thread

Hi,

On more way to re-program is through cloning option in dynamic C .

Create a master board or unit with bin file with cloning enabled,

I had create one a master with its own power source (rechargeable
battery ).

If u already have your units on 485 network , u may look at shdesign's
serial loaders

Regards

Mrutyunjay .

________________________________

From: r... [mailto:r...]
On Behalf Of John Mc Murray
Sent: Thursday, March 13, 2008 14:28
To: r...
Subject: Re: [rabbit-semi] RCM 3700 Bootloader

Hi everyone that responded.

Thanks to all of you

Adrian Mojoatca :

I am trying option 2, to basically follow the protocol used by dynamic c
/ RFU. You mention that I can purchase the RFU source. Any idea where?

fairy_dave:

Thanks, that is kind of what we do at the moment, but we need to move
away all together from physically being there. Besides the access
problems, we also have distance problems. Some mines are 400km away (+-
150 miles I guess), and those are the near mines. We are also in
discussions with international mines, so we do need a fully remote way
of updating software.

Dave Moore:

Hi Dave, Adrian above mentions that you can purchase it, so hopefully he
knows where. We actually do have a meeting with the guys from Rabbit
this afternoon, so I'll ask them then about getting it from the horses
mouth.

Regards,

and thanks again to everyone,

John

----- Original Message -----

From: Adrian Mojoatca

To: r...


Sent: Tuesday, March 11, 2008 5:43 PM

Subject: Re: [rabbit-semi] RCM 3700 Bootloader

It seems that you have two alternatives to resolve the problem:
1. Use a modified version of the serial download manager
provided by SHDesigns (see http://www.shdesigns.org
), adapted to your needs; this involves
developing a built-in loader which will be kept in the flash memory for
all the firmware versions you will use (I believe Scott Henion can help
you better on this matter - and trust me, i have used his loader and it
works really fine)
2. Load the .bin file directly to the Rabbit, like the RFU does;
this means you have to use the internal loader protocol, which,
unfortunately, is not published by ZWorld, but includes:
- load the coldload.bin file at 2400 bps
- load the pilot.bin file at 57600 bps
- load your binary file at 115200 bps
- use some specific checksums, like sum8 and fletcher16
- replace the control bytes (0x7E with 0x7D and 0x5E, 0x7D
with 0x7D and 0x5D)
- chunk your binary file to 128 bytes per packet, put a
header which includes the length of the packet, the address where you'll
be writing, etc

For the second alternative, I can help you with an application
(Visual C++).
Anyway, depending on your needs, you can use one of those two
alternatives, or also you can purchase the RFU source code (Borland C++)
and adapt it for your pic controller.

john_sam_mc wrote:

Hi all,

I'm glad I found this group.

I have seen some related threads, but they don't quite
answer my
questions exactly.

Does anyone know the bootloader protocol for rabbit
3700? We have
equipment that is in very hard to get places, so what we
have is a
little PC board with a pic and a 4meg memory chip. This
PC board
actually mounts directly onto the rabbit programing
pins.

We want to be able to receive a new program via the lan
/ wireless /
serial port and simply write this bin file to the 4 mb
chip. When a
certain command is received by the rabbit, it must
'turn' the pic on
which will then set smode, and basically do what the
rabbit
programing cable does.

In theory, this shouldn't be too difficult as this seems
to be just a
serial protocol, but I don't know what they are doing.

I know that I must load the coldboot.bin, and then
pilot.bin, then my
program.bin, but I don't know the exact protocol to do
that, ie, how
do I send it, what replies do I receive, etc.

Any pointers here would be greatly appreciated.

Please note that I do need to use the pic (or some low
cost
processor). I cannot send this program directly from a
PC as not all
rabbit based boards have a direct connection with the
PC. Only the
main controller does (usually LAN), and it then controls
a population
by RS485, or wireless modem. The PC software should be
responsible
for sending new software to the controller boards, and
it will then
pass it on to the population.

Hope this makes sense.

Thanks,

John

________________________________
Never miss a thing. Make Yahoo your homepage.
Start a New Thread

Hi John,

RFU source codes:

http://www.rabbit.com/products/dc/index.shtml
Good luck!

John Mc Murray wrote:
Hi everyone that responded.

Thanks to all of you

Adrian Mojoatca:
I am trying option 2, to basically follow the protocol used by dynamic c / RFU. You mention that I can purchase the RFU source. Any idea where?

fairy_dave:
Thanks, that is kind of what we do at the moment, but we need to move away all together from physically being there. Besides the access problems, we also have distance problems. Some mines are 400km away (+- 150 miles I guess), and those are the near mines. We are also in discussions with international mines, so we do need a fully remote way of updating software.

Dave Moore:
Hi Dave, Adrian above mentions that you can purchase it, so hopefully he knows where. We actually do have a meeting with the guys from Rabbit this afternoon, so I'll ask them then about getting it from the horses mouth.

Regards,

and thanks again to everyone,

John

----- Original Message -----
From: Adrian Mojoatca
To: r...
Sent: Tuesday, March 11, 2008 5:43 PM
Subject: Re: [rabbit-semi] RCM 3700 Bootloader

It seems that you have two alternatives to resolve the problem:
1. Use a modified version of the serial download manager provided by SHDesigns (see http://www.shdesigns.org), adapted to your needs; this involves developing a built-in loader which will be kept in the flash memory for all the firmware versions you will use (I believe Scott Henion can help you better on this matter - and trust me, i have used his loader and it works really fine)
2. Load the .bin file directly to the Rabbit, like the RFU does; this means you have to use the internal loader protocol, which, unfortunately, is not published by ZWorld, but includes:
- load the coldload.bin file at 2400 bps
- load the pilot.bin file at 57600 bps
- load your binary file at 115200 bps
- use some specific checksums, like sum8 and fletcher16
- replace the control bytes (0x7E with 0x7D and 0x5E, 0x7D with 0x7D and 0x5D)
- chunk your binary file to 128 bytes per packet, put a header which includes the length of the packet, the address where you'll be writing, etc

For the second alternative, I can help you with an application (Visual C++).
Anyway, depending on your needs, you can use one of those two alternatives, or also you can purchase the RFU source code (Borland C++) and adapt it for your pic controller.

john_sam_mc wrote:
Hi all,

I'm glad I found this group.

I have seen some related threads, but they don't quite answer my
questions exactly.

Does anyone know the bootloader protocol for rabbit 3700? We have
equipment that is in very hard to get places, so what we have is a
little PC board with a pic and a 4meg memory chip. This PC board
actually mounts directly onto the rabbit programing pins.

We want to be able to receive a new program via the lan / wireless /
serial port and simply write this bin file to the 4 mb chip. When a
certain command is received by the rabbit, it must 'turn' the pic on
which will then set smode, and basically do what the rabbit
programing cable does.

In theory, this shouldn't be too difficult as this seems to be just a
serial protocol, but I don't know what they are doing.

I know that I must load the coldboot.bin, and then pilot.bin, then my
program.bin, but I don't know the exact protocol to do that, ie, how
do I send it, what replies do I receive, etc.

Any pointers here would be greatly appreciated.

Please note that I do need to use the pic (or some low cost
processor). I cannot send this program directly from a PC as not all
rabbit based boards have a direct connection with the PC. Only the
main controller does (usually LAN), and it then controls a population
by RS485, or wireless modem. The PC software should be responsible
for sending new software to the controller boards, and it will then
pass it on to the population.

Hope this makes sense.

Thanks,

John

---------------------------------
Never miss a thing. Make Yahoo your homepage.

---------------------------------
Never miss a thing. Make Yahoo your homepage. Start a New Thread