AMC7904 Interrupt Mode

Additional information about the preceding question about the cause of interrupt mode.
Change the RESETCMD [1:0] bit to a non-zero value to exit interrupt mode (Tom Lane).
The results are as follows. I will let you know for reference.
Writes "01" to the [7:6] bit of the interrupt mode register ADDR (HEX) "0F."
Reset status (page 1 ADDR (HEX)) The measured value of "24" becomes "07."
Also, when "10" is written, the reading is "0D" and the sequence went all the way.

Thank you and best regards,
Takehiro Seino"

Additional information about AMC7904.
Checked AMC STATUS (Page1 ADDR (HEX) "05").
"4F," "0A," and "0F" readings occurred on multiple devices.
This is the result of an error detected in OperationMemory in the DAC.
SEC：Error correction with single bit errors. Bit [1]
DED：Error correction NG with multi-bit errors. Bit [2]
If this is confirmed, what do you think is happening?

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

The AMC7904 is a tricky device. There is a possibility when burning the memory in EEPROM, it was somehow overwritten, or other registers were accessed while the device was burning the memory. These errors, you say some devices are good and some are bad? Here are two tests you can perform:

1) Read all of the registers of one good unit and one bad unit and compare what is written. This will confirm if there were any memory burning issues.You can provide the log files to me.

2) Reset the registers to their factory default value, then burn the EEPROM and see if the problem continues. You can reset to factory default by writing register 0x07 Software Reset = 0xAD. Then burn to EEPROM.

Thank you,
Erin

Hi, Erin-san.

In BAD UNIT, "PA _ ON" is not enabled on 5 out of 8 devices. On the other hand, there is no NG out of 8 in a good unit.
In NG UNIT, "DED" or "SEC" of ADDR (HEX) "05" occurs in 3 out of 8 devices.
1)Submit the lead value for Page1. GOOD UNIT: RFIC#2, BAD UNIT: RFIC#3. Please check the attached file. AMC7904 page1 log01.xlsxAMC7904 page1 log01.xlsx
2)Let me check the detailed procedure again.
Should I write in the following order?
7E 01
07 AD
7E 0F
7C E4

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

1) Thank you for the register if oration. This shows that nothing was erroneously written during the burn sequence, as the only different registers are the status ones.

2) Yes, this is the correct sequence. Once you burn the EEPROM and restart the device, let me know if it is still in interrupt mode.

Thanks,
Erin

Hi, Erin-san.

Thank you for checking the log I sent you.
We also implemented a method to reset the proposed register to the factory default value.
I will let you know the result.
There are no more interrupt modes, but some devices still have bit errors.

Single bit error (SEC)
DEV No=66・・・ ADDR "0x05"→DATA "0x4A," ADDR "0x24"→DATA "0x0D"

Double bit error (DED)
DEV No=65・・・ ADDR "0x05"→DATA "0x4F," ADDR "0x24"→DATA "0x0D"
DEV No=67・・・ ADDR "0x05"→DATA "0x4F," ADDR "0x24"→DATA "0x0D"

Will replacing the AMC7904 with a new part solve the problem?
I would appreciate your comments on why setting the register to the default value does not fix it.

The log is also attached. Please refer to it.
AMC7904 page1 log02(Register Reset).xlsx

Thank you and best regards,
Takehiro Seino"AMC7904 page1 log02(Register Reset).xlsx

Hi Takehiro-san,

Just to confirm, the interrupt mode went away when you did the software reset, before you burned the EEPROM?

The SEC and DED error originates from damaged EEPROM memory. Usually, this can be fixed by reburning the EEPROM. Once you reburn the EEPROM, let me know if the SEC or DED errors are still showing up. If they are, this could originate from the LUT Configuration registers, which don't get reset unless you write 0-code to all of them.

Thanks,
Erin

Hi Takehiro-san,

Could you let me know what voltage you are using when programming the EEPROM? 

Hi, Erin-san.

Let me answer your first question. I reset the software and then ran Burn. I haven't checked if interrupt mode was removed before Burn.
I will answer the following question. For SEC and DED, the error indication for SEC and DED remained even after the software was reset to factory defaults.
Let me confirm the measures for this.
"This can be due to the LUT configuration registers, which are not reset unless all of them have zero codes."
Please provide specific steps to implement this comment.
What should I write on which page and at which address?

Also, I must have rewritten the software to the factory default value, but why is the LUT configuration register not set to 0 code?
Also, I understand that operational memory is a factor that causes SEC and DED. Is EEPROM a problem?
The following describes the occurrence of DED in a datasheet:
"1=A double-bit error was detected when accessing a LUT register in the operating memory."

Finally, the voltage I was using to program the EEPROM, but I didn't know which pin the voltage was.
I'll let you know what I can think of.
VDD=5V
VCC=5V
VSS=-9V
VIO=1.8V

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san

I talked with a designer. They said the SEC and DED errors could be bugged, and that we should look at the EECRC errors. When I looked through the data you sent me, none of the devices had EECRC errors. This means there is a chance the SEC and DED errors you are seeing are invalid. After resetting the EEPROM, has your interrupt mode been fixed?

For the power supplies: Are you applying VCC = 5V and VSS = -9V to the same device? If you are, this is an invalid configuration. The device should only operate in one voltage range, either VCC = 5V and VSS = GND, or VCC = GND and VSS = -9V. 

Thanks,
Erin

Hi, Erin-san.

Thank you for your confirmation.
The interrupt mode has been fixed as a result of resetting the EPROM to factory defaults.
I have a question for you.
Regarding the "This means there is a chance the SEC and DED errors you are seeing are invalid." in the comment below, does it mean that the hardware is working fine?
Do you mean the error displayed is a mistake?

Next, answer the power supply questions.
I didn't explain well.
VCC=5 V, VSS=-9 V are not applied to the same device.
Operating only in one of the following voltage ranges: VCC=5 V and VSS=GND, or VCC=GND and VSS=-9 V.

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

Glad to hear interrupt mode has been fixed! Hopefully when rewriting with your software, it does not come back. When writing your software to EEPROM, make sure there are no background sequences communicating with the device, as this can potentially cause errors.

Yes, there is a chance the SEC and DED errors could mean nothing here. The designer I talked to told me the main bit to look at is the EECRC bit, as this will tell you if the device detected any EEPROM issues. If your EECRC bit is 0, then you can safely ignore SEC and DED errors.

Thank you for clarifying the voltage ranges, there is no problem there.

Thanks,
Erin

Hi, Erin-san.

Thank you for your reply.
The device (AMC7904) is still available. Thank you.

However, to prevent this from happening again, I want to clarify why the device went into interrupt mode. What do you think caused the interrupt mode? Also, how do I avoid errors when accessing AMC 7904? Please let me know if there are any precautions.

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

We're not entirely sure how you got into interrupt mode. There are a few things we can check, though:

1) Monitor the VIO and VDD voltage when you are burning EEPROM. If these voltages lower during the burn, this can cause miswrites, which can potentially get you into interrupt mode.

2) Your system is doing other reads while burning the EEPROM. When burning EEPROM, you must ensure that nothing else is being done with the device, such as other reading or writing. This would be good to check, as we have had situations in the past where customers were monitoring the status registers, and thus caused EEPROM issues.

Thanks,
Erin

Hi, Erin-san.

Thank you for explaining this valuable information.
It is very helpful.
Thank you very much.

Thank you and best regards,
Takehiro Seino"

Hi, Erin-san.

We understand that the interrupt mode you inquired about is an individual event that occurred on our company device, so we will continue to pay attention to it. We will close this matter.
Now, there's something else I want to ask you.

Page2 ADDR (HEX) 10~13 is understood to be a direct writable address because TYPE is R/W.
However, the value that was supposed to be written is not left after RESET. Are there any possible factors? Due to the nature of CLAMP, are there any special steps required to complete the write?
I would like to inform you of the procedure we have performed for your reference. All of the following are WRITE COMMAND.

7E 01
0A 13
7E 02
10 0F
11 FF
12 0F
13 FF
7E 0F
7C E4

After that, when I restarted the device and read ADDR 10,11,12,13, it was "00."

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

I tried this on my own setup. When I disabled the LUT, wrote to the clamps, and burned the EEPROM, I received the correct values after a hardware reset. Which type of reset are you doing?

If you are writing 0xAD to the Software Reset register (0x07), the CLAMP Overwrite will read 0x00.

Thanks,
Erin

Hi, Erin-san.

Thank you for your confirmation.
I understand your situation.
Our company did a hardware reset.
No software reset has been performed.
I'll check it again.

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

If you just did a hardware reset, it definitely should have worked then! Let me know what you find out.

Thanks,
Erin

Hi, Erin-san.

In another register, we also performed a hard reset after running Burn and found that the value was not written to the address.
DAC BASE for pages 4 and 5.
ADDR[HEX]：65,67,69,6B

Also, regarding Burn, please tell me the following.
As for Bit3 (EERDY) of AMC Status of Page1, is there any case that Burn cannot be executed normally if it is not set to "0" before Burn?
Even after Burn to DAC BASE and hard reset, this Bit3 is always "1."
Does this affect anything?

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

The EERDY bit is read only, so you can not set it to 0. This bit indicates if an EEPROM burn is in progress. 0 means the device is burning the EEPROM, and a 1 indicates that the EEPROM burn is finished. So by default, this bit should always be 1 unless you are currently burning the EEPROM. 

On page 37 of the datasheet, it says that device pages 4 and 5 must be configured before pages 1 and 2. Did you write to the device in this order? It could be why pages 4 and 5 appear blank for you.

Thanks,
Erin

Hi, Erin-san.

Sorry for the late reply.
Thank you for your explanation.
I understand what the EERDY bit means.
Also, what exactly is the flow that means pages 4 and 5 on the device must be set before pages 1 and 2?
The write operation is performed by writing values to all registers on pages 4 and 5. Then perform a hard reset. Next, values are written in the registers of pages 1 and 2.
Then, burn processing is performed.
Is this flow correct?

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

The correct flow is to turn off the LUT, write to page 4 and 5, then write to page 2 and 1. Then burn EEPROM. You do not do a hardware reset in between because this will erase all of the information you put into page 4 and 5. 

Thanks,
Erin

Hi, Erin-san.

Thank you for your explanation.
Please tell me the detailed procedure.
The correct flow is to turn off the LUT first. Next, write to pages 4 and 5. Then write to page 2 and 1. and then Burn.
Do I have to write some kind of value to all addresses for the contents on pages 4 and 5 here?
Or should I write only some addresses?
Please tell me specifically which address I need to write.
Next, the flow is to write to page 2 and 1. Is it okay to write pages 4 and 5, then run Burn, and reset, then write pages 2 and 1?

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san,

You do not have to write to all of the addresses in page 4 and 5. Basically, I believe there may be a glitch where if you write to page 1/2, then write to page 4/5, then burn, it might not save the information correctly. According to the datasheet, it is more reliable if you write to page 4/5 with whatever data you require, then write to pages 1/2. If you do not have anything to write to page 4/5, you can skip it and just do pages 1/2 then burn.

I believe writing pages 4/5, burning, then resetting and writing pages 2/1 would be ok. 

Thanks,
Erin

Hi, Erin-san.

I'm sorry that time has passed.
Thank you for your explanation.

I would like to inform you of the procedure that we actually performed.
Is there a problem with the order of these contents? Please confirm.

Attach a text file.
DAC_BASE_Writing Procedure.txt

Thank you and best regards,
Takehiro Seino"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 01"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "0A 13"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 04"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "65 33"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "67 84"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 01"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "0A 13"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 04"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "69 36"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "6B F1"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 0F"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 67,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7C E4"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 01"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "0A 13"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 05"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "65 06"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "67 3F"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 01"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "0A 13"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 05"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "69 06"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "6B 35"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7E 0F"

    "$type": "I2CCommand",
    "Rfic": 3,
    "DeviceID": 66,
    "Operation": "WRITE",
    "ReadLengthBytes": 1,
    "FormattedCommand": "7C E4"

Hi Takehiro-san,

Here are my thoughts on the code:

"FormattedCommand": "7E 01"
"FormattedCommand": "0A 13"
"FormattedCommand": "7E 04"
"FormattedCommand": "65 33"
"FormattedCommand": "67 84"
"FormattedCommand": "7E 01"  -> you shouldn't have to go back to page 1 and reset the LUT 0A register. You are able to continue to write to page 4.
"FormattedCommand": "0A 13"  -> see above
"FormattedCommand": "7E 04"
"FormattedCommand": "69 36"
"FormattedCommand": "6B F1"
"FormattedCommand": "7E 0F"
"FormattedCommand": "7C E4"  -> You can write to page 5 after page 4 without burning EEPROM. This sequence you have here is ok though. Make sure you have enough time between burning EEPROM and doing the next write command, otherwise you could run into the interrupt error again.

"FormattedCommand": "7E 01"
"FormattedCommand": "0A 13"
"FormattedCommand": "7E 05"
"FormattedCommand": "65 06"
"FormattedCommand": "67 3F"
"FormattedCommand": "7E 01"  -> same as before, you shouldn't need to go and rewrite the LUT register.
"FormattedCommand": "0A 13"
"FormattedCommand": "7E 05"
"FormattedCommand": "69 06"
"FormattedCommand": "6B 35"
"FormattedCommand": "7E 0F"
"FormattedCommand": "7C E4"

Thanks,
Erin

Hi, Erin-san.

I'm sorry that time has passed.
Thank you for your opnion.

In the middle of the procedure, I realized that there were some steps that I didn't need to go back to page 1.
I also understand the following comment.
「You can write to page 5 after page 4 without burning EEPROM. This sequence you have here is ok though. Make sure you have enough time between burning EEPROM and doing the next write command, otherwise you could run into the interrupt error again.」

In particular, I want to see if the problem goes away by allowing enough time between writing the EEPROM and executing the next write command.

Thank you and best regards,
Takehiro Seino"