ADAU1445 - Some projects don't work when uploaded from MCU (but work with USBi)
So here is the situation:
I've used the 144x series a few times and haven't had a problem like this show up until now.
My setup: 1445 being controlled via a PIC32 over SPI. I have some jumpers on the board so I can switch to using the USBi for debugging/testing things in SigmaStudio.
Generally, uploading the code via the PIC32 and controlling everything works fine. There are some particular projects however, that don't respond after initialization/upload. I will hear audio, but writing to anything like a volume slider or switch is non-responsive. Also, reading a readback that is supposed to be the peak volume gives a constant number, even though I can hear the audio, which is varying in volume of course.
These same projects will upload and run fine over USBi. My init process is the normal "default_download_ic1()" (after setting to SPI mode). If I readback the entire contents of program RAM and compare it to the Program_Data_IC_1 array generated by SigmaStudio, they are the same.
Now, here is the strange part. The only projects that are failing are ones with a FIR filter in it. I've used FIR blocks with 200 coefficients before (in another application) and have not had a problem, as long as I stayed under the max MIPS/coefficient limits of the sigma chip, of course. Here, if a put a FIR filter in with 80 coefficients, the project will not respond when uploaded from the PIC32. The %'s in the compiler output are all under 25%, with the MIPS being the most at 23% (I'm running at quad rate). If I remove that FIR filter and replace it with a ton of first order filters (just to max out the MIPS at 25%), the resulting project works fine. If I drop the # of coefficients to 60, the project will deceptively appear to work, but certain blocks within the project will not respond, and others will!
This is what the non-working project looks like (with the 60 coeff FIR)
Subroutines called:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 800 800 338 265
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
(%) 22% 20% 4% 6%
And this is what a working project looks like, where the FIR is replaced by a ton of 1st order filters to max out the MIPS:
Subroutines called:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 894 894 364 253
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
(%) 25% 22% 4% 6%
At quad rate, this should be well within the limits! Any idea what is going on here?
Audio Signal Processors
adau1445
SigmaDSP Audio Processors
Hi josh:
Just to be clear. You are running @ 196kHz right? If you are, you are very close to the limit in terms of MIPS.
Are you using any of the algorithm that use subroutines (some of they are called "Optimized").
Miguel
Hi:
Any chance you can share a failing schematic? We can then investigate further.
Regards
Miguel
If you are not comfortable posting your schematic in this public forum, we can start a private discussion with you. Please let us know.
Hi Miguel,
I am running at 192kHz, yes. The max # of instructions should be 896. There aren't any optimized blocks being used, I'm pretty sure.
My concern is that like in my example, a project using 894 instructions runs fine, but another with 800 does not, with the difference being it includes an FIR filter block. Yet both work when uploaded over USBi.
Sure. I've stripped it down to a rather simple project, the minimal amount of stuff to result in a failed upload.
So this project does work when I upload via USBi. The readbacks and switches work, audio passes through, etc. When I upload the same project via MCU, it will pass audio, but the readbacks and switches don't work.
In doing this I found the exact cutoff point at which the project fails. If the "coeff" section of the compiler output goes over 256, the project stops working when uploaded via MCU. This made me think there could be something wrong with my upload code, but those 256 coefficients translate into a 1024 byte array, which is much smaller than the program RAM size (2268 or thereabouts) which uploads fine (I can read the program RAM from the Sigma and see it matches the array from the SigmaStudio generated header file). The Sigma limit on parameter RAM should be 8192 Bytes, so it should be good.
Incidentally, I think the compiler output is not giving accurate percentages for the coefficients. If the total parameter ram is 8192 bytes, and 256 coefficients take up 1024 bytes, you would be using 12.5%. The compiler output shows 6%.
Hi InoJosh,
Although I'm not sure I can offer any advice as to why the microcontroller-based boot is failing, I have a small correction to make to your post.
The parameter memory size of the ADAU144x is not 8192 words, it's actually 4096 words. You can confirm that in the corresponding section of the datasheet:
The data memory, on the other hand, is 8192 words. Perhaps that's where the confusion is coming from.
To break down the memories in this device and how each of them are used...
The program memory stores the machine instructions executed by the DSP core. Its size is 4096 words, but only 3584 instructions (maximum) may be executed within the span of a single frame.
The parameter memory (4096 words) is used to store filter coefficients and other processing parameters.
The data memory (8192 words) is primarily used to store audio samples that are held temporarily in memory to implement delay lines, filters, or other algorithms that require audio samples to be stored.
Additionally, some of the data memory may be set aside and designated as "non-modulo" data memory to store additional coefficients. I think this is simply done to enable more efficient coding of algorithms.
I hope that's helpful, even though it doesn't solve your problem!
Yagami,
I was thinking in terms of bytes, since I was considering the array generated by the SigmaStudio export function... but I was indeed off in my numbers. The 4096 words for parameter ram = 16384 bytes, since the word length is 28 bits (4 bytes).
But yeah... I'm still not sure what is causing this problem. I thought it was happening the moment I went over 256 coeffs in the project, but it turned out that was a fluke it seems. With other combinations of blocks, it stops working at a different point. Yet it is always well below 25% (100% at quad rate). Gonna have to keep working at it...
Hi InoJosh,
I'll toss this one out as a long shot, but recently I've run into a similar problem where a -1701 wouldn't work right when PIC-loaded, but ran fine with the USBi. We had to put a delay in our uC code to make the PIC32 wait about 50 mS after reset, before it began to boot the first DSP in our project (we have six of them!). The exact wait time is shown on page 20 of the -1445 data sheet. We had never run into this before, perhaps because our earlier projects used a slower PIC.
Best regards,
Bob
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.