Pops when changing programs in a second eeprom

[scmitche]

In a vintage multi-head delay emulator we have an Arduino Nano controlling the switch over of 2 eeproms to give a total of 16 programs. I have noticed a pop or click on the output, which only occurs when the 2nd eeprom is switched into circuit. This is effected using a change in level sent from D5 on the Arduino via an NPN transistor to toggle the levels seen by the address bit E0 on each eeprom, i.e. as one E0 is at low level the other is high level and vice-versa. Anyone any ideas why this should generate the click as the addresses swap over to put eeprom 2 into circuit with the FV-1? There is no click when using only eeprom 1 emulations/patches.

[frank]

Well, saying Arduino doesn't tell me much, which board? Which processor? Schematic of entire circuit?

I would start with a scope to see when the pop happens exactly. When the eeproms are switched? When the program starts to run?

Are you changing D5 and waiting a few milliseconds for the eeproms to settle to the new level on A0 before changing the program select lines?

[PhilHaw]

Hi Steve and Frank,

As the firmware programmer for the project Steve has asked you about I can fill in some of the details of how I handle FV-1 program changes. Our pedal reads a 'user patch' from a separate eeprom. This contains the FV-1 program number and the pot settings for P0-P2.

The program number from the stored patch is in the range 0-15 or 0b0000 to 0b1111 (we use the extra 4th bit to indicate which of our two DSP EEPROMs the program is stored in, 0bxxx = Mem 1 and 0b1xxx = Mem 2).

The FV1_Control algorithm is basically as follows:

The EEPROM select output from the Arduino (obtained from the 4th bit of the program number) is set high or low at the start of the FV1_Control function. Since, for some reason, the click is only heard when changing between MEM2 programs, if the select line is already set to Mem2 it won’t actually change by being set again as it’s already high. Therefore I don’t think this is the cause.

Let’s consider the scenario where we currently have program 2 in Mem 1 selected and we want to change to program 2 in Mem 2. Changing the Mem select line won’t make the FV1 read the new program because S0-S2 have not changed – this was the early bug way back years ago and it was fixed as follows:

The S0-S2 lines (i.e. the FV1 program number 0-7 or 0b000 to 0b111) are flipped to their opposite state using the exclusive-OR function with the bit mask 0b111. This flips all the bits in the program number to their opposite states, to force the FV1 to load a new program. NB This happens after the memory select pin is set.

E.g. if program 2 (0b010) had previously been selected in Mem 1 but the patch wants program 2 in Mem 2 then this will force the S0-S2 to 0b101 (decimal 5) and the FV-1 will load prog 5 from Mem 2.

I allow 100ms after changing S0-S2 to allow the FV1 to load the program.

Now the S0-S2 are set back to what the patch requires by ex-ORing again with 0b111 giving 0b010 again. This time the FV1 loads program 2 from Mem 2 as required.

Again I wait 100ms before proceeding to set the pot values from the values stored in the patch.

[forum_admin]

I would look for an unexpected glitch on any of the eeprom lines. While you may be writing the same value to the mem select pin it may be glitching.

Again, schematic and what processor is the arduino board using? Is the pin open collector?

[ice-nine]

Hi, I'm also one of the members of this project, the Arduino is a NANO which uses the ATMega328p which is a 5v device but we have level shifters in place between all FV-1 pins. I can dig out the full schematics as requested if I am able to send PM.

[frank]

Yeah, I would look around the level shifters for a glitch. Something must be pulling a line since it happens on every program in one eeprom but not on the other and the only thing different is A0.

[PhilHaw]

Frank I was wondering how the FV-1 reads the S0-S2 inputs when checking if they have changed. Does it poll them (if so how often) or does a change in any one of the inputs cause an interrupt which then tells the FV-1 to read in the three switch input?

Also, having looked at the FV-1 Datasheet, I can't see any recommended min/max logic levels for '0' and '1' specified for the S0-S2 inputs.

Our logic level converters consist of a 1.5k pull-up resistor to +3.3V with the Arduino (5V) output going through a 1N4148 diode, reverse biased on a logic high and pulled down to the Arduino's logic low level so the logic low seen by the FV-1 would be at least one forward diode voltage drop.

Thanks

Phil.

[frank]

FV-1 is a typical CMOS process so anything above 0.7*VDD is a "1" and below 0.3*VDD is a "0"

Have you looked at all the signals for a glitch? Personally I would ignore everything else until I tracked down with a scope where the pop is originating. Is it on the power line? A glitch in a control line?

[ice-nine]

FV-1 is a typical CMOS process so anything above 0.7*VDD is a "1" and below 0.3*VDD is a "0"

Have you looked at all the signals for a glitch? Personally I would ignore everything else until I tracked down with a scope where the pop is originating. Is it on the power line? A glitch in a control line?

Just an update on my findings, 1st off the second EEPROM does not click on program change every time in my testing. The second thing EEPROM 1 also clicks when the hex file from EEPROM2 is placed in EEPROM1. I have flashed 2 completely different test.hex files to both EEPROMS and with these there has been no clicking at all. Would you still like me to PM you the schematics Frank ?

[frank]

This changes the plan of attack. Do the following:

Note which programs clicks happen between, i.e. click when going from 2 to 3 but not 3 to 2, etc. If this is consistent then issue is most likely with your code, you are introducing an offset somewhere in the code.

If this is not consistent then program both eeproms with a pure pass through program and see if the click still happens at times. If it does then it is a circuit issue and you will have to look at signals with a scope to determine the source.

[scmitche]

FV-1 is a typical CMOS process so anything above 0.7*VDD is a "1" and below 0.3*VDD is a "0"

Have you looked at all the signals for a glitch? Personally I would ignore everything else until I tracked down with a scope where the pop is originating. Is it on the power line? A glitch in a control line?

Just an update on my findings, 1st off the second EEPROM does not click on program change every time in my testing. The second thing EEPROM 1 also clicks when the hex file from EEPROM2 is placed in EEPROM1. I have flashed 2 completely different test.hex files to both EEPROMS and with these there has been no clicking at all. Would you still like me to PM you the schematics Frank ?

Hi Frank, The clicks disappeared when I reduced two programs from 127 clicks to 126. These are nothing like one another in program style; the first a multi-head delay and the second a variable reverb. It had me very confused but at least the problem seems to have gone. Thanks for your help.

[PhilHaw]

This changes the plan of attack. Do the following:

Note which programs clicks happen between, i.e. click when going from 2 to 3 but not 3 to 2, etc. If this is consistent then issue is most likely with your code, you are introducing an offset somewhere in the code.

If this is not consistent then program both eeproms with a pure pass through program and see if the click still happens at times. If it does then it is a circuit issue and you will have to look at signals with a scope to determine the source.

Hi Frank, I followed your suggestion and with straight thru programs in all banks of both EEPROMS there were no clicks. I see that Steve has notified you of his finding that reducing the code from 127 to 126 instructions in a couple of the troublesome programs removed the previous clicking problem. We're not sure why that would happen!

Thanks for your help.

Phil.

[frank]

My guess is still a DC offset was being introduced. I've written programs that use all 128 instructions and never had any pop due to number of instructions.

In any case glad it is working now!

[scmitche]

Hi Frank,
I narrowed down the click/pop problem when changing programs to the fact we were using both ADCR & ADCL and summing/averaging them. If I only use ADCL then the problem is solved. Does this point to a slight difference between the ADCs in some way to produce an offset?
Thanks again. Steve

[frank]

I would need to see the schematic and code to determine what it is. But there will always be a minor difference in the converters even though they are in the same chip. But if it is working using only ADCL then keep doing that.