ΣSigmaStudio Ask AI Русский Log in

ADAU 1452/51  I2C  Safeload doesnt work

SigmaDSP & SigmaStudio MarcE Sep 20, 2017 00:00 6 replies Original on forum ↗
Subscribe
MarcE Question
Sep 20, 2017 00:00

Hello,

For two days I try to get the Safeload Mechanism working.

DSP is 1451, programming is done via I2C. Direct Programming/Reading works without Problems. (Custom PCB, commercial)

I2C Sequence:

0x00, 0x76 Adress ADAU

0x00, 0x28 Adress first Datafield Safeloadreg

0x00, 0x00, 0x00, 0x01 Data to be written

0x00, 0x2D Safeload Register Adress - Target Adress

0x00, 0x00, 0x03, 0x7D Target Adress

0x00, 0x2E Safeload Register Adress - Number of Data Words written

0x00, 0x00, 0x00, 0x01 Number of Datawords (In this case one)

The sequence is written as one Block, without I2C Start or Stop Conditions in between. I controlled the Communication many Times (see Pictures) but nothing happened. (Polarity of the Adio Signal should be inverted)

Second Problem:

After the first Sequence the I2C stays BUSY, so the MCU has to disable/enable the I2C Hardware.

As you see all Bytes are acknoledged.

What is wrong?

Marc

5758.6f6c4131cd4d7662dbb7eda8d702ad13.png
5758.6f6c4131cd4d7662dbb7eda8d702ad13.png
5758.6f6c4131cd4d7662dbb7eda8d702ad13.png-620x390.png
5758.6f6c4131cd4d7662dbb7eda8d702ad13.png-620x390.png
7750.76590ab3d772175c70db83cb27b0e8ff.png
7750.76590ab3d772175c70db83cb27b0e8ff.png
7750.76590ab3d772175c70db83cb27b0e8ff.png-620x390.png
7750.76590ab3d772175c70db83cb27b0e8ff.png-620x390.png
8117.36d82f15ab47d903b140460022242567.png
8117.36d82f15ab47d903b140460022242567.png
8117.36d82f15ab47d903b140460022242567.png-620x390.png
8117.36d82f15ab47d903b140460022242567.png-620x390.png
MarcE Reply
Sep 20, 2017 00:00

Hello

The second Problem could be solved. It is part of the complex of problems of the STM32s I2C Physics. Extremely annoying.

Marc

DaveThib Reply
Sep 20, 2017 00:00

Hello Marc,

Can you send over your SigmaStudio project? If you do not want to share it here then let me know and I will contact you.

Thanks,

Dave T

MarcE Reply
Sep 20, 2017 00:00

Hello Dave,

Thanks for the Feedback. We are not authorised to make the Project public. Contact me please. Do you have Access to my email Address?

Kind Regards

Marc

MarcE Reply
Sep 20, 2017 00:00

Good Afternoon

i think i got a Solution. Has nothing to do with I2C but with SS.

You are right Dave. Its better Analog Dev get the File.

Marc

MarcE Reply
Sep 21, 2017 00:00

Hello

Problems are solved now.

I2C Format was wrong. it is not possibel, to send the Datas to the Safeload registers at once. Three I2C Blocks are mandatory, otherwise the ADAU doesn't recognize the Addresses.

The Crossovers seem not to work properly with SS 3.15, i replaced them with the generell EQ Elements. Maybe the initially exported headerfiles contained therefore Errors.

The Crossovers wrote many Datas to Address 0x00 00 00 00. I can't imaging that's correct.

The SS Project was rebuilt, exported and so safeloading is working now.

If you are going to use the STM32 I2C Physics you should have the capability to suffer.

Marc

DaveThib Reply
Sep 22, 2017 00:00

Hello MarcE,

I will contact you in a minute. I will first write this post for you and possible others who may read this.

Yesterday I discovered a problem with the ADAU1450 DLL where it was not performing the safeload properly. It was always writing to address 0x00. I reported the bug and so it should be fixed hopefully soon.

The workaround is the use the ADAU1452 DLL that does work fine. The two parts share the same register map so you do not have to change anything. The only things to look for is the reporting of the cycles usage and memory usage. Those numbers will be wrong. So you cannot go over 50% MIPS usage and look at the actual size of the memory use to see if you exceeded the amount that is actually on the part. The compiler will not give you a warning message since it does not know that you are using a 1450.

So MarcE, I know that you said you are using the 1452/1451 so this is not the problem you are having. I did test the 1451 DLL and it did not have the problem. Only the 1450.

I will contact you directly to see about solving your issue.

Dave T