Spin Semiconductor

hello, I'm new in this forum but very interesting with fv1
question here, is possible to protect the hex code in external eeprom ?
if yes, what software that i need ?
pardon my english,
any answer will be appreciated:)

No, it is not possible.

As Frank said, No. It is not possible to protect the code stored within the 24lcXX EEPROM but it is possible to protect your code if you wanted to do so. Sort of.
You would need to use a microcontroller with internal EEPROM space to send the programs to the FV-1 in place of the normal 24lcXX EEPROM, this would require you to be able to code the micro. Something like a PIC chip or Arduino would be capable of this job. There is a but though, while this makes it read protected. If someone really wanted to look at the code it is still possible to datalog the code as it is sent from the micro to the FV-1. Not an easy thing to do and unlikely anyone would be that interested to go to the expense of doing this.

I have been thinking on using an external mC su emulate the EEPROM, but never thought of using it to obfuscate the code.

I mainly have been thinking on using this to expand beyond 8 programs....

Do you know of any working EEPROM emulation code out ther for AVR or PIC?

Mat

potul wrote: ↑Wed Oct 28, 2020 2:43 am I have been thinking on using an external mC su emulate the EEPROM, but never thought of using it to obfuscate the code.

I mainly have been thinking on using this to expand beyond 8 programs....

Do you know of any working EEPROM emulation code out ther for AVR or PIC?

Mat

I tried emulated an EEPROM last week with a new AVR line (DA series), and got it to act as an I2C slave, reading out the data from the microcontroller, but ran into issues. My AVR would be sending data all fine to the FV-1, and somewhere along the line the clock would get stretched, the FV1 would NACK, and the transfer would halt. Can't tell if it is my code. I think I'd need to implement the I2C slave transmit in assembly to transfer the data without more efficiently to prevent clock stretching, since the FV1 doesn't support clock stretching (I've seen in another post), and that's what would happen before the transfer would halt, the clock got stretched. I occasionally got a program to transfer, but it was rare. And sometimes it was mangled and distorted (kind of cool sometimes haha).

There is an AVR document for the XMEGA series on operating as an I2C slave at 400kHz without clock stretching. Although the FV-1 seems to have an I2C SCL ~250kHz. In the document, it described using assembly routines and running at 32MHz F_CPU.

So, getting it working might take quite a bit of work and proficiency with MCUs. I was pulling my hair for a while. I think if I try again, I'm going to get an AVR to talk to another AVR first just to make sure my I2C slave routine works.