Post Go back to editing

Instructions (Cycles) close to 100% sometimes does not pass audio

Category: Hardware
Product Number: ADAU1452

I am running the ADAU1452 with a program that has worked in the past. The compiler was at 98% of Inst cycles, I added a few more EQ blocks, and the % is at 99%. I have had a few cases where the audio is not passing through the system when it was OK at first boot, and I am trying to track down the problem. Is it possible that the program, when executed is actually over 100% and the program cannot properly run?

  • Hello Todd_P,

    The instruction usage is an estimate since there are variables involved. One of them are loops in the program. Sometimes the loops may take longer to finish. 

    The other is safeloads. Are you using a system controller that is using safeloads to change coefficients? However, that should not cause a problem that is always bad, just when safeloads are being performed. Just those actual sample periods. 

    Then the last issue is the actual sample rate and how the sample rate is implemented. If the DSP is the master and the core Start Pulse register is set to an internal clock. Then the number of cycles (instructions) per sample period will be constant and not changing. If you are slaving to an external sample rate source then it WILL drift and so the number of instructions per sample period will change as the sample rate and core rate clocks drift from each other. This can be significant. 

    We did add a feature that will help you answer some of these questions. It is called the Overrun Monitor.

    You might have to remove a few things in your project to make room for the overrun monitor feature. I forget how many instructions it uses, I think it was  19 or so? If you have the normal clocking setup for 48kHz you have 6144 instructions per sample period. Since you are running at 96kHz that will be 3,072. Your report shows 3033 instructions so you will just barely have enough room for the monitor.  

    This monitor actually gives you the exact instructions used and you can see over time if it did overrun. This post explains how to use the overrun monitor that gives you some information. 

    https://ez.analog.com/dsp/sigmadsp/f/q-a/117504/adau-1452-multirate-instruction-cycles-and-program-overrun/352525#352525

    Dave T

  • That is very helpful. If I have a Framework overrun, and audio stops (as it should), would there be any way I could see that from my microcontroller, such as over I2C register? I am thinking I would want to alert the user if that happened. I am already monitoring the Core Status register.

  • Hello Todd_P,

    Absolutely Yes! If you click on the "Read" button and watch the capture window you will see it is reading a parameter in data memory. The address will appear in the system output files but I do not know exactly what it is called but you should be able to figure it out. 

    The Core status is good to monitor but it will not be super helpful. There is also the Panic Manager you can setup and monitor. I have detailed this in older posts, at least I think I have. I will look. 

    Here is a post about how to use the Watchdog Counter feature:

    (+) Using the Watchdog Counter in the ADAU1452 or the ADAU1467 family of processors. - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone

    Well, I did some searching for a post where I outline how to setup and use the panic manager. It appears I have not written one. I have answered some questions but not a lot of detail. This is one. 

    (+) ADAU1452 intermittently reporting strange panic codes - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone

    I do recall writing up some detail but it was most likely in an email to a large automotive customer. I will try to dig it up and write a longer post. Basically, one thing I can say is that you have to clear the panic codes shortly after the program starts to run. When the part powers up the memory is in a random state so it is almost guaranteed to have a parity error somewhere. Plus one other little detail is that the ASRC memory cannot be cleared by initialization code. It must be cleared by using the ASRC. So mask those errors and then once you start using the ASRC and it has locked. It will take around 1ms for the filter memory to clear. Then you can clear the errors and unmask the error bit. By the way, these parity errors are meant to find when bits might flip in memory. The mean time to failure of these memory cells are measured in the millions of hours of operation so this is very rare. The loop overrun, stack overrun and Watchdog counter errors are more likely to happen.  The Software Panic is still only used for Selfboot failures. 

    Dave T

  • Thank you, this is very helpful. I am also thinking about the PLL LOCK register. If for some reason the PLL LOCK was lost, would it be shown in the Panic Codes, or should I simply check that register from my microcontroller on a periodic basis.

  • Hello Todd_P,

    The PLL lock does not show up on any of the panic registers. I suggest you read it with your controller. However, it has come to my attention recently that there is a serious bug with the PLL. I was surprised that it took that long to find this and I personally had never checked it. (I was not a part of this project when the part was originally developed so I can step back and say it was not me!) However, I can see how this could slip by and not get noticed. 

    The problem is if the master clock just stops cleanly. Just quits. Then the PLL itself stops in its tracks and there is no clock present to update the lock flag!! So it still shows that it is locked because it is not able to update the flag! but it has no master clock so nothing works.

    If the master clock gets flaky and comes and goes no problem, the PLL will lose lock and the lock bit will show unlocked. Or if it changes frequency quickly it will lose lock then relock. So if you want to capture this one failure mode then you have to somehow sense the master clock.  One good way is to take the CLKOUT pin which is the output of the PLL and make sure that is either changing or I suppose you could rectify it and if it does to 0V DC then there is no clock out so no PLL. 

    This is also a failure mode where the DSP core itself cannot sense because with no clock the DSP cannot execute instructions. I have discussed this with our designers and I will be making sure this failure mode will be covered in new chip designs but there is nothing I can do for this part. 

    Dave T

  • Thanks Dave, I have followed your suggestions and everything seems to be working well and I have good results with the monitoring. One follow up question, ... I am now looking at the possibility that my Microcontroller , which is programming the 1452 on bootup, may not always program properly. Specifically if there is a communication problem on the I2C bus. Right now I am sending the program data over I2C, and then just monitoring the various registers, but I don't actually know if the program was loaded fully/properly. On other subsystems in my design, specifically the ADC and DAC (ESS parts) I do a checksum after sending the programming on bootup to ensure they are programmed properly before I unmute. Is there a way to do that on the 1452? I read some info on checksum related to the self boot, but I did not see anything for an external uCotroller.

  • Hello Todd_P,

    Have you had a look at the wiki page on this? and you don't find enough info there?

    The wiki checksum page details how to do this from uC and it also has a code snippet. 

    CheckSum [Analog Devices Wiki]

    Regards,

    Harish

  • Thank you! That is what I needed and could not find. 

  • Follow-up question on the PLL lock, If the PLL never locks to the MCLK  ; for example, the unit is programmed but the XTAL is not assembled properly, or my external MCLK  oscillator is not running at startup, the PLL will show "no lock" properly? I would want to alert the user know that there is no external clock for the DSP to lock onto, and in that case I would not unmute DAC outputs. I understand there is this bug that could let the PLL LOCK not change to UNLOCK , but I am looking at it never getting LOCK in the first place.

  • Hello Todd_P,

    This will all work as expected and there are no problems here with the sensing of the lock. It will show unlocked if it is not able to lock to the incoming MCLK for whatever reason. the changing to Unlock if you read what I wrote carefully is only a problem if the clock just stops and there is NO clock at all. Similarly, if from startup there is no clock then the chip will sit there like a brick and do nothing. There is no clock so it can do nothing. The serial SPI port will function because it works using its own clock you provide to it so it will read the memory location and give you the PLL status but showing it is not locked. 

    If there is some sort of clock but it is unstable or too low of a frequency then the DSP will function albeit REALLY slow and the PLL status will show it is unlocked. If it locks and then the MCLK gets flaky again it will show it is unlocked because there is some sort of clock just not good enough to lock to. The bug I mentioned is the one narrow use case where the PLL is locked and the MCLK just stops dead. Poof! Gone! Then the chip has no clock to do anything. In a new chip we are designing I am fighting for some sort of slow fall-back clock that it will use internally to be able to do things like update registers. It is tough to catch every possible problem and also keep the cost of the part down!! I mentioned a method in my earlier post where you can sense the CLKOUT pin because the CLKOUT is the output of the PLL. 

    Dave T