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"

Hi Takehiro-san,

If you wait a sufficient amount of time after burning EEPROM, you should not run into any interrupt mode issues. Make sure not to read or write for around one second for safety.

Thanks,
Erin

Hi, Erin-san.

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

I would like to add a wait command if I want to run the Burn command on the EPROM and then run another command.
However, I don't know how to specify the wait command.
How do I write the corresponding command?

Thank you and best regards,
Takehiro Seino"

Hi Takehiro-san!

Once the EEPROM is done burning, the device waits for a command through SPI/I2C. You just need to insert a wait from your MCU of around 200ms between the burn command and whatever you would like to send next.

Thanks,
Erin

Hi, Erin-san.

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

I tried to add a wait command if I want to execute another command after executing the Burn command to EEPROM.
I used the wait command of the Python program.
log file is attached.
Lines 2627 and 2640. Add Wait 1 [s].

However, if you execute multiple ANTs consecutively, you cannot burn ANTs with odd order such as 1st, 3rd, 5th ・・・.
In contrast, ANTs with an even order, such as the second, fourth, or sixth, can Burn.
Attached is a log file of one ANT. If multiple ANT Bias adjustments are made successively, the contents of this log will be repeated.

Why doesn't Burn succeed when I add wait?
Please let me know if you notice anything.
When I tried changing the wait to 10 seconds, the same Burn failed.

Thank you and best regards,
Takehiro Seinolog_Ant27_console_240604_213347.txt

Hi Takehiro-san,

It sounds like this might be more of a problem with your software. I tried to copy your sequence (Writing page 5, burning, then page 4, burning) and I did not have any issue burning the memory. Unfortunately, I don't know how much I'll be able to help here, but I would suggest probing the communication pins to make sure the burn signal is being sent correctly.

Thanks,
Erin

Hi, Erin-san.

Thank you for your opnion.
Also, thank you for actually trying this procedure.

I will explain what is happening here in detail.
I do a Burn on the same AMC7904 in the first phase, 5 pages, then 4 pages.
Without turning off the power, in the second step, write 4 pages, then 5 pages, and perform Burn.
If I follow this procedure, and I check after rebooting the power supply, nothing is written to the address I wrote in the first step.
If possible, please confirm the reproduction.

I will send you the log for each successive execution.
The first stage →log_Ant27_console_240604_213347.txt
The second stage →log_Ant59_console_240604_214334.txt

Thank you and best regards,
Takehiro Seino"2330.log_Ant27_console_240604_213347.txtlog_Ant59_console_240604_214334.txt

Hi Takehiro-san,

So, if I understand you correctly, you take one AMC7904, burn page 5 then 4, and then on the same device burn page 4 then 5? Or are these two separate devices? If it's the same device, it will only show the second set of writes.

I did a quick look through your procedure, and it doesn't look like you write to anything besides registers 65, 67, 69, and 6B on pages 4 and 5. I would appreciate more information about the procedure, since I can't quite understand what's going on in the logs.

Thanks,
Erin

Hi, Erin-san.

Let me answer your first question.
This is happening on 2 AMC7904 devices.

There were some inaccuracies in my explanation. I'll correct it.
I will tell you the procedure again.
The following description is based on the attached block diagram. Block Diagram.PNG

・Write DAC3 (adr=69, 6B) and DAC2 (adr=65,67) of AMC7904 (Dev_ID=47) to the PA Module of ANT27.
・Then run Burn.
・Then Wait for 1 second.
・Next, write DAC1 (adr=69, 6B) and DAC0 (adr=65,67) of AMC7904 (Dev_ID=46) to the PA Module of the same ANT27.
・Then run Burn.
・Then Wait for 1 second.
Perform the following steps without turning off the power.
・Write DAC0 (adr=65,67) and DAC1 (adr=69, 6B) of AMC7904 (Dev_ID=47) to the PA Module of ANT59.
・Then run Burn.
・Then Wait for 1 second.
・Next, write the values of DAC2 (adr=65,67) and DAC3 (adr=69, 6B) of AMC7904 (Dev_ID=46) to the PA Module of the same ANT59.
・Then run Burn.
・Then Wait for 1 second.
Then restart the power supply.
When I read the value written to EEP, I found that the value I should have written to DAC3 (adr=69, 6B) and DAC2 (adr=65,67) of AMC7904 (Dev_ID=47) of ANT27 and DAC1 (adr=69, 6B) and DAC0 (adr=65,67) of AMC7904 (Dev_ID=46) was not written.

As described above, when Burn is executed consecutively to the devices of two ANTs, the value of the first ANT is not written.
Detailed command information is provided in the attached file. Burn_flow_20240620_01.txt
Please let me know if you notice anything.

Thank you and best regards,
Takehiro Seino"

 (0/5) FNL_PK write: RFIC#2, Dev=47, Page#05, ad=7E, dt=['01'], res=
 (1/5) FNL_PK write: RFIC#2, Dev=47, Page#05, ad=0A, dt=['13'], res=
 (2/5) FNL_PK write: RFIC#2, Dev=47, Page#05, ad=7E, dt=['05'], res=
 (3/5) FNL_PK write: RFIC#2, Dev=47, Page#05, ad=69, dt=['33'], res=
 (4/5) FNL_PK write: RFIC#2, Dev=47, Page#05, ad=6B, dt=['8D'], res=
 (0/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=7E, dt=['01'], res=
 (1/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=0A, dt=['13'], res=
 (2/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=7E, dt=['05'], res=
 (3/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=65, dt=['36'], res=
 (4/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=67, dt=['F4'], res=
 (5/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=7E, dt=['0F'], res=
 (6/7) FNL_CR write: RFIC#2, Dev=47, Page#05, ad=7C, dt=['E4'], res=
  Wait 1sec
 (0/5) DRV_CR write: RFIC#2, Dev=46, Page#04, ad=7E, dt=['01'], res=
 (1/5) DRV_CR write: RFIC#2, Dev=46, Page#04, ad=0A, dt=['13'], res=
 (2/5) DRV_CR write: RFIC#2, Dev=46, Page#04, ad=7E, dt=['04'], res=
 (3/5) DRV_CR write: RFIC#2, Dev=46, Page#04, ad=69, dt=['06'], res=
 (4/5) DRV_CR write: RFIC#2, Dev=46, Page#04, ad=6B, dt=['5C'], res=
 (0/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=7E, dt=['01'], res=
 (1/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=0A, dt=['13'], res=
 (2/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=7E, dt=['04'], res=
 (3/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=65, dt=['06'], res=
 (4/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=67, dt=['3C'], res=
 (5/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=7E, dt=['0F'], res=
 (6/7) DRV_PK write: RFIC#2, Dev=46, Page#04, ad=7C, dt=['E4'], res=
  Wait 1sec

 (0/5) FNL_PK write: RFIC#2, Dev=47, Page#04, ad=7E, dt=['01'], res=
 (1/5) FNL_PK write: RFIC#2, Dev=47, Page#04, ad=0A, dt=['13'], res=
 (2/5) FNL_PK write: RFIC#2, Dev=47, Page#04, ad=7E, dt=['04'], res=
 (3/5) FNL_PK write: RFIC#2, Dev=47, Page#04, ad=65, dt=['33'], res=
 (4/5) FNL_PK write: RFIC#2, Dev=47, Page#04, ad=67, dt=['9B'], res=
 (0/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=7E, dt=['01'], res=
 (1/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=0A, dt=['13'], res=
 (2/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=7E, dt=['04'], res=
 (3/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=69, dt=['37'], res=
 (4/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=6B, dt=['17'], res=
 (5/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=7E, dt=['0F'], res=
 (6/7) FNL_CR write: RFIC#2, Dev=47, Page#04, ad=7C, dt=['E4'], res=
  Wait 1sec
 (0/5) DRV_CR write: RFIC#2, Dev=46, Page#05, ad=7E, dt=['01'], res=
 (1/5) DRV_CR write: RFIC#2, Dev=46, Page#05, ad=0A, dt=['13'], res=
 (2/5) DRV_CR write: RFIC#2, Dev=46, Page#05, ad=7E, dt=['05'], res=
 (3/5) DRV_CR write: RFIC#2, Dev=46, Page#05, ad=65, dt=['06'], res=
 (4/5) DRV_CR write: RFIC#2, Dev=46, Page#05, ad=67, dt=['51'], res=
 (0/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=7E, dt=['01'], res=
 (1/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=0A, dt=['13'], res=
 (2/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=7E, dt=['05'], res=
 (3/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=69, dt=['06'], res=
 (4/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=6B, dt=['3F'], res=
 (5/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=7E, dt=['0F'], res=
 (6/7) DRV_PK write: RFIC#2, Dev=46, Page#05, ad=7C, dt=['E4'], res=
  Wait 1sec

Hi Takehiro-san,

I understand your procedure now, thank you for the diagram and explanation.

In theory, there should not be any issue with your program. I wonder if after burning the EEPROM, the device or your program does something strange, and writes "00" to those registers. Would you be able to add a command to read the registers after burning? For example:

-DEV ID 47, write DAC3 and DAC2.
-Burn EEPROM 
-DEV ID 47, read DAC3 and DAC2. Confirm that the first step sequence was done correctly.

Do this for both devices and let me know if the first set of burns do it correctly or not.

Thanks,
Erin