AnsweredAssumed Answered

ADAU1452 DM0 delay issue

Question asked by Z0mb13 on May 8, 2016
Latest reply on Jul 27, 2016 by matthijs

There is a problem in the way sigmastudio allocate DM0 memory for DM0 delays. Here is an example schematic:

ex.png

It's a simple DM0 delay and a simple DM1 delay.

 

Here is the modified and commented compiler_output.log:

ADAU145X Assembler, Analog Devices Inc.

Version: 3.13.1,1065  (built 5/2/2016)

##### Summary #####

DM0 RAM used:     19238    (of 20480)

DM1 RAM used:     19208    (of 20480)

 

##### DM1 Allocation Summary #####

ModuloMemoryRegions:    Addr:   Modulo: Length:

_DEFAULT_MODULO_1       0x0     1       19204

Address:  Module:                 Param:

0x0                                 Link0/Link0_SHIFTREG3 =0x00000000

0x1                                 Link1/Link1_SHIFTREG5 =0x00000000

0x2                                 Link2/Link2_SHIFTREG7 =0x00000000

0x3        ADAU145XAssignableDelayAlg2 buff0 [19201] =0x00000000, ... // DM1 delay buffer

0x4B04     __DM1_PADDING__          __DM1_PADDING__ [4] =0x00000000,0x00000000,0x00000000,0x00000000

 

##### Exported C for DM1 #####

#define DM1_DATA_ADDR_IC_1 43780 // start address of DM1 memory

#define DM1_DATA_SIZE_IC_1 16 // 16bytes

ADI_REG_TYPE Param_Data_IC_1[PARAM_SIZE_IC_1] = {...}; // 4x4bytes

That is the standard case. There are 3things allocated. The DM1 delay is allocated last. As it is a delay, no need to initialize its values. The C array is only 16bytes long.

 

##### DM0 Allocation Summary #####

ModuloMemoryRegions:    Addr:   Modulo: Length:

_DEFAULT_MODULO_0       0x10    1       19204 // I don't know what Modulo means here. Default 1 memory?

_STACK_MODULO_          0x0     0       16

Address:  Module:                 Param:

0x0        __STACK__                __STACK__ [16] =0x00000000, ...

0x10       ADAU145XAssignableDelayAlg1 buff0 [19201] =0x00000000, ... // DM0 delay buffer

// This shouldn't be there but at the end of DM0 Allocation!

// If you use a DM0 delay, it changes the SafeLoad addresses!

0x4B14                              MP1_DM0 [4] =0x00000010,0x00000010,0x00004B04,0x00000000

0x4B18                              MP1_DM1 [4] =0x00000000,0x00000000,0x00004B04,0x00000000

0x4B1C     __SafeLoad_Module__      data_SafeLoad [5] =0x00000000,0x00000000,0x00000000,0x00000000,0x00000000

0x4B21     __SafeLoad_Module__      address_SafeLoad =0x00000000

0x4B22     __SafeLoad_Module__      num_SafeLoad =0x00000000

0x4B23     ADAU145XAssignableDelayAlg1 delay =0x00000000 // DM0 delay (amount of delay used)

0x4B24     ADAU145XAssignableDelayAlg2 delay =0x00000000 // DM1 delay (amount of delay used)

// ADAU145XAssignableDelayAlg1 buff0 should come here instead

0x4B25     __DM0_PADDING__          __DM0_PADDING__ [4] =0x00000000,0x00000000,0x00000000,0x00000000

 

##### Exported C for DM0 #####

#define PARAM_ADDR_IC_1 0 // start address of DM0 memory

#define PARAM_SIZE_IC_1 76964 // 4x10bytes + 4x19.2kbytes(DM0 delay) + 4x31bytes  from the beginning of DM0 memory

ADI_REG_TYPE DM1_DATA_Data_IC_1[DM1_DATA_SIZE_IC_1] = {...};

 

If you use a DM0 delay:

- The Safeload addresses change.

- A 19.2ksamples DM0 delay, leads to a >4x19.2kbytes DM0 memory initialization.

 

If you use a DM1 delay:

- The Safeload addresses don't change.

- The impact of the DM1 delay on the DM1 memory initialization is negligible.

 

If you do not initialize the DM0 delay memory, it works fine. But you have to manually process the generated files to do that. In this example you could easily get the application working only using the DM0 C array "from 0x4B14 until the end". So it's a 84bytes reduced array instead of the 77kbytes generated array.


Since using DM0 delays also change the Safeload addresses, I think it would be a great improvement that sigmastudio allocate the delay at the end of DM0 allocation, and remove the delay's buffers from DM0 memory initialization.

 

Best regards,

Simon

Outcomes