"Check last compilation through DSP" not working on custom board using ADAU1467 and SigmaStudio

Hello Andreas,

I am not sure exactly what is going on. It does seem a little strange and it seems like you have checked things carefully. I downloaded your program and opened it up. There is a problem with it running on the EVAL-ADAU1467Z board because you are driving GPIO_6 as an output and on the PCB that GPIO is setup to be an input. It is connected to the output of a hex inverter. So I cannot get it to change the LED because it is an output fighting an output. 

So I changed it to out on MP24 and changed MP6 to be an input and it works just fine. Then I programmed the EEPROM and checked it and it worked fine. 

It is good that you are setting the selfboot pin low when you do this. I do not know what else could be going wrong? 

Here is my modified program. 

Poti-LED-DT-Edits.dspproj

Dave T

Sure, for the evalboard the GPIO has to be adjusted.

Dave, do you have any ideas how I could debug this more deeply to find the reason?

Some ideas:
1. Maybe the problem is cross talk from SPI Clock and MOSI into the MISO signal. Is there a way that I can adjust the slew rate and drive strength of these SPI M Bus pins when the "Check last compilation through DSP" feature is used? Maybe by running the SPI commands from PC to DSP from Sequence window and adding a few extra commands? Does this sound feasible for you?

2. The reason for using the "Check last compilation through DSP" is that I want to be sure that the programming was successful. Just writing the firmware does not give any feedback at all. There is no error or warning, if target is not connected to USBi or not powered by SigmaStudio. For development phase it is not ideal, but at least managable. But for production it is bad. But on the other hand maybe the check is not really required as DSP would not boot if somehting is wrong with the data in the EEPROM.

Is it correct, that the data in the EEPROM has a checksum appended and DSP will check the checksum when starting from EEPROM? So in case something went wrong in programming the EEPROM, DSP will not boot and signal this by a "panic".

3. All this programming of EEPROM via DSP from USBi seems to be a bit weak or unreliable.So maybe it is better, if we would change our custom board and forsee to programm the EEPROM differently.
What options do I have here?

3a: add additional path for the SPI signals from USBi directly to EEPROM and use another SS signal here. This would be in addition to the SPI_M connection from DSP to EEPROM. Of course I have to be ensure that both connections to do not interfere with each other.
Are there any pitfalls here? Is there a reference design available from ADI?

3b. expose SPI of EEPROM on a different header and use a third party adpter and programming tool. When doing so, DSP is hold in reset.
Are there any pitfalls here? Is there a reference design or recommendation for third party programmer via SPI by ADI?

Ideally I could fix the problem and could rely to the Write through DSP feature. Do you have any further ideas how I could debug this?

Hello Andreas,

You bring up valid arguments some of which others have brough up in the past. 

Comments based on your points you numbered:

1) There is drive strength registers for the master port pins. Of course it is only for the output pins and you have to write to the registers before you try to program the part. It will do not good to have the settings imbedded into the program file that is not run until AFTER you write to the EEPROM.  

So your comment about setting up a sequence file is a good way to add some register writes before the EEPROM is programmed. Remember that you can save these sequences into an XML file for later use. 

2) SPI is an issue because of no handshaking. However, most people want or need the fast bootup. The automotive companies brough this up so we added a special feature to do a checksum of not just the program in the EEPROM but all of the data and the program once it is loaded into memory. Not just when it is read out of the EERPOM. 

Yes, there are some provisions for error checking. There is the "AA" at the start of the EEPROM to say it is a program loaded and it is not empty. Then there is a checksum in the EEPROM file that is compared when it is read out of the EEPROM and if it does not match it does not run the program and stores an error code in the Software Error Code registers. The code that is stored is funny because it is the designers getting bored and being funny. The error code for a bad program in EEPROM is "0xBABE CAFE". 

However, this utility for checking the actual data in memory is a very good check to verify that it was all loaded correctly. Here is the into on how to use that utility.

CheckSum [Analog Devices Wiki]

If you use I2C this is really not needed. 

There has been some customers who setup things like analog switches or jumpers to allow the USBi to directly talk to the EEPROM and so you can use the EEPROM tools built into SigmaStudio or your own tools to program it. Yes, just hold the DSP in reset and the master SPI pins will be tri-stated and be out of the way. 

Just make sure that once it is programmed that the two comms ports will not be connected together afterwards. That is rather obvious so I think you understand that well. 

Dave T

Meanwhile I was able to fix my problem. The actual reason was a problem with the SPI communication from USBi to ADAU1467 on my customer board. The custom board uses smaller header than the USBi because of limited space. Therefor we use a custom adapter cable between USBi and custom board. This combination introduced problems on the SPI communication for MISO (ADAU1467 to USBi). Because of this the check feature fails, which it uses MISO. The problem was not so visible when using SigmaStudio to programm and tune the DSP on the fly. I found the problem when I tried to tune the pin drive parameters for MISO line. I saw that whatever setting I sent, reading it back always give wrong result. Looking at the MISO signal with a scope showed the problem. Especially if only 1 bit is set within a byte of a transfer, the MISO signal was crippled to a small peak. it looks like ADA1467 is not able to drive enough power to the bus.

The actual fix was to improve the adapter cable and make it much shorter. Still this works only with MISO line driving strength set to slowest. When I set it to Highest, MISO signal is again crippled. Actually I do not understand why, because Highest should even make it more robust. But nevermind.

In order to be 100% sure that SPI communication is not perfect I create a small SigmaStudio script that reads value of a DC obejct on the DSP setup by USBi multiple times and compares it to an expected value.
// #LANGUAGE# C#
//Read 32 bit value from a specific address and compares value with expected one.
//Usefull to test SPI read from DSP

long value;
const long soll_co = 0x01020304;
int count = 1;
int count_max = 200;
int addr = 0x0017;

ss.PrintLine(System.String.Format("Reading 0x{0:X4} for {1} times...", addr, count_max));

while(count<count_max)
{
    ss.ICRegisterRead("IC 1", addr, 4, out value);
    //ss.PrintLine(System.String.Format("read 0x{0:X8}", value));
    if(value != soll_co)
    {
        ss.PrintLine(System.String.Format("Missmatch on read #{0}: read: 0x{1:X8} expect: 0x{2:X8}", count, value, soll_co));
        return;
    }
    count++;
}
ss.PrintLine("no errors");