DSP monitoring register

Personally, I just read back a register or DC block I know the value of. If it works, I assume it's running.

I tried using a DC block, but since the RAM is not cleared under reset this doesn't work...

Fixed it for now using a sawtooth generator at a very low frequency connected to a DSP readback block and just checking for changing values.

If anybody has a more standard approach or brighter idea please let me know.

Hello,

The simplest way to check would be to read back the core status register (on the ADAU1452, for example, 0xF405). This will tell you if the core is running, paused, stalled, sleeping, etc. For the 1452, refer to page 117 of the datasheet for more information.

Hope this helps!

Tyler

Hello Tyler,

I know the topic is a bit old but I have a question regarding the different states of the core. We have our own design which runs in selfboot mode from a EEPROM connected to the SPI master port. The communication to the outside is handled via slave I2C interface to a main MCU. We are monitoring always the states of PANIC_CODE, HIBERNATE and CORE-STATUS. Sometimes we get the 0x0004 for the CORE_STATUS, which is stalled. Of course I know what running and paused mean but especially stalled and sleeping is not 100% clear for me. Could you explain me how the different states can be triggered?

Dont get me wrong the systems runs and we can control everything with the main MCU. But we have some random problems with the selfboot process, especially if we power up the full system (cold start). Then the DSP starts with wrong behavior and it is really hard to identify these random errors. Do you have any experience with that? If needed I can explain this issue more in detail.

Questions regarding CORE_STATUS:

Stalled:

How gets the processor into this state?

Is this triggered by writing or reading o lot of data from the processor?

Is this a circital state, so must the processor resetet and selfbooted again?

Sleeping:

How is this state triggered?

Is it normal that the processor toggles between SLEEP (0x0003) and RUNNING(0x0001).

Is it possible to disable this toggling, to have only 0x0001 which indicated a stable running?

Is this state called if selfboot fails?

PAUSED:

How is this state triggered?

Is this state called if selfboot fails?

Is this a circital state, so must the processor resetet and selfbooted again?

Many thanks in advance and best regards,

Eric

Hello Eric,

EricSa said:

Stalled:

How gets the processor into this state?

Is this triggered by writing or reading o lot of data from the processor?

Is this a circital state, so must the processor resetet and selfbooted again?

This is in the rare event that there is more than one system writing to the same memory location and so the result is to have the core wait one core clock cycle to avoid the contention. It does not happen often and usually is only one clock cycle. This is the core clock cycle running at ~300MHz so it is a short time. If you are writing a lot of data via the slave port it can trigger this.

No, you do not have to reboot the processor. It just resumes where it left off and there was one fewer clock cycle in that particular sample period.

EricSa said:

Sleeping:

How is this state triggered?

Is it normal that the processor toggles between SLEEP (0x0003) and RUNNING(0x0001).

Is it possible to disable this toggling, to have only 0x0001 which indicated a stable running?

Is this state called if selfboot fails?

This happens every sample period. Remember that the DSP program is executed every sample period then it waits for the next sample period to start all over again and process the next sample. So usually there are a lot of extra capacity of instructions per sample that are not used. So the last instruction in the DSP program puts the core to sleep. Then the interrupt for the next frame wakes it up to start processing the next sample.

This is very normal and desired so it is not a problem. If selfboot fails then there is no program loaded so no program pointer to start at so it enters the sleep mode after three attempts to boot and there is nothing to wake it up since no program is loaded. So in that mode a reset is required. However, differentiating between a failed boot or simply waiting for the next frame is not possible with this register alone. So it is really not terribly useful. It was more for our diagnostic work during development.

EricSa said:

PAUSED:

How is this state triggered?

Is this state called if selfboot fails?

Is this a circital state, so must the processor resetet and selfbooted again?

This one I am not certain if and when this is used. I think this was another diagnostic command. This allows us to put in a pause command in the code and then extract the exact state of the core at that point. It stops the clocks to the core to freeze it until it is restarted. You should not be seeing this code during normal operation. I don't think any of the standard software is using a pause command for anything. So I guess you should reboot. Let me know if you have seen this code and I will ask the designers and programmers for more details. From what I know right now you should not be seeing this state.

Regarding sensing if the core is running. There are many different techniques found is other posts on the forum. You can simply set a GPIO port to a zero in your program. The pin is high in reset and when the program starts to run it will set it low.

The technique of setting up a heartbeat with an oscillator is another method.

Ramps to see if it is changing is good.

You can also setup a DC cell to hold a value. This is handy because it can hold certain numbers you define for things like software versions. Read it in to see if it is valid data. It is a 32 bit number so you can always have one byte be something like 0xAA to make sure the data is not scrambled and then the lower bytes have a version number which may be different from unit to unit.

For your problem with unsuccessful booting. There can be several causes. The SPI speed setting might be a little high and there can be PCB layout issues such that you might have signal integrity issues so sometimes you get some errors. So that is something to look into. If the SPI is set close to the max of 22MHz? ( I think that is the max) then you may have a problem. from time to time.

Are you using a reset generator in your design? That is always a good idea. It allows time for the power supplies to stabilize and the master clock to stabilize before starting to try to boot. Since you have an MCU, is one of the GPIO ports connected to the reset of the DSP? This way you could hold it in reset for a little longer when booting up from cold.

Dave T