ADAU1452 DMA handling and interrupt servicing

Hello annihilate_123,

The SigmaDSP is designed to be simple and take care of these hardware details in a seamless way. These details differ for the different generations of SigmaDSP but you asked for the ADAU1452 which is the Sigma300 generation of processor. The Sigma350 will be the same with respect to these questions.

The SigmaDSP core does do pre-fetching of instructions but there are no DMA buffers for the data. Depending on the use of memory, some sections of memory are setup as a modulo memory so for things like FIR filter calculations the data does not move from memory, the pointers to memory move so there is no need to bring in a segment of memory into a buffer. The core has direct access. There is some memory management to prevent clashes with other peripherals where it will wait one clock cycle and the likely hood of a memory location being busy for more than one clock cycle is quite remote. There are some small data buffers in hardware to prevent these delays from being a problem. It all works quite well and you have no control over it. It is all handled in hardware and is seamless. This is the benefit of having a core designed for processing audio and not be simply designed for general purposes.

The interrupts are a little but more difficult to explain. There are not many, there is the frame interrupt for the start of the sampling rate frame and then there is the Block interrupt. These will stop the execution and begin servicing the interrupt. In the case of the frame interrupt, if the previous frame had not finished running then it never gets to finish most likely. This will usually cause a loop or stack overrun panic code to be generated.

Most programs do not use the panic code feature so the user might not be aware of these errors happening unless there is some strange behavior of the audio or functions of the program. However, we recently implemented a way to monitor for frame, block and multirate overruns. It also is a way to see the instruction usage for simple single rate programs with no block processing. I write a response on this post about how to use it. https://ez.analog.com/dsp/sigmadsp/f/q-a/117504/adau-1452-multirate-instruction-cycles-and-program-overrun

Getting back to part of your question. The interrupt handling is done in the Framework code and if you look at the compiler output window you will see the instruction/cycle usage of the framework. This is often not just interrupt handling but it is overhead code that is run every frame. So this will tell you the time it takes for this overhead.

Now the programmers recently made some changes. There used to be a line item called "Beginning Code" that was run during the first frame when the processor is started up but this is not longer listed. I will have to inquire as to where it went and how to understand those instructions. The reason it is important is that it is only run once and never again so it should not be counted in the normal frame cycle count.

Dave T

HI Dave ! Thank you for all your time . Appreciate your response . However i have few more queries ...

1. As far as i know In SHARC a receiver interrupt culminates the data to be filled into DMA buffer followed by filling up of pack buffer ..prior to this the read and write pointers do the empty space checking fill space checking to ensure data isnt overwritten in the ping pong buffer however ..Without a DMA buffer when a receiver interrupt does occur in SIGMA 300 what are the sequence of events that follows...Could you please elaborate on this SEQUENCE OF EVENTS that follows

2.

Hello annihilate,

I am really trying to say that you do not have to concern yourself with this. It is all handled either by hardware or by the compiler. It is a VERY different architecture than the SHARC so trying to compare them is like trying to compare why controlling a jet engine is not the same as controlling a piston engine.

There is no receiver interrupt.

When data comes into the part either from a serial port or from the SPDIF, ASRC, or the AUXADC, they are buffered ( with gate logic) and retimed because they can be latched in at slightly different times. So they are then transferred to the memory locations at the frame boundary. When this occurs the core is not writing or reading from memory. So there can never be a clash. The only thing that can clash is from the Comms port which is fully asynchronous. Those writes to memory will happen in one clock cycle. So if the core tries to write to the exact same memory location at the exact same clock cycle, Remember that it is running at 294.912MHz, then it will wait one cycle and try again. There is no way that the comms port is able to write two cycles consecutively to the same memory location. Depending on the sampling rate it is difficult to have two writes in one frame! especially with I2C at slower rates.

The frame interrupt is not really being serviced because it is basically the main loop. The program runs once during every frame and when the program is done it performs NOPS until the next frame. The block and multirate interrupts are the ones that have to store the current state and return to the main program. I don't think there is actually a hardware interrupt for the multirate, I think this is simply all done in software.

One other thing, back to the incoming data. If for some reason the data coming into the port is faster/slower than the core's sample rate, then the core will wither either pick up the same sample more than once or it will miss samples. They are not buffered. It is up to the user to properly set the sample rates and the clocking on the serial ports along with the core start pulse, etc. This can actually be useful and we have used this for doing some tricks with sampling rates.

Dave T

Well that explains it all

Thank You!