ADAU1452 doesn't start execution of program
Hi there,
I've designed a custom PCB with an ADAU1452 DSP. There is also a Linux SOM, a Codec for ADC/DAC and two MAX98397 on the PCB. Right now I'm trying to get the DSP to work. I've programmed a basic proof-of-concept kernel driver to load the firmware onto the DSP and also set up some registers.
The PLL locks perfectly fine to the 24.576Mhz crystal. Also the CLKOUT Pin works. I can communicate via I2C without any problems. The program data on the DSP looks good, also I've checked most other registers, but I cannot seem to get around the following problem:
The Core Status (register 0xF405) always states "Core is not running". The core is not killed, it is not hibernating, I tried sending a start core command with register 0xF402 many times and double checking everything else. Sometimes I get a memory bank 0 or so panic, but clearing that changes nothing from the problem. (I read that this is not an issue to worry about because the checksum is not correct when uploading memory).
In register 0xF401 so Start Pulse I configured to use 0x02 so base sample rate. For me that is 192kHz.
I don't have any selfboot operation. Also there is no USBi interface.
My SigmaDSP program consists of a Tone Generator with a splitter to output a sine wave to a 2 channel I2S output. (Also mixing with a I2S input).
Any idea what I may have overlooked or what I could check again?
What additional information do you need? Maybe a full register dump? What memory region would that be?
Audio Signal Processors
Speaker Amplifiers
adau1452
software
Core Status not running
SigmaDSP Audio Processors
Class DG
Show More
Hello Leander,
My first comment is about not have a USBi interface. You are handicapping your ability to troubleshoot and verify performance without the "window" into the program running in the DSP core. I have seen some customers put in a way to connect up a USBI and some zero-ohm resistors to disconnect the system controller. In your case since you are using I2C instead of SPI, you could just disable the I2C port on the system controller and jumper in the USBi I2C and ground pins. This just allows you to verify everything else first. But, moving on from this...
Since you are setting the start pulse to be a base rate of 192kHZ then setting the start pulse register to 0x02 is fine. I generally do not like setting up the clock generator with 192kHz as the base rate. It is not a super important reason but I just do not like the idea that there are clocks in the core running at fs*2 and FS*4 which is very high is you setup the clock generators to produce 192kHz at the X1 setting. These clocks are distributed to the serial input and output ports and to the ASRCs and other places radiating noise and using more power.
OK, It sounds like you have checked the Start Core and Kill Core registers. First make sure the Kill Core register is sitting at zero.
Then make sure the Start Coire register is also at zero...
Then change the Start Core to a "1" and that should start the core.
You need to do the transition from 0 to 1 when the core is NOT killed.
Oh! and also check the Hibernate register. 0xF400. Make sure it is sitting at zero.
At the moment nothing is standing out to me besides what I just mentioned. It is good you looked at the CLKOUT pin and see a clock. This means the main PLL is running.
If you could send over your program that might help. A memory dump would be tedious to go through and also the DSP program would be in assembler which is super tough to troubleshoot.
Thanks,
Dave T
Hello Dave,
Thanks for your answer.
I will consider USBi for my next design.
It seems my linux driver is having some weird issues, I think so at least.
Right now my ADAU1452 is outputting I2S and it seems the core is running fine. I quickly set up a userspace program based on the microcontroller driver template for SigmaDSP processors and I already had something working lying around for the ESP32 and ADAU1467. It seems that there is still some issue where sometimes there is an I2C error while uploading. But at least I got further now.
I'll keep investigating my troubles and maybe post an update here.
I primarily asked here to find out if I missed something obvious, but it seems not.
Thanks,
Leander
Hello Leander,
You have some good observations. The I2C error is an interesting observation. What is your I2C clock frequency? It is close to the 400kHz max I2C clock frequency? To push it over 100kHz you have to pay attention to the pull-up resistor value and the rise and fall times of the clocks and data. This is affected by stray capacitance. There is a timing diagram in the datasheet. Table 13 and figure 7.
There is a utility now to calculate a checksum when loading in a program but since you are using I2C it is usually not as big of a worry about errors in loading the program. The ACK that you get from I2C helps to know the DSP received the data.
Dave T
Please log in to reply.