Monitor Faults? Diagnose hung SigmaDSP?

The SigmaDSP /may/ be entering Hibernate mode, but I'm not sure.

I found the page in SS for CORE_CONTROL PANIC, but those are all Red when "Read This Page" is clicked.

Hello SoundConsulting,

In the Register Control Window → Core Control tab, you can find the Hibernate register read option. By clicking the Read button under the Hibernate section, you can check whether the DSP core is currently in hibernate mode or not.

When the hibernate bit is enabled, it places the DSP into hibernation mode. In this mode all incoming interrupts are disabled, and the DSP core enters a low-power sleep state after completing the processing of the current audio sample or block essentially the DSP goes into hibernation by masking all interrupts.

Regards

Aravindh

Hello SoundConsulting,

In addition to what Aravindhan is asking about I would also like to ask if you are using any blocks that require a license? Some blocks will work only for a short time until you purchase a license for the block.

It would be best if you could attach your project.

How are you clocking the DSP? Is it from a crystal or from something else?

It would also be good to see the schematics of your boards. Feel free to send it via a private message if you need to keep it secret.

Include Aravindhan so we can both work on this.

Thanks,

Dave T

It's definitely in Hibernate mode, whether I read the whole page or just the Hibernate register. Sometimes it also shows Halt mode.

My question is how do I get the SigmaDSP out of Hibernate mode, or prevent it from entering that mode?

Hello Dave,

No licensed blocks. If fact, I was wondering if the schematic was too simple.

Project and support files attached in a ZIP file.

8546.Design-48.zip

The SigmaDSP is clocked by a 12.288 MHz oscillator, ECS-TXO-3225MV

I'll work on the other aspects.

Hello SoundConsulting,

I need to explain a little bit how the core of the DSP works. Sorry that it had been a busy day for me today...

The DSP core will sit and wait for the "Start Pulse" to trigger it to start executing the program in program memory. There is a register of course to select what it triggering it and of course that sets the sample rate.

Then the core starts executing the program. When it reaches the end of the program, assuming the program is shorter than the max number of instructions, the core will reset the instruction pointer to zero and then go into Hibernate mode and wait for the next "Start Pulse" to start processing the next set of samples!

So if you have a fairly short program, let's say 1,000 instructions. If you are running at 48kHZ then you can fit over 6,000 instructions. So for at least 1/6th of the time the core is in hibernation. So if you read the register, the chances of catching it running is small.

We did add a feature a number of years ago to SigmaStudio to allow you to monitor the core. Here is a post where I explain it.

(+) ADAU 1452 Multirate instruction cycles and program overrun - Q&A - SigmaDSP Processors & SigmaStudio Dev. Tool - EngineerZone

This is important if you are running at high sample rates and of course if you are triggering to an external clock source.

Now regarding the clocks coming out of the core? I need to better understand your clocking arrangement. What is driving the PLL?

What are the PLL settings?

What is the core start pulse set to?

Are you using any "timed" blocks that need to have paid licenses before unlocked blocks are supplied? Usually this has nothing to do with the clocks but I do not know exactly what you are doing so I mentioned it since you mentioned it working for a while then stopping.

Setup the overrun monitor and that might give you some clues.

Thanks,

Dave T

Thanks, Dave.

So, it seems that the Hibernate status might be a red herring, since my schematic so far only uses about 3% of the cycles. I will read the linked post that you shared, because I'll be starting at 48 kHz but eventually hoping to run at 192 kHz.

PLL CLK SRC is PLL clock (i.e. not external MCLK) and when I query that page it shows PLL locked (that seems good).

MCLK OUT is now 12.288 MHz (the higher 24.576 rate will be needed for 192 kHz)

START PULSE is Base_Fs

You should find all the PLL settings in the project inside the ZIP attached earlier in this thread.

There are no "timed" blocks.

I will set up the overrun monitor and see what I can learn.

Unfortunately, I blew my power supply while probing with the oscilloscope probe, and I'm searching my lab storage for a trusty old bipolar supply to replace it. I can test on the EVAL board, but that doesn't seem to have quite the same problems as my own board.

I finally enabled these monitoring options, but did not get anything back from the SigmaDSP. I'm also not getting anything from DSP Readback, so perhaps the two issues are related.

I will try to contact you to summarize the issues I'm having since they may be broader than this topic.

I found the issue.

The IOVDD rail is dropping significantly - presumably due to some component pulling too much current shortly after startup - and then the ADM811 is asserting reset. Since reset connects to all the major chips - DAC, ADC, A2B, SigmaDSP - it must stop the excessive current draw until I reload firmware and start again. This certainly explains why the clocks stop, because their reset state is disabled.

I haven't figured out why the timing is random, but I'll be pulling the board apart to isolate the problem.

I didn't all signals availble for probing on this six layer board, so I missed that the Reset line was being pulled low. I had to expose some vias and solder probe wires, but eventually found the issue.

Further diagnosis shows that linear regulators in my first design cannot handle the required Wattage dissipation. The random timing may be due to ambient temperatures, or stored heat in the regular itself.