Post Go back to editing

ADAU1466 selfboot failure

Category: Software
Product Number: ADAU1466
Software Version: SigmaStudio 4.7


I use ADAU1466 as DSP on my design,and I use it's selfboot function.The contents of EEPROM are updated through DSP as below

I use a gpio to drive a LED then I can know if 1466 selfboots successfully.Sometimes I find 1466 works abnormally but LED is lightened by the GPIO which means that the 1466 has selfbooted successfully.

Read back the status of Register 0xF427 (PANIC_FLAG),then get 0x0001,as below:

Read back the status of Register 0xF428(PANIC_CODE),then get 0x0040.

When I restart the system,1466 reworks nomally most time.But the status of Register 0xF427 (PANIC_FLAG) are still 0x0001,and the status of Register 0xF428(PANIC_CODE) are changed to 0x0080.

I have some questions about this result:

1.The gpio has ligthened the LED,it means selfboot successfully,but why sometimes it works abnomally?

2.How to understand the PANIC_FLAG if it is 0x0001?

3.How to understand the PANIC_CODE if it is 0x0040 and 0x0080,and why it works nomally when 0x0080 ang abnomally when 0x0040?

  • Hello jobjun,

    The Panic System is used after booting and there are things you need to do first like clear the panic flag. Do not focus on the panic flags for the most part unless you set it up to use it. When starting up a program you will almost always trigger a flag because you will read or write to a memory location that is not initialized and will trigger a parity error. It is a cool feature but not to be used the way you are trying to use it. It is a much bigger conversation on how to use it. Search the forum for details. 

    I think you are running into issues with the selfboot being enabled when you are trying to write to the EEPROM. I explain it in this post:

    (+) Selfboot Problem on ADAU1452 - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (

    By the way, I almost never use the Read Write window. Yes, it is there and can be handy. I will use the sequencer but in this case you were looking at the Panic codes so I suggest you look at the actual registers. Then you see it decoded and will answer some of the questions you were asking. 

    In this screenshot I am showing the Panic registers. But there are many other tabs showing the register settings.

    Dave T

  • Hello Dave,

    Thanks for your reply.You mean that I should not judge if ADAU1466 selfboot successfully according to the result read from the registers of  Panic System,but the datasheet of ADAU1466 tells me I should do this action.

    It will be more puzzling.As you say,it looks like that ADAU1466 selfboot successfully as the LED is lightened,but the audio stream works not good.The ADAU1466 contacts to an AD2428 and an ADAU1761.AD2428 works as an A2B slave node,it gets audio messages from the master node and send audio stream to ADAU1466 through I2S.Then ADAU1466 transmits the audio stream to ADAU1761 through the other I2S.If ADAU1466 selfboot successfully,I should hear audio contents from the A2B master node.But actually it is not.As I metioned above,sometimes I can hear the audio from the A2B master node,but sometime I can't,even though the LED is lightened.I reload the cofigurations of ADAU1466 through USBi then ADAU1466 works nomally and I can hear the audio from A2B master node.It looks like ADAU1466 selfboot failed.There's clearly a paradox here.

    I can not get the answer of my questions on your reply.Can you tell more?

  • Hello jobun,

    I am sorry that this is in the datasheet. This is a detail I missed when I made updates to the ADAU1452 datasheet back in 2015. The ADAU1452 datasheet. is the most up to date but it is still the same. 

    It is not correct about the Panic codes for selfboot failure. When self boot fails it puts a code in the Software_Value_0 and 1 registers. 

    Addresses 0xF433 and 0xF434. You only need to check one of them and if it is not zero then the selfboot failed. 

    If you were not able to overwrite the existing contents then the old program would still be running. Make sure you disable the selfboot when you write to the EEPROM through the DSP. 

    If the selfboot is enabled then you can get corruption of the data in the EEPROM and that can lead to many different symptoms. Usually if the contents of the EEPROM is corrupted, it will fail the Checksum test and so the program will not run. No program will be running and no failure code will be placed in the Software Value registers. It will just not run. 

    Regarding your LED coming on. What is your circuit on the hardware? The reason why I ask is because when you do a reset all the GPIO pins will be in a high impedance state and so it will float up and that might turn on the LED. I suggest you setup the program to flash the LED. This is a better confirmation that the program is actually running.

    Do it like this, but use a much lower frequency like 2Hz.

    Dave T:

  • Hello Dave,

    I think we should not focus on the selfboot.I use a logic analyzer to obtain the datas from SCL_M&SDA_M during the selfboot process of ADAU1466.The result is that wherther ADAU1466 works nomally or abnomally,the datas of I2C during selfboot are same to each other.And the contents of register 0xF433 and 0xF434 are 0x0000.I firmly believe that selfboot is successfully.But the questions we met still there,contents of registers 0xF427 and 0xF428 are not 0x0000.I think I should let you know I have used the NR and AEC functions of ADAU1466.Can you tell me more about how to check NR and AEC functions work?

  • Hello jobjun,

    Go back and read my first reply. To sum it up, Do not look at registers 0xF427 and 428 after booting up. They will NOT be zeros and they never will be zeros ever. It is a much longer procedure to setup to use the panic flags feature and the first step is to clear the flags after booting up because they will always be triggered during the boot up process. This is why I say they will never be zeros. Please Please ignore these registers!

    Checking the NR is easy. Simply listen to the output and use the switch in the SigmaStudio schematic to shut it on or off. You can program your microcontroller to activate or deactivate this switch. Another option is to let the system boot up then connect the USBi and use the Link/compile/Connect button to establish control from SigmaStudio and then flip the bypass switch on and off. It is similar with the AEC. You can bypass it and hear it work or not work. 

    The error here may be with the ADAU1761 not being properly configured. 

    Look at the serial data on a scope and see if you can see the audio data going to and coming back from the 1761. 

    What is the master clock rate being sent to the ADAU1761?

    Dave T

  • Hi Dave,

    The master clock rate of ADAU1761 is 12.288MHz.It is generated by ADAU1466's CLKOUT,PIN 23 of ADAU1466.About the master clock,actually I have another question but I don't want to change our topic here.About you mentioned above 'The error here may be with the ADAU1761 not being properly configured'.I think you want to let me to configure ADAU1761 again when I couldn't hear the audio from the A2B master node.But I have tried this.When I met the situation,I can't let the system works normally if I just configure ADAU1761 again.I have to configure ADAU1466 one more time through USBi,then configure ADAU1761 because its master clock is from ADAU1466.Then I can hear the audio normally.The biggest problem is that the rate of the question we met is not 100%.We have to find a method to ensure my audio system works stablely after powered up.But now I feel I have a long way to go.So I need your helps DaveMaybe you need the schematics?The projects of sigma studio?You can get anything you want if it can help you to analyse my question.

  • Hello jobjun,

    You are correct that you have to configure the ADAU1466 first because the ADAU1761 has to have a master clock for it to be able to be configured. You cannot write to it without the clock. Well, you can write to it but it will not be listening. 

    So you have to configure the 1466. The CLKOUT pin is right off of the PLL so as soon as the PLL in the 1466 is locked then the CLKOUT will have the correct output. You have to set the CLKOUT register BEFORE you enable the PLL otherwise again, the settings will not take hold until you would disable and reenable. So setup the PLL registers and setup the CLKOUT setting and then enable the PLL.

    Then you can write to the registers of the ADAU1761. At first you can only write to the first few registers that are associated with the PLL. So you setup those registers and then enable the PLL. Then after writing for it to lock, you enable the internal MCLK and then you can write to the rest of the registers and memory locations in the part. This procedure is all well documented in the datasheet. 

    My one question about the MCLK frequency is because I have seen an issue where the MCLK frequency of 24.576MHz the PLL did not reliably lock to it with the settings we suggest in the datasheet. For that case you set the input divider to 2 and then the rest of the PLL settings would be the same as they are for the 12.288Mhz settings. You are using 12.288MHz so you should not be seeing this problem at all. I have never seen an issue with a 12MHz clock. 

    Are you using your own PCB or are you using one of our evaluation boards?

    Send me a message and a friend request. The schematics and projects would be important. Post them up here if you like but I suspect you do not want to do that. 

    Dave T

  • Hello Dave,

    I will show you the schematcs of ADAU1466.But  the projects are enciphered,so I can not show you now.

    See the main part of the schematics.On my design,I2S1 of ADAU1466 is bi-directional,so you can see BLCK_IN1 and BCLK_OUT1 are connected derectly.LRCLK_IN1 and LRCLK_OUT1 are connected derectly too.Some GPIOs are used,like MP6,MP7,MP8 etc.

    When powered up,the OSC provides clock of 12.288M.

    The design of reset and selfboot pins is different from the reference.Expecially the design of Reset.On the datasheet of ADAU1466,a circuit is recommended.

    Finally,I use 24FC512-I/SN as the EEPROM of selfboot.

    Maybe you can take a look first.I suspect there are some issues about RESET and power.An assumption I want to propose is that the rising edge of RESET when powered up is too slow.ADAU1466 can not response it correctly so ADAU1466  do not work normally even though maybe selfboot successfully.

    Now I want to get the waveform of RESET and then I will try to add an IC(Microprocessor Reset Circuit,call it RESET-IC) to control RESET pin.If ADAU1466 works normally after selfboot all the time.Maybe the answer of my question is here.I will have a try as quick as I can.

  • Hello jobjun,

    The first thing I quickly noticed in your schematic is that the self-boot pin is tied high, and it is high by default. 

    The self-boot pin must always be disabled (held Low) when you write the EEPROM via the ' write latest compilation thru DSP'. This is because Sigma Studio will reset the DSP, then start writing the program to the DSP. When the DSP is reset and self-boot is enabled, then the DSP will also start loading the program from the EEPROM. so, it may cause some clashes.

    Dave explains this in this thread very clearly. Please have a look.

    Selfboot Problem on ADAU1452 - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone (

    could you please disable the self-boot pin while writing to the EEPROM and see if it works?



  • Hello,Harishgowtham,

    Thanks for your reply.I know what you want to let me know and I have a design on my schematic.I'm sorry about that I do not show it above.Like below.

    When I connect an USBi,the self-boot pin will be low.I think EEPROM can be wrote correctly with USBi if I use this design.

    By the way,the voltage of RESET is just 2.5V.I think it may be a factor that influences the stability of my system when powered up.