ADAU1452 Data Memory 0 DM0 size

Hello Bernt,

Can you send the schematic to me via email? I would like to look at it. So they are exporting the system files and then using these files to compile the program for their MCU right? So the MCU's program image in the EEPROM is getting large?

What are they storing in DM1 and DM0?

Dave T

Hello Bernt,

The TxBuffer_IC_1.dat files are produced for backwards compatibility reasons. These files include the entire data memory which was not that big of an issue with some of our older parts with only a few k-words of memory. However, with the Sigma300 parts the memory is much larger. What is causing it to grow very large is that the delay memory is being saved in its entirety when it really only needs to be "zeroed" out. So all that really needs to be stored is where it starts and how large is the buffer. Then a controller can zero the memory when booting up and not store all those zeros in EEPROM. If you have SigmaStudio create the hex file as if you were to self-boot the part, then you see that it does not grow nearly as large because we do not store the entire buffer in the hex file.

So what I have been researching is now to use this SigmaStudio generated Hex file to mimic what our selfboot engine does and to have an external controller use this file. However, I have run into issues that the key to the file format in the datasheet seems to be wrong so the format must have changed. I am working with the software team to obtain more information. I will report back once I have the answers but it will be much later into January if I am to guess.

So meanwhile, they could parse several of the other files to produce a smarter loader that compresses the files to remove all the redundant zeros in the .dat files. In other words, come up with their own compression format for the EEPROM file that uses the TxBuffer.dat file as input.

I will document a better solution but I will not have much time to work on this in the coming weeks.

Dave T