CRC error false readout
Hello,
i'm referring to this post:
https://ez.analog.com/message/114369#114369
in which is reported:
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.
I'm having the same problem: after fighting with CRC issues (https://ez.analog.com/message/140557#140557) i finally managed
to have it working, but when there's IIC traffic i get random bad CRC readouts, which are cleared simply disabling and reenabling CRC check.
I modified my DSP check routine to attempt the "CRC disable/enable" trick, before to reset and reload DSP firmware.
Why these false readouts?
Is there any "clean" solution to avoid CRC trickery?
I'm using an ADAU1446
Thanks
Tom
Audio Signal Processors
adau1446
1446
iic
crc
SigmaDSP Audio Processors
Show More
HI Tom:
I have talked to some designers and they are asking me if you could give us your program count and instruction utilization. In essence we want to understand if there is a relationship between MIPS utilization and the occurance of this problem.
Thank you
Miguel
Of course:
2847 (out of a possible 4096 )
Modulo Data RAM used (X Memory):
2432 (out of a possible 8192 )
Non Modulo Data RAM used (X Memory):
0 (out of a possible 8192 )
Parameter RAM used (Y Memory):
1049 (out of a possible 4096 )
Regarding max instruction count :
Read Result
Param Address: 0xE229
Bytes: 2
Param Data:
0x0D, 0x5D
Why 0xd5d=3421 peak instructions executed when program is 2847 instructions long?
HI Tom:
Instruction utilization is not the same as MIPS being used. You see, some of the algorithms make use of loops and subroutines. The use of loops save on instructions but do not save on MIPS. The CRC is based on MIPS utilization and therefore may differ from the number reported by the assembler.
Anyway, we have some data here provided by you to make some hypothesis.
Regards
Miguel
Hello Miguel,
the board is running fine until now, though i'd to use that CRC workaround.
Are there any news on this?
Thanks
Tom
Hi Tom:
Indeed the designers confirm that when doing lots of I2C/SPI transactions (for reading back values from the core), the instantanous CRC result may be erroneous. The recommendation is to only use CRC with programs that don't use constant I2C/SPI access.
Miguel
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.