ADAU1452 selfboot eeprom commands

Hello EricSa,

Great detail on this post. You win for the well done post of the week contest! :)

I do not have all the answers right now, and a few of these may be difficult to obtain the info and might start getting into proprietary stuff, but most of this I can answer for you. I will be open when I do not know the answers.

SigmaStudio does a lot more then it needs to when you compile a project and also when you perform this programming of the EEPROM through the DSP. The reason is that we cannot assume the state of the DSP at any time. It could have just powered up but it also could have a program in it running. So this is why you see it being placed into hibernation and killing the core etc. when simply performing a soft or hard reset would be all that is needed. This is why we clear the memory etc. You do not need to do this and when you write in a program you do not have to have all the memory cleared. The only side effect is if you are using the panic manager you will get some memory panic codes due to the pre-fetch of the core accessing memory above the end of the program that is uninitialized and may or may not have a parity error in the random value it holds. So when you want to load in the program that writes to the EEPROM, all you should have to do is reset and write the program. To answer question A1, you will have to initialize the PLL if you do toggle the reset pin.

You do want to mute the audio in your product outside of the DSP. Clocks will be going away to the codec/converters etc., so look over your design to be certain that you are not going to make any loud noises or damaging signals happening when you do this.

Questions B1 and B2, You should not have to clear out the RAM. It is a good idea to do for a program that is going to run days at a time in your product but for this temporary program it is not needed.

C: Yes, After loading in the program you start the core.

D1: NO, I do not have it easily obtainable and I may not be able to post them. These instructions are directly controlling the SPI and I2C design module that is part of the design of the chip. This module is from our library of reusable IP and so I may not be able to get or give out any more info.

D2: I do know that the SPI and I2C speeds are controlled in a non-intuitive way by using clock dividers etc. So the numbers you use are not going to be the resulting frequency. I will look for some info on it. I think you understand that this is for the speed for writing and reading from the EEPROM during programming only. Not during the selfboot operation.

D3: No, this is not defining the header at all in the EEPROM. Keep in mind that some of this work is done by programmers and they name things in a way that makes sense to them. I think this variable location is not just the number of bytes of the address but it may include the instruction byte. Because the SPI state machine in hardware just needs to know how many bytes to send out before it sends out the data or reads the data. It will not care what is an address and what is an instruction to the EEPROM. Since it looks like you are using a 25AA1024 then it will have a 3-byte address and a 1 byte instruction.

One other thing that is good to add here is that the block structure of the program stored in the EEPROM cannot be changed. What I mean is that the selfboot hardware is a state machine programmed into the silicon and is not able to be changed at all. It does not reside in any FLASH memory or anything like that. It does not pick up any code from the DSP. It just boots up and starts loading in and it is the information in the header that will then cause the SPI read to change speed etc. The selfboot engine itself we cannot change. It is set in stone... well, set in sand. :)

D4, I sort of answered this earlier. I am not 100% certain why, I will see if I can find that info.

E: I do not know why it reads in the first few bytes. Perhaps to see if the EEPROM is already programmed? If you give it a new erased EEPROM does it then skip the Erase? I had never noticed this detail.

F1: Usually SigmaStudio takes care of all the delays but I do not see that here. So it may be build into the SPI port code. If you do not see a Delay instruction then the hardware in the DSP comms port will take care of it.

G1, Another good question. I think the comms hardware is involved in these writes. There may be more in the DSP program that was written into the DSP but I do not see SigmaStudio actually executing a delay command. It just sets up the transfer and says "Go!" by writing the page size. The delays are most likely in the DSP assembly code you loaded in and called the Pipe program.

H1: Yes, you are correct that SigmaStudio loads back in the original program that was loaded on the screen so that the user can continue to use SigmaStudio. This is not required in your case and I think you would want to boot up directly off of the EEPROM as a verification. If you do not see the program running in a timely fashion then you can trigger and error and try to program it again. So you certainly can raise up the Selfboot pin and toggle the reset line.

Sorry I cannot answer everything but I will talk to a few people to see if I can get more info. I also have some notes on a few aspects of this to search through.

Dave T

Hey Dave,

many thanks for the also detailed and fast answer. You helped me a lot by describing which command is necessary and which not.

Regarding Pop-Noise:

This should be no problem. We can mute the connected DAC before we trigger the update process.

Regarding D1-D4:

I expected that this will be hardest part to find out :) and I am also okay with your answer that this is IP. But if you get some additional information from your colleagues and if you know which is IP and which not, please let me know. Every little detail helps to understand the procedure.

Regarding E:

If the EEPROM was erased before SigmaStudio triggers the same command but the EEPROM replies with 0xFF, 0xFF, 0xFF, 0xFF.

Maybe it is just to see if the EEPROM replies and is accesable (It is the first communication command to the EEPROM)?

Regarding G:

Okay. But here is one question if the front-end does not take care of delays between page writes:

If I send the Page-Address and Page-Data to the DSP this information must be stored inside DSP-RAM because it is first triggered by sending the Page-Size, right? What happens when I send the next Page-Address and Page-Data immediatly to the DSP? Can it happen that the previous Page-Data/Address will be overwritten? Are there 2 buffers? The Param-Address is always the same. Or do they expect that the transmission to the DSP takes longer as the EEPROM write delay?

Regarding H:

Yes you are right we want to boot directly from the EEPROM after the update is ready.

Best regards,

Hello Dave,

question on the same topic, so I thought I'll keep it in same thread.

How is the write through procedure handled by the USBi? According to eval board schematics there is no connection between USBi and self boot pin. There is none connection on my board as well, and I can program the eeprom from Sigma studio with eeprom write-through. So under which condition we do need not to bother with self-boot pin?

Hello Pitrsek88,

I might be a bit confused as to what you are asking about. So excuse me if the answer is not what you expect.

You are correct that there is no connection to the actual selfboot pin and the USBi. The person who wrote this original post had a GPIO on their uC to control the selfboot pin.

I have found in my little projects I have done that programming the EEPROM through the DSP would often take two, or three tries before the program was actually written. What I found out was that if you have the Selfboot pin set high, (Selfboot Mode) and you try to program the EEPROM through the DSP, SigmaStudio will send a reset command to clear out registers etc, and load in the pass-thru program. If the Selfboot pin is high and you send a reset, when the DSP comes out of reset it will try to self boot. It will try three times then stops trying if it fails to see the correct first byte or the checksum is not correct. Meanwhile, when the DSP is trying to load in the program SigmaStudio is trying to load in a program as well! This does not work well most of the time. I am surprised it ever works. Once I realized this I made provisions for setting the Selfboot pin to ground and then it loads the EEPROM pretty much first time every time.

In the past I was told that it works best if the EEPROM was cleared first. This helps because the first byte is zeros so the selfboot fails much more quickly. This is where the long delay SigmaStudio puts into the bootup routine comes in handy.

So if you do not have a switch or a jumper to take the DSP out of selfboot mode, then you may run into this issue. Clearing the EEPROM first might help you most of the time. If this is for new systems where the EEPROM is blank then you do not need to clear it. In future designs I will be using a transistor connected to the 5V line that is on the USBi connector. I will do some level translation and then using that signal to drive the Selfboot line. Perhaps a FET device would work better? The point is that it would automatically remove the selfboot when the USBi is attached. You can still selfboot if you like by lowering the 5V line from SigmaStudio. This might be done when you want it to boot with the EEPROM but then do a link/compile/connect to monitor the program and control objects in the DSP. So you do not lose that capability.

Others have done custom cables for the USBi such that plugging this cable in will place ground on the selfboot pin.

So these are the conditions I have noticed that causes problems and when it was manageable. I do not know your situation and your product as to what will work for you. IF you need low-skilled workers programming many units a day you might think about doing something on your next hardware revision.

I hope this helps,

Thanks!

Dave T

That's some great info! That was exactly what I needed to know. I knew it somehow works without. I'll update next revision of the board. Thank you Dave, your answer is much appreciated!

Cheers,

Pitrsek