Specifications for SIGMA_WRITE_DELAY Function

Hi Tom:

We are looking into this. My assumption is that we are treating the need for a Delay as a normal Write operations when generating microcontroller code with the intention to provide pseudo-code for user to use as a reference to implement a simple wait command on their uC for the PLL to lock.

Please experiment with this a bit, my experience is that the 1761 did require some noticeable time for the PLL to lock since it has a fractional PLL. I also know that the hardware guys have made improvements to prevent the need the PLL to lock to access memories however I don't recall what DSPs were implemented this way.

More to come

Miguel

Hi,

I searched about that a while ago, when I was coding for an ADAU1452 project.

void SIGMA_WRITE_DELAY(int devAddress, int length, ADI_REG_TYPE *pData );

The required delay between some of the I2C/SPI writes are different. So the delays passed as *pData are also different.

my delay function:

inline void SIGMA_WRITE_DELAY(uint16_t us)

{

_delay_us(us);

}

For more explanations, look into the ADAU1452 datasheet:

INITIALIZATION, p24 of revC.

I don't remember where on the forum an AD mod said that you should use a >1.3ms after the PLL enable, but if I use a 1300us delay, my ADAU1452 fail to start. So I think he was right.

I personally use:

SOFT_RESET delay

1334us

HIBERNATE delay

1334us

PLL_ENABLE delay

1334us

START_CORE delay

21us

Best regards,

Simon

Wondering if there's a definitive answer to the above query? I am also implementing ADAU145x downloaad from a microcontroller, and the default_download_IC_1 code emitted from SigmaStudio has multiple references to the SIGMA_WRITE_DELAY function, with different parameters. Does this imply a function with variable delay?

Thanks, that verifies for me that the function is simply a delay, and thanks for passing on values that worked for you.

Hi,

I just found back the interesting post:

Since the state of the processor is unknown when "Link Compile Download" is executed in SigmaStudio, the SigmaStudio initialization sequence must handle all scenarios and has some additional register writes.

The addition of "HIBERNATE" and "KILL_CORE" in the SigmaStudio handle the specific use case where the processor's SELFBOOT pin is high (meaning it is in selfboot mode). In this situation, after writing to the "SOFT_RESET" register, the processor will begin a selfboot and at the same time SigmaStudio is configuring registers and memory, the settings can get corrupted if selfboot and SigmaStudio are writing different data. To prevent this SigmaStudio waits for the selfboot to complete ("Reset Delay"), then it stops the DSP core (Hibernate + Kill_Core). Then it reprograms the registers and memory and restarts the DSP core.

If you do not have a use case that includes both selfboot and an external MCU or software that needs to overwrite the processor program, you do not need to include the Hibernate and Kill-Core registers. I would recommend you use the sequence from page 26 of datasheet revC instead because the SigmaStudio sequence adds delay and increases boot time.

The hibernate delay time depends on your program, for sample based processing it is 1 sample period: e.g. delay=20.8us.

So here is motivated summary:

You have 3 scenarios:

1 - you do not use SELFBOOT

Use the exported default_download_IC_1 function of sigmastudio.

You can remove some of the operations (reset delay, hibernate 0, hibernate 1, hibernate delay, kill-core, hiberate 0, ...), change the order of some things then it looks very much like the the Example System Initialization Register Write Sequence1 from datasheet p26.

PLL_ENABLE delay

10666us, (32*1024/3.072MHz) worst case according to the datasheet p26

START_CORE delay

50us, according to the datasheet p26

2 - you use SELFBOOT

Use the exported default_download_IC_1 function of sigmastudio.

SOFT_RESET delay

self-boot duration (depends of your application size, and SELFBOOT load rate), according to the post.

HIBERNATE delay

21us (1/48kHz), according to the post.

PLL_ENABLE delay

10666us (32*1024/3.072MHz), worst case according to the datasheet p26

START_CORE delay

50us, according to the datasheet p26

3 - you do not use SELFBOOT but you want to keep the exported default_download_IC_1 function of sigmastudio untouched as much as possible (great choice if you are planning to export very often).

Revert back to scenario 2, and choose a 0us soft_reset delay

Best regards,

Simon

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