EEPROM Memory layout?

[jwhitmore]

I'm looking at the layout of the code in the EEPROM, as I was hoping to use the Python Assembler and just program my binary into an EEPROM without using the DEV board and Windows. To answer the question how to write a binary file to EEPROM I hooked up a logic probe to the I2C Interface between the FV-1 and the 24LC64. The results are not what I'd expect, so I'm a bit confused.

Each 'Program' is 128 instructions, which are 32 bits wide, so looking at my trace of the I2C interface that's about 17.6mS of data. (I counted 128 Bytes on the trace and extrapolated out by 4. It's not exact but, close enough for the moment.) One of my problems is that sometimes the FV-1 reads twice this amount of data and I'm not sure why? More confusingly when I trigger on bus activity and change program I'm getting a different read Address from the EEPROM for the same "program" on the rotary dial?

The format for the I2C interface is a Chip Address byte and then High memory Address, Low Memory address. The first and last of the three bytes are always the same, as expected you're reading from the same 24LC64, and low order memory address is always 0x00, the High Order memory Address I'd expect to be different for each 'program' being read from the EEPROM. If I just look at the High Byte and the amount of data being read as I rotate the program selector rotary switch I get:

Program MSB Address Data
0 0x0C 17.6mS * 2
1 0x02 17.6mS
2 0x06 17.6mS * 2
3 0x06 17.6mS
4 0x0E 17.6mS * 2
5 0x0A 17.6mS
6 0x0E 17.6mS *2
7 0x0E 17.6mS

Go randomly around the rotary selector (Clockwise and anti clockwise):

Program MSB Address Data
0 0x0C 17.6mS * 2
1 0x02 17.6mS
0 0x00 17.6mS
7 0x08 17.6mS * 2
6 0x0C 17.6mS
5 0x0E 17.6mS * 2
6 0x0E 17.6mS * 2
7 0x0E 17.6mS *2
0 0x0C 17.6mS * 2
7 0x08 17.6mS * 3
6 0x0C 17.6mS
7 0x0E 17.6mS
6 0x0C 17.6mS
5 0x0E 17.6mS * 2
4 0x08 17.6mS
3 0x0C 17.6mS *2
2 0x04 17.6mS
1 0x06 17.6mS *2
0 0x00 17.6mS

So what I assumed I'd find is that program '0' is stored at fixed location, 0xabcd, in the EEPROM. so I know that if I write a 'binary assembler output to that memory location. The same for all the other 8 programs. So If I wanted certain programs in certain rotary switch positions I just had to write to the correct address. From what I'm seeing above both the address being read and the amount of data being read, is on the face of it random. On the face of it random as I haven't as yet deciphered it. So the address being read for program 0 depends on whether you arrive there from '7' or '1', so turned clockwise or anticlockwise. Sometimes reading from 0x0C and sometimes from 0x00. Sometimes two blocks of data sometimes only 1.

I decided I'd look at the addressing of the 24LC64, but I might have gotten this wrong. The pdf file for the dev board SPN1001-DEVB_sch.pdf specifies a 24LC64P, which is where I got that from, but when I look at my board I've got a 24LC32. The difference doesn't matter in terms of the addresses above. The 24LC32 uses a 12 bit address width so the lower four bits of the high order address are used.

I'd be grateful if someone could shed some light on the above results. I must plug a musical instrument into the dev board and see if I get consistent audio results from the program positions selected or can it vary depending on which way I was turning the rotary selector.

What have I misunderstood? Thanks for any light shed this way.

John

[jwhitmore]

Sorry the formatting of my table got messed up.

I just had the brain wave of checking the actual Datasheet for the FV-1. I've been through it a while back and couldn't remember anything specific about the EEPROM but thought I'd best check, in case I totally missed a description. Can't find anything mentioned there.

[frank]

Programs are always at the same location no matter how you got there, program 0 starts at 0.

You are seeing the result of your switch bouncing and re-triggering the "load program" state machine. Even if it settles to the same value it will re-trigger it.

Example, you go from "111" to "000" we could see due to bounce:

111 -> 100 -> 000 -> 010 -> 000

So you may see multiple loads from the EEPROM, it settles on the right program but it transitions through multiple loads as it sees changes on the pins.

[jwhitmore]

Ahhhhh

Thanks a million for that. So when I saw what looked like reading twice the normal length of data was in fact two reads, the first which I was looking at the address for, in a trace, and the second for the correct address after the switch pins had all settled down. If I make a PCB I might debounce those pins.

Thanks again for your help.