Post Go back to editing

error in DM0 Bank 0 and startup verification

Hello EngineerZone,

I have a question regarding the "PANIC FLAG", "ERR_DM0B0" and selfboot-startup verfication in ADAU1451.  I have searched for similar topic and also found one, but it is closed and was answered via E-Mail. So here is my problem.

I have a SigmaStudio Program (Version 4.1. Build 1, Rev 1761) which uses about 98% of DM0 and 85% of DM1 for delay-blocks in different channels. It is no problem to "Link compile download" the project. But when I press "Read All Registers" it indicates that there occured an "error in DM0 Bank 0". 

When I clear the Panic Manager and read all Registers again the error is gone. 

First I thought this is an problem of the USBi connection, but I also checked the "Panic Code" register 0xF428 by reading it with an connected MCU and I got the same result. My problem is, that I want to guarentee that the ADAU1451 runs correct after startup. My planed verfication should work as follows (ADAU1451 loads his programm via selfboot, MCU is connected to slave I2C):

1. Activate selfboot pin with MCU

2. Reset ADAU1451 by MCU 

3. Wait about 20ms (Pll locking)

4. Poll register 0xF004 until PLL_LOCKS

5. Wait again about 20ms (Selfboot process)

4. Poll register 0xF427 to check if an error occurs

5. Maybe verify a specific "DC Input Entry" block value by reading it to check if startup was successfull.

As describe before, my problem is that this "ERR_DM0B0" occurs and I dont know if i can simply clear this error of if this is crictical for the operation of the device. My second question is if there is a better way to verify that the safeload-startup process was sucessfull?

This is hopefully not too confusing and you can understand the problem.

Many thanks in advance,

Eric

  • Hello Eric,

    This is nothing to worry about. What these panic registers are for is reporting parity errors. When you reset the part and reload the memory, especially from a cold start. Chances are the parity bit is at a random setting. So the chances of you loading in the entire program with no errors is not likely. The parity bit is set once the memory has been accessed once. So the proper procedure is to clear the panic manager bit after loading the program and after it has started running. The purpose of this feature is to catch when memory might change a bit over a long time. Parameters that never change in a program may change after some VERY long time. All memory has a mean time to failure so this is to catch this issue should the product be on for many years without ever being turned off and restarted. Of course if there is some other random error that causes a parity error it will catch that too.

    So if you want to simply verify that the program loaded correctly and is running, there are a couple of other ways. One would be to have a square wave oscillator toggle a GPIO pin and you can test for that heartbeat.

    Another way is to use a DC cell, like you suggested, that holds a number placed in it during compile time. This could actually be a revision number for your software or product. Then connect the DC cell to a readback cell. Then once the program is loaded you read the readback cell memory location and see if it contains the number. The only way the number would be in that memory location is if the program moved it over to there.

    Dave T