I've experienced a problem with using the "CRC error sticky" bit of the ADAU1445.
The ADAU1445 DSP in my design is configured by an external microcontroller using the I2C interface. The software configuration routine uses the automaticly generated C-code ( default_download_IC1() ) from the Export System Files function of SigmaStudio.
Configuration of the ADAU works fine and the program is running without problems. However I want to verify this from the software running on the external microcontroller by reading the "CRC error sticky" bit. My problem is that this CRC error sticky bit is almost directly set to 1 after the ADAU program runs. (Even worse, when I enable the CRC mute function, this mute functionality also enables accordingly).
I've tried several things to find the problem:
First I've loaded the same project directly from SigmaStudio into the ADAU processor. When afterwards I read the CRC error bit from my external microcontroller, this bit remains 0. With this difference I did suspect the I2C interface between the uC and the ADAU of having problems. I verified the I2C interface by monitoring it, but did not find any problem with it.
Inspecting the auto-generated default_download_IC1() routine, I saw it loads the program RAM up to 8 times(!!!) with the same data. This only occurs when the CRC is enabled at compile time in SigmaStudio. Otherwise it only programs the RAM only once.... Why is this? However, even when programming the program RAM 8 times by I2C, the CRC error did remain. For my this definitly proved it wasn't an I2C problem..
The next step I did was comparing the I2C command sequence generated by SigmaStudio loading directly the ADAU and the I2C commands sequence in the generated C-code. I noticed the main difference is the program RAM is being completely cleared when SigmaStudio loads it directly. This is not done within the auto-generated C-code!
By manually adding the program RAM clear commands to my microcontroller software, before calling the default_download_IC1()-routine the CRC error sticky bit did remain 0!
So my question is if this is a known issue or is there another solution for this problem? Clearing the complete program RAM by I2C @ 100 kHZ takes about 3 seconds, which is a noticable delay at start-up.
Hope you can advice on this problem. Thanks in advance,