problem trying to load the program from a microcontroller
Hi,
I'm using the evaluation board for ADAU1467 and I'm using a microcontroller to load the program in it.
The schematic is a bit complex but in order to verify the load operations I have created a debug block
that contains the modules as showed in the fig below.
In the firmware I change the value of db_dc module that drive a led wired to the GPIO19.
It looks that the program is not loaded by the microcontroller.
I tried to delete all the modules excpet for the debug block and using the same microcontroller firmware it works.
Are there any reason to believe that the large amount of data can affect the loading of the program?
(programming the DSP directly by sigma studio 4.5 and USBi it works without any problem)
I’ve been trying to fix it for a week and it drives me crazy. please help me
anybody experienced something like this?
thanks all in advance
Audio Signal Processors
spi
microcontroller
adau1467
SigmaDSP Audio Processors
SigmaDSP
Show More
I know, the problem is too generic to be solved.
Anyway I've isolated the problem.
I use adau1467 in combination with the codec ad1937 at the sample frequency of 96Khz. In order to do that I use the module "Master Control Port IO Ext. Trigger" to setup the codec parameters.
The situatuin is the following:
When i programming the DSP via USBi everything goes smoothly.
When I send the firmware via the DSP it works unless I delete the module "Master Control Port IO Ext. Trigger". (obviously working at 48KHz)
I can't understand the reason.
Hello Alex,
Sorry for the delay. I have been out due to illness for a while.
Since you are using the " Master Control Port IO Ext. Trigger" module setup the codec. If you delete it then it will not be setup for 96kHz. So you will not get anything out of the codec. Using this module is not the best way to do this. It uses MIPS during every cycle when you only need to set it up once after booting. So use the Startup-Boot Master control Port IO module for this function. It is executed during the Beginning Code and never run again.
When the codec is not programmed and not in standalone mode, then it powers up with the internal master clock disabled. ( I have been tripped up by this in the lab in the past) So you must set it up no matter the sampling rate or set it into the Standalone mode if your serial port setup is only I2S and the sampling rate is 48kHz. There is also the detail of the ADC serial port output being master or slave. That is an option for standalone mode. However, I think the eval board is setup to set the codec to slave mode when you flip the switch to Standalone mode.
Now, regarding your original post. I am guessing you are running out of MIPS. What is our percentage of MIPS used in the compiler output report? Keep in mind it is for 48kHz not 96kHz.
We did setup a great addition to the framework features that allow you to monitor the MIPS usage. However, I discovered a bug in the ADAU1467 DLL so it does not work for this part or the other Siogma350 parts. It does work for the ADAU1452. This bug has been fixed and will be out with the next revision. The current revision is Rev 4.5 incase someone reads this months/years from now. In the Advanced Framework Configurations there is a checkbox for monitoring the framework overruns.
What happens if your program is too long to complete during one sample period is that the interrupt for the end of the frame comes and resets the counters/instruction pointers to the beginning of the program and it start running again. Any code that was after that point is never run. So you will get portions of a program that stop working.
You can sometimes detect this by using the Panic Code Manager. Usually if the program overruns there will be an overrun of a stack or a loop counter eventually. But the monitor feature is much better once it is working... Sorry about that.
If you want you can send me your program and I can take a look at it to see if there are ways to make it more efficient.
Dave T
Thanks for the answer,
I'm using SigmaStudio 4.5,
This is the percentage of MIPS that comes out of the compiler.
The firmware works well when it is downloaded via USBi for this reason I think that it's not a problem of out of MIPS.
Are there any reason why it works via USBi and not via uC?
However, I'll try to use the Startup-Boot Master control Port IO module.
Please log in to reply.
