SX28 chip data save

Rsadeika

The I2C/UART dev board came with two Scenix chips, what I want to do is save the data that is on the chip right now, then I will have the original stuff handy.

So, in device, if I do a read, and then do a 'save hex', I am assuming that copies the original contents of the chip. Later I can just do a 'load hex' to restore the original info that was on the chip. Am I correct in my thinking about this procedure. In other words instead of recompiling the code, and then doing a program the chip, I can just load the hex file, and I am done.

Or does so one else have a better way of saving contents off of programmed chips.

Thanks

Ray

David B

I also got one of those kits.

The floppy that came with it contains source files for both chips, SX1 and SX2. Isn't that what you want?

I'm assuming the floppy source files are the same code as on the chips.

Rsadeika

I am aware that the source is on the floppy, and that I can compile and re-program the chip. What I want to do is take what is on the chip right now and save that for a future re-load.

Thanks

Ray

Guenther Daubach

Ray,

you can use the "device - read - save hex", and later the "device - load hex - program" procedures for saving/restoring the original contents of the SX chip provided that it was not programmed with the DEVICE PROTECT option.

Nevertheless, you have the original source code on the floppy that came with the kit. To verify that the source code matches the contents of the SX program memory, hook up the SX-Key to the device you want to check. Next, load the matching source file, e.g. SX1.SRC, do a "Run-Assemble", then do a "Run-Device", and click "Verify". If there are no errors are reported, you can be sure that the code generated from the source file is identical to the code in the SX program memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Rsadeika

Guenther you mention the DEVICE PROTECT option, you have probably experimented with that, when you use that option, and some one does a hex read what will happen. Is the hex code completely unavailable or does it get·distorted. What kind of protection are we talking about.

If I do what you have suggested and the verify fails does that mean that the code is protected, or the problem lies somewhere else.

Thanks

Ray

Paul Baker

A read of a protected program comes back as scrambled data.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

MacGeek117

Can you load another program into the SX if it has one with CODE PROTECT enable?
RoboGeek

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are·3 kinds of people in the world,

the dreamers, the do-ers, and the "Oh, what's this button do"-ers.
Formerly bugg.
www.parallax.com
www.goldmine-elec.com
www.expresspcb.com
www.startrek.com
·

Jon Williams

Yes, but you'll overwrite the current program.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

Yes you can reprogram a chip which has a protected program on it, you just overwrite it. The only purpose of code protection is to protect your intellectual property (code) from prying eyes. Without it, Parallax couldn't make Basic Stamps because some shady outfit would steal thier code,make clones and sell them at a fraction of the cost.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

MacGeek117

Thank you!
RoboGeek

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are·3 kinds of people in the world,

the dreamers, the do-ers, and the "Oh, what's this button do"-ers.
Formerly bugg.
www.parallax.com
www.goldmine-elec.com
www.expresspcb.com
www.startrek.com
·

Guenther Daubach

Thanks guys - you have answered almost all the questions Ray had .

When doing a verify, you will definitely get an error when the chip was code-protected before, as the data read back are scrambled. On the other hand, you may also get verify errors with unprotected chips. In this case, it is most likely that the chip was programmed with a different program before, or with different DEVICE settings. Before running a verify, you need to load the SRC file into the IDE, and have it assembled in order to fill the IDE's internal program buffer with the matching data. During verify, the contents of this buffer is compared against the data read from the chip's program memory.

As mentioned in some other threads, it is recommended _not_ to use the Device dialog for programming chips. Always use the IDE's "Program" option. This makes sure that the device settings are programmed according to the DEVICE directives in the program code, and not to the settings in the Device dialog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Rsadeika

Thanks Guenther for the very short and informative tutorial on this. Just a few more thoughts before this post is laid to rest.

I am assuming that when you use DEVICE PROTECT option, it is applied when you do a RUN, PROGRAM, and DEBUG. So, you have to be aware of the fact that you are using that option, other wise it could create some havoc.

Also, is their code overhead that you have to be concerned about. When the scrambling is done and the chip is programmed, the chip has to know how to work with the code, correct. I guess what I am after is, if you write a program that is going to use the max code space, and you know you will be using the protect option, how much code·space should be left available, or am I on the wrong path with this.

Thanks

Ray

Guenther Daubach

Ray,

as far as I know, the DEVICE PROTECT directive does nothing else but clear bit 3 in the FUSE register during programming the chip. This does not cause the data in program memory to be scrambled, i.e. you can run, program, debug the chip as usual. The only difference is when reading the program memory you will get scrambled data. I'm using the DEVICE PROTECT option in many of my commercial applications, and don't have problems RUNning, or DEBUGing them with the SX-Key IDE. But the "Device - Read" and "Device - Verify" options will fail by good reason, reading back junk only.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G