Post Go back to editing

[Bug Report] ADAU1467 Interface Write creates Self Boot failure

Hi

Having spent many hours trying to understand what was going wrong, I now have a minimum project to demonstrate this failure.

Simply put, the existence of an Interface Write block prevents Self Boot. Take the following trivial example, the oscillator is simply to produce an output that tells me all is well, and the DC block is a substitute for my volume control GPIO configuration : -

If the Interface Write block is removed then 'Write latest compilation through DSP' works perfectly, and a tone can be heard.

With the Interface Write block in place Link Compile Download works perfectly, however 'Write latest compilation through DSP' appears to work ok, but doesn't produce a tone.

From earlier tests using SPI Read I can see that the Interface Write does successfully write to the correct EEPROM address when using Link Compile Download (The WriteAddress defined in the parameters)

I'm using I2C to connect to the board, and SPI EEPROM, functionally equivalent to the EVAL board from this perspective.

So, it looks like a bug to me, does anyone have a workround?

Thanks in advance

Jonathan

ADAU1467 Interface Write Tests 0.2.zip

  • I think I understand what's happening. The interface write is choosing a memory address within the section of memory used to self boot. This in turn means that the interface write changes the checksum, and prevents it from self booting. As there is no way to manually configure the address used it is not possible to use an unused area of the EEPROM, i.e. a higher address.

    Anyone from ADI, any chance of changing this behaviour so that it can be configured to work?

    (Or failing that, tell me what I'm doing wrong!)

  • Hello Jon_R,

    I worked on this for a while today. I found that it works just fine with the ADAU1452 DLL instead of the ADAU1467 DLL. 

    What is happening is that the compiler is not zeroing out the checksum in the hex file. My quick look at the different hex outputs I can see one has the checksum and the other does not. If you read the seflboot section of the datasheet you will see a discussion of the footer which is the checksum and if it is zero the DSP selfboot program will ignore the checksum and run the program. 

    So with the ADAU1467 DLL I can run the program and it boots fine. As soon as I change the index to a non-zero value it does not boot. Then what I do is recompile the program but I do NOT write it to the EEPROM. Then I change the index back to zero and then do a reboot and it works. So the checksum is changing and the DSP does not run the program because it does not agree with what is in the hex file footer. 

    Here is the end of the hex file of the ADAU1467:

    You can see the end of what I highlighted is the checksum.

    Here is the hex file from the same exact program using the ADAU1452 DLL :

     

    As you can see the checksum is all zeros. 

    So if you could identify where the end of the EEPROM data is and change the checksum to zeros it will work. 

    I will report this bug but it will be a while before it is fixed. 

    The problem is how to get an edited hex file into the EEPROM on your board. I assume you do not have direct access to it?

    Dave T

  • Hi Dave

    Thanks for looking into this.

    You assume correctly, I don't have direct access to the EEPROM on this board, only via the DSP.

  • Hello Jon,

    OK, so here is a way to do it. It is a bit clunky but it will work around the problem for now. 

    1) Click link compile download on your project. 

    2) Click on the red "X" on the Capture Window to clear out all the data in the Capture window.

    3) Go to the hardware config tab in SigmaStudio and right click on the DSP GUI and write latest compilation through the DSP. Click all the "OK to erase" and all the other warnings for writing to the EEPROM. 

    4) Now the capture window will be full of information. Scroll all the way to the top and click on the first entry. then scroll all the way to the bottom and "Shift-Click" on the last entry to highlight the entire list. ( If I remember correctly CTRL-A does not work in this window...) 

    5) Right click on the highlighted area and select "Add to Sequence" . It will look like this:

    The Sequence window will open up just to the right of the Capture window. 

    Now when you click on the Download Mode to Hardware button it will program the EEPROM with all the program you just loaded into the EEPROM. But, do not click on it now. We need to modify the program first. 

    6)  So now the trickier part. In this capture there are three basic things going on.  The first is to load in a program that is basically a data server between the slave comms port and the master comms port. 

    Then once this program is running it sends the EEPROM data in packets based on the size of the EEPROM page sizes. Then once it is complete it resets and reloads the program that was previously compiled and running from your schematic. 

    So go to the top and you see the core being killed and restarted and the PLL being setup. 

    You see all the SOUT registers and serial registers then you see Program, DM0 and DM1 data. This is the pass-thru program. Then you see it start up this program. 

    Then you see the master port being setup then you start to see the Page Address and Page size commands. This is your program hex file being loaded into the EEPROM. It looks like this:

    My test program was short so this is all of it:

    Notice the lines that have large blocks of data that are 256 bytes long. This is the data. 

    Click on the little plus sign on the last large packet. This will be the end of the EEPROM hex file. 

    On my test program almost all of the last 256 byte page was zeros so the program end was at the start of this page. So find checksum which is the last 8 bytes of the hex file. 

    Here it is on my file:

    Everything below this is all zeros. So this is the footer which is the checksum.

    Click on the data and change it to all zeros, Here is how it looks when I only had the last byte to change:

    So once they are all zeros you are done. 

    Now, write this to the EEPROM by clicking on the Download Mode to Hardware button I described earlier. 

    It happens really fast. The EEPROM is loaded and ready to test. Reset the DSP or power it down and let it reboot and it should work. Then change the interface registers so it writes to the EEPROM and then power down to reload it. It should load up again but this time with the updated setting. 

    You can save this sequence in a file if you like. 

    Sorry this is so long but I wanted to detail all the steps. 

    Dave T

  • Hi Dave

    Thanks for all the effort you've put into this, I'll get it tested

    Jon

  • Hi Dave

    That's fantastic, thanks, I can now get a test version to hold a volume level, surviving a reboot.

    Really appreciate the detailed explanation, it's helped me understand how it works as well as giving me a workaround, much appreciated.

    Kind regards

    Jon

  • Hello,

    Thanks for this. I understand up to the clicking on the Download Mode To Hardware button. The then EEPROM is loaded with the correct program. I don't understand why should I reset the DSP twice and what registers should I change between. When exactly should I switch the button "selfboot" ?

    In my case the DSP stops to communicate with EEPROM when I switch the secondary I2C from MP2 and MP3 to MP24 and MP25 (I use secondary I2C for communication with codecs ADAU7118 and I need MP2 and MP3 for SPI communication with EEPROM).

    Thank you in advance.

    Best regards

    PH

  • Hello PH,

    I am not sure exactly what you are confused by but I will give it a shot. 

    I am using the sequencer to capture the program that transfers the EEPROM image from what SigmaStudio. So with that capture we have the actual program that is being sent to the EEPROM. So I show how to go in and change the program.

    So then clicking the "download" button will transmit the entire sequence and program the EEPROM. You have to then turn on the Selfboot and hit reset to actually boot up from the EEPROM. When programming through the DSP the DSP is reset, if you have the selfboot on then SigmaStudio is trying to program the DSP while the DSP is trying to boot off of the EEPROM. So you have to turn off the Selfboot. If the EEPROM is empty or the stored program is really small, you may not see this clash but if it is a long program it is an issue. 

    Now on to the MP pin issue. 

    It is my understanding that the blocks that communicate using the master port will configure the port every time it uses it but I am not certain if this includes the registers for the MP pins? 

    What is the timing of your writes? Do you need to write constantly to both? 

    Can you share your project? I will have to do some research on this and it would be great to see what you have setup.

    Thanks,

    Dave T