Post Go back to editing

ADAU1445 CRC error



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,


  • I have filed a bug report regarding this issue, which I also observed.

    Maybe their idea was to fill up the entire RAM with the code and still get a good CRC for that. Then, however, they should not write the code to the same memory address eight times...

    I have one more serious issue with the CRC: It causes false alarms whenever there is heavy I2C-activity.

    These false alarms can simply be reset by clearing the error: If I disable CRC, then enable it again, then the CRC error sticky bit  goes back to zero and remains zero - without reloading the DSP code! Therefore I am pretty sure that I am not accidentally overwriting any code during the "high activity" I2C phase, during which I am adjusting hundreds of mixer settings.

    If however I deliberately write garbage into program RAM, then simply clearing the error no longer works - which is the correct behavior. In this case I really have to reload the code to make the error bit stick to zero again.


  • Apologies for the very delayed response to this report.  This issue is discussed in a previous topic:

    SigmaStudio was updated to support this feature, however as you reported, it does not appear to be properly handled by the export system files command.   Thank you for report, we will investigate this issue. 

  • 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