SelfBoot SPI EEPROM flashing via I2C


I have an ADAU1467 eval. board with 25AA1024 SPI EEPROM connected via USBi to SigmaStudio 4.6 (rev 1812)
Everything works fine while Hardware Configuration USB is set to SPI (SPI 0x1 ADDR0)
So I can write a program to ADAU1467 directly, also can “write latest compilation through DSP” (with SelfBoot switched temporarily off on the board) and have the same program running after Reset/Restart.

However if I switch the connection from SPI (SPI 0x1 ADDR0) to I2C (I2C 0x76 (118)) I can only update the program in the processor successfully, but can’t write the compilation to EEPROM.
Obviously I switch SelfBoot off before performing “write latest compilation through DSP” (as in the “SPI mode”), the writing finishes without errors. but after switching  SelfBoot back on and Resetting the board, the processor boots old program (previous EEPROM content)

I realize that “write latest compilation through DSP” means loading a “flashing stub” into the processor first. Unfortunately I can’t find any details about the stub capabilities, i.e. whether the stub can write to (master) SPI connected EEPROM from (slave) I2C.
The I2C connectivity itself works fine though. So the program can be written to the processor, but never to the EEPROM.

I tried to tweak Multipurpose1/Secondary I2C (just in case) – no effect,
tried to add/remove/configure EEPROM in HarwareConfigiration/Config – no effect. The problem remains.

While connected via SPI I had  USBi’s “SPI 0x1 ADDR0” connected to ADAU1467 and “SPI 0x1 ADDR0” connected to E2Prom (the latter looks redundant for a reason)
While using I2C I have USBi’s I2C 0x76 (118) connected to ADAU1467, but can’t choose the same for E2Prom (SigmaStudio doesn’t allow to choose the same I2C address), so I tried different I2C addresses, but without any EEPROM flashing effect. The program can be written to the processor directly though.

So the questions, if I might, whether SPI EEPROM programming is supported via USB/I2C and how it could be configured. I’m planning to use an MCU with I2C later to make the program changes available on autostart, so ability to change EEPROM would be very desired

Thank you,

  • Trying to reformulate the question.
    How the stub that is loaded into the processor before “write latest compilation through DSP” and implements the “through DSP” is constructed

    - the stub has a buffer to read data from the slave interface and then writes the buffer to (master) EEPROM
    - the stub just traces the slave interface data lines and then just replays the lines states to the master interface. This would mean the ability to flash SPI EEPROM from SPI slave and  I2C EEPROM from I2C slave only. So never SPI from I2C and I2C from SPI

    Thank you,

  • +1
    •  Analog Employees 
    on Feb 19, 2021 9:59 PM in reply to SergeG

    Hello SergeG,

    The capability of the DSP you can certainly do this. The slave port format and the master port format are separate things. So you can communicate to the DSP using the I2C format and the master port can be setup to be SPI. The program that is loaded does not just copy the line states. The data coming into the DSP from the slave port is loaded into the DSP. The DSP does not care what the comms format was, it is only data. Then it sends it to the master port. The master port settings do not know anything of how the slave port is setup. It is a different module in the silicon. So at that point the DSP sends it the data and the master comms module will send out the data using the format it is setup to use. 

    So if this is not working then it might be a bug with how it is all setup. It is not easy for me to test this on the bench. I know others have done this in the past. So when you start the programming of the EEPROM, are you setting the EEPROM Property window to SPI? 

    Dave T

  • Hello David,

    Thank you for navigating me to the problem origin.
    It was definitely my fault, I just was not attentive enough with the (highly integrated)  UI.
    It works fine now.

    Thank you once again,

  • 0
    •  Analog Employees 
    on Feb 23, 2021 7:13 PM in reply to SergeG

    Hello Serge,

    Glad you found the problem! 

    Dave T