Recovering code from the RC

[Orborde]

For some reason, between the end of last season and now we have managed to lose track of all the source code, hex files, etc. for the software that currently lives in our (2004) robot controller. This wouldn't be a problem except that we want to use said controller to test new ideas with, and the code in it is somewhat specialized (though not TOO different from the default code) and would be annoying to rewrite. So, is there any way to back up the old code off the controller as, say, a HEX file so it can be put back on later if we want?

[Mike Betts]

Sorry, I do not believe that an upload is possible.

[Dave Flowerday]

Originally Posted by Orborde

So, is there any way to back up the old code off the controller as, say, a HEX file so it can be put back on later if we want?

Try getting in touch with rwaliany or jdong on this board. They've written a loader that talks to the RC for Linux. The command set that the loader uses supports a way to read the FLASH as well, so there's some chance that they could modify their code a little bit so that it would dump out the contents of the FLASH instead of uploading to it.

[Mike Betts]

Given that it has been years since I have attempted it, reverse assembly is a pain... You do not have the variable names or constants to reference...

[Rickertsen2]

I don't think this will help you, but i'm posting it anyway. I know a way to do it, but it requires voiding your warranty as well as a PIC programmer and a bit of know how. If you are willing to be daring and have access to a PIC programmer, then crack open the RC and you will see some pinheaders. One will be labeled somethign like "user" (i don't remember the exact text). This is an ICSP port for the user processor. I'm not sure the order of the pins but it wouldn't be that hard to figure out with an ohmeter and the ICSP spec from the microchip website.

[Dave Flowerday]

Originally Posted by Mike Betts

Given that it has been years since I have attempted it, reverse assembly is a pain... You do not have the variable names or constants to reference...

Agreed, but I think the original poster is just looking for a way to save the binary image in the controller so they can restore it later if they want to put their 2004 robot back together again (judging by the request to save it to a .hex file).

[Tom Bottiglieri]

I think the overall answer to your question is no, and the time you would spend trying to get it to work would be more than that required to rewrite the code.

Although.. this seems like a neat project for any willing able minded programmers!

[Ian W.]

Originally Posted by Rickertsen2

I don't think this will help you, but i'm posting it anyway. I know a way to do it, but it requires voiding your warranty as well as a PIC programmer and a bit of know how. If you are willing to be daring and have access to a PIC programmer, then crack open the RC and you will see some pinheaders. One will be labeled somethign like "user" (i don't remember the exact text). This is an ICSP port for the user processor. I'm not sure the order of the pins but it wouldn't be that hard to figure out with an ohmeter and the ICSP spec from the microchip website.

Before you go and crack it open, give IFI a call, perhaps there's a way to interface the PIC directly with something on the outside of the RC. Don't tell them you're cracking it open though, if they don't answer .

As for retrieving the code in general, you're probably better off just rewriting it, and using the experience two ways. One, teach new programmers how it all works (because it is quite a bit different from writing a generic win32 program), and two, figure out how to use some sort of more robust storage solution, be it backing up your code in several places or something like CVS.

[Rickertsen2]

Originally Posted by Ian W.

Before you go and crack it open, give IFI a call, perhaps there's a way to interface the PIC directly with something on the outside of the RC. Don't tell them you're cracking it open though, if they don't answer .

As for retrieving the code in general, you're probably better off just rewriting it, and using the experience two ways. One, teach new programmers how it all works (because it is quite a bit different from writing a generic win32 program), and two, figure out how to use some sort of more robust storage solution, be it backing up your code in several places or something like CVS.

I started to think about this and got excited. Then realized it is not possible to access the necessary 4 pins from the outside. You can only access 3 out of 4 of them from the outside SO CLOSE!!!
Just for the info the 3 are as follow:
GND- any ground anywhere on the RC will do
PGC(program clock)(RB6)- Digital I/O 5
PGD(Program data)(RB7)-Digital I/O 6
MCLR(master clear/reset)- No hope of accesing this from the outside

[Orborde]

Thanks very much for your help and extremely rapid response, folks. Since there doesn't seem to be an off-the-shelf solution, I'll just overwrite whatever's on there and reconstruct it later from notes, I guess. No warranty-voiding for me. I suppose I'll pm these fellows rwaliany and jdong, and if they've got something clever by tomorrow afternoon, I'll try it. I was planning tomorrow to have a software team meeting and go over compiling and downloading code to the controller, and I'll just overwrite the old code.

Agreed, but I think the original poster is just looking for a way to save the binary image in the controller so they can restore it later if they want to put their 2004 robot back together again

Exactly. Though reverse assembly would be quite impressive and even more useful, I just want to maintain the current functionality without having to recreate it from scratch.

Thanks again.

[Venkatesh]

As an academic challenge, this would be incredibly fun, to force code from an on-core flash/nonvolatile space.

As far as I know, the User processor (PIC) stores its code in an onboard flash region. Since this flash region is not separate from the PIC, it would be incredibly difficult for one to read data from that flash/nonvolatile space. Also since the bus between the nonvolative region and the CPU Core would be inside the IC, it would become even more difficult.

The only possibility I see is:

1) Connect the I/O pins of the PIC to an independent flash/nonvolatile region
2) Then overwrite only a tiny portion of the existing code, which a JMP to code in the external flash
3) Then have the PIC's reset vector targetted at the JMP in the main flash space.
4) The code on the auxiliary flash space should be able to direct the PIC to read code from the main flash space (or read the exact contents of memory, more accurately).
5) The code on the aux. flash should then direct the PIC to forward the recovered data via Serial/other to a PC/other.

This procedure is very difficult to accomplish, since it depends on partial-erase of a flashchip attached directly to a CPU. Also it depends on the CPU being able to execute code directly out of an external region and map that external region as part of the main memory space.

Manufacturers spend time defending chips against code hijacking, so Microchip might be able to help... Other than that, good luck.

And btw, I am interested in the details of the read technique you detail, Rickertsen2. Please enlighen me. Thanks

And good luck with the controller.

[Rickertsen2]

Originally Posted by Venkatesh

As an academic challenge, this would be incredibly fun, to force code from an on-core flash/nonvolatile space.

As far as I know, the User processor (PIC) stores its code in an onboard flash region. Since this flash region is not separate from the PIC, it would be incredibly difficult for one to read data from that flash/nonvolatile space. Also since the bus between the nonvolative region and the CPU Core would be inside the IC, it would become even more difficult.

The only possibility I see is:

1) Connect the I/O pins of the PIC to an independent flash/nonvolatile region
2) Then overwrite only a tiny portion of the existing code, which a JMP to code in the external flash
3) Then have the PIC's reset vector targetted at the JMP in the main flash space.
4) The code on the auxiliary flash space should be able to direct the PIC to read code from the main flash space (or read the exact contents of memory, more accurately).
5) The code on the aux. flash should then direct the PIC to forward the recovered data via Serial/other to a PC/other.

This procedure is very difficult to accomplish, since it depends on partial-erase of a flashchip attached directly to a CPU. Also it depends on the CPU being able to execute code directly out of an external region and map that external region as part of the main memory space.

Manufacturers spend time defending chips against code hijacking, so Microchip might be able to help... Other than that, good luck.

And btw, I am interested in the details of the read technique you detail, Rickertsen2. Please enlighen me. Thanks

And good luck with the controller.

Grrr!!! I just spent quite a bit of time typing a long detailed explanation of how the method you mentioned could work, and how my method works, but it was lost due to a bug in the forum software that occurs when you try to post something and are not logged in.

Since i really don't feel like rewriting everything, here is the cliff's notes version

*the pic does have support for external memory up to 2Mb and has external pins that connect to the memory bus. thye are multiplexed with some other things and must be configured as memory bus pins.
*the pic can execute code from ecternal memory and can even boot from it
*read sections 6 and 4.1 of the datasheet for more info on external memory
*the problem lies in configuring the pic to boot off of external memory. this requires changing a few bits in the configuration section of the onboard FLASH. In order to write to flash, it must first be erased. I'm not sure whether or not ICSP supports selectively erasing little bits of the FLASH at a time. I know it supports killing the entire thing at once but i doubt you can erase little bits at a time. This would pose a huge security risk as it would allow you te reset the code protect bit as well. keep reading if you don't know what the code protect bit is.


*pics are usually programmed through a synchronous serial interface microchip calls ICSP (in circuit serial programming)
*details on ICSP and the 18f8520 are at: http://ww1.microchip.com/downloads/e...Doc/39583b.pdf
*ICSP has facilities for reading back the data from the onboard FLASH. This is usually done after programming the chip to verify that everything was written correctly, but it can be done at any time. You can do this with any PIC programmer.
*there is a bit in the configuration section of the flash that prevents you from being able to read back the contents of the FLASH. It is called the "code protect bit"
*I'm pretty sure the code protect bit isn't set in our case. There is a setting the in MPLAB project setting that toggles it. Its not set in the default code project, but it could always be overided by IFILoader before the .hex file is uploaded, although i doubt this. There is no point in protecting us from our own code.

I think a really interesting project would be to add a 2mb FLASH chip to the RC. Think of what you could do with that much program space!

[Matt Krass]

Originally Posted by Rickertsen2

I think a really interesting project would be to add a 2mb FLASH chip to the RC. Think of what you could do with that much program space!

Sorry if this was said already in the above jumble of pin designations, but are the necessary pins needed to tag memory on accessible without cracking open the RC? Would it be FIRST legal to use this in a competition? The possiblities...

[Rickertsen2]

Originally Posted by Matt Krass

Sorry if this was said already in the above jumble of pin designations, but are the necessary pins needed to tag memory on accessible without cracking open the RC? Would it be FIRST legal to use this in a competition? The possiblities...

Unfortunately they are not

[Astronouth7303]

Originally Posted by Rickertsen2

I started to think about this and got excited. Then realized it is not possible to access the necessary 4 pins from the outside. You can only access 3 out of 4 of them from the outside SO CLOSE!!!
Just for the info the 3 are as follow:
GND- any ground anywhere on the RC will do
PGC(program clock)(RB6)- Digital I/O 5
PGD(Program data)(RB7)-Digital I/O 6
MCLR(master clear/reset)- No hope of accesing this from the outside

Would you only need these for downloading to the PIC? or just uploading from?