ADAU1761 Program Clear Block
Hello,
I'm using the ADAU1761 and Sigma Studio v3.11. I have done several successful Sigma designs over the years, but this has me befuddled.
I have custom hardware which seems to work fine when using the USBi interface. Using a simple pass-thru program with only a single fader, I can pass audio and change parameters no problem.
In previous designs, I have always been able to take the Sigma Studio capture data output and use it to get my custom firmware control code working. However, in this case I am running into some difficulty. If I load the dsp program using the USBi interface, then copy all the register values and writing sequence into my MCU firmware, it appears to work as long as my HW is not power cycled. I can even reset my MCU, which has its own power-up sequence for turning on the dsps, and all is well. But if I kill the power supply, I cannot get audio to pass even though the code has not changed. For the reset case, it's as though the dsps are retaining their program even though they've been powered down. Bizarre...
So in troubleshooting, I noticed that the Sigma capture output has 5 sections of code labeled "program clear block" which are numbered 0 thru 4. Each block is all zeros, starting at address 0x0800, written in 4x 1020-byte chunks (each corresponding to 204 5-byte instructions) and 1x 15-byte chunk (equiv of 3 instructions). If I've done my arithmetic correctly, this adds up to 819 40-byte null instructions.
So here are my questions:
1. Why doesn't the program clear all 1024 instructions?
2. What prompted this feature to be added to Sigma Studio?
3. As I have never needed to do this before, is it necessary? When should it be used?
4. Could my issue possibly be related to NOT including these clearing blocks in my code?
Appreciate any help you can offer.
thanks,
chuck
Audio Signal Processors
program clear block
SigmaDSP Audio Processors
adau1761
Hello Chuck,
I will have to ask the programming team about the clearing instructions. I can only guess so I will save my speculation. I can however, say that there are several things you will see when looking at the communications from SigmaStudio to the DSP that seem to not make sense. But, it has to do extra housekeeping because it does not know if the hardware has been power cycled, or reset, or it is running a program when you hit Link/Compile/Download. So it has to do extra stuff like muting outputs and safely stopping the core etc.
Now I have not experienced this with a 1761 but it may be able to happen. I have had this issue with the 1772 where you power it down but when it powers up it is not in a default state! What happens is that I have it hooked up to the Audio Precision so it is getting clocks from an external device. So when I remove the power to the DSP the DVDD is now 0VDC. So anything over 0.3V will violate the pin input maximum and it will forward bias the ESD diodes and attempt to power up the part! For the ADAU7002 you can actually power up the part with just clocks! (it is a very low power part). So when I would power down the DSP there is enough power from the clocks to keep the memory from clearing. This may be what is going on but I am not sure. Remember that GPIO pins that might be driving a high into the part will also do the same. So if you have several GPIO pins and you are sending clocks and data from a DSP in the system then it is possible you think you are powering down the part but you are not. Have a look and see if this could be the case.
Dave T
Dave,
Thanks so much for your helpful reply.
Since I first posted last night, I discovered that indeed the dsp was remaining powered from clocks and pull-ups elsewhere. So at least that part of the mystery is resolved. I will have to remedy that problem on my next board revision. Still haven't got my own code working, but at least I know that's not the reason.
Understand on S.Studio needing to do housekeeping chores. In the past, I have just used the capture output just to get started. Once I have audio passing, I usually pare it down as needed for the design requirements.
As for the Program Clear blocks, I reviewed the datasheet section on burst mode it looks like it's loading 4-byte instructions into a 5-byte space. But either way I do the math, something is not right. So... I really look forward to the programming team's reply.
cheers,
chuck
Dave,
Just thought I'd let you know I resolved my initialization problem... a misplaced parenthesis on my address shifting.
This makes the program clear block kinda moot for me, but still would like to know from the programmers the How and Why.
Thanks,
chuck
Please log in to reply.