SigmaStudio Seems Unable to Update Self-Boot EEPROM Indirect Parameter Access Table on ADAU1452
Thread Summary
The user encountered an issue with the ADAU1452 where the Indirect Parameter Access Table (IPAT) reads back stale data after updating the DSP EEPROM. The solution involved disabling the EEPROM self-boot during reprogramming and ensuring the MCU strobes the reset pin correctly, holding the reset for 10ns and waiting a few seconds for the DSP to boot up from EEPROM before performing I2C read/writes. The user also noted that the IPAT updates correctly when creating a new SigmaStudio project for the first time.AI Generated Content
I am having a difficult problem with the ADAU1452 part in our product using the Indirect Parameter Access Table. I am using a DC block to store a version number. I must query this version number via I2C when our MCU boots and perform error checking. However, when I upgrade our ADAU1452 DSP and use the "Write Latest Compilation through DSP" feature to burn the update to the DSP EEPROM, the IPAT does not read back the new version but keeps pulling the old version number from previous programming. From my testing and observations, it appears that IPAT is stuck presenting stale data and the program is not triggering IPAT to be updated.
When I do the "Compile, Link, Download" to the DSP RAM the IPAT reads back the correct value, but after rebooting the DSP and allowing DSP to self-boot from EEPROM the IPAT will always read back an old value from a previous EEPROM programming.
If I bypass IPAT and directly read the DC block, the DC block will show the correct new version number (even when self-booting from EEPROM). That gives me confidence that the DSP IP is being flashed to EEPROM and is being self-booted upon RESET and the problem is isolated to IPAT.
It is very important for our product to use the IPAT for this version check so that I can always guarantee that the version query goes to the same subaddress because our DSP IP is radically evolving and our DSP EEPROM and MCU are independently versioned and programmed so I want to always be able to verify that all required versions are found. If I have to directly read a DC block with a random subaddress then I cannot do version checks against older or newer DSP images because my MCU won't be able to find the proper subaddress and worst case the MCU could read a subaddress that returns real data that is not a version which is not good.
This bug is very easy to reproduce. I have attached two ADAU1452 projects. One has a DC block with the integer value "0" and the other has a DC block with the integer value "1". Programmer the ADU1452 with either project, does not matter, and "Write Latest Compilation through DSP". Power cycle the chip (this step is critical because SigmaStudio reloads the SigmaDSP RAM after an EEPROM write). Load the IPAT window and read back the value of the DC block. It should be "1" or "0" depending on what was programmed.
Now open the other project and re-program the ADAU1452. Leave the IPAT window open and power cycle the chip. Click READ in the IPAT window. Observe that IPAT reads back the wrong number! This is an absolute curse for us and is causing major issues for this product.
ADAU1452_DC0.dspproj
ADAU1452_DC1.dspproj
Edit Notes
Added schematic of our SigmaDSP and EEPROM circuit. We program the SigmaDSP via I2C and the 8 Megabit EEPROM is directly connected to the DSP via the private SPI path (similar to ADAU1452 eval kit).
[edited by: compy386 at 9:22 PM (GMT -4) on 2 Aug 2023]
Audio Signal Processors
adau1452
sigma studio
Audio Products
software
4.7
SigmaDSP Audio Processors
SigmaDSP
Show More
One of the interesting observations when reproducing this issue is that the IPAT EEPROM seems to get updated when creating a totally new SigmaStudio project (the first time). The first time I create a new project, setup the IPAT, and perform the "Write Latest Compilation through DSP" and then reboot the DSP the IPAT seems to take the update. If I modify the project and do another "Write Latest Compilation through DSP" then IPAT seems to stay stuck and the previous programming.
Hello compy386,
I am not able to test your actual project right now but are you compiling before you try to write to the EEPROM? It is the latest "compilation" that is written so if you make a change you have to recompile then program the EEPROM.
Also, are you turning off the "selfboot" while you are updating the EEPROM? I would recommend you do that.
Dave T
Thanks for the reply, Dave.
Hello compy386,
Sorry for delay in response.
I guess I can assume what you are trying and getting. I have tested this here.
You are setting DC=1 and compile it after that you open the IPAT window and change the DC value to 0 in runtime. So, it's currently giving latest output which is running. But when you write to EEPROM without recompiling, the old value is stored in the EEPROM.
Exactly as Dave said, the latest compilation is what is written to the EEPROM. The latest runtime changes after compilation won't reflect in the EEPROM. So, you are reading the old value which is there at the time of compilation. To understand this, you don't need to use the IPAT window, just write a 1 from DC block to a GPIO to led and compile it. Initially the LED will glow and if you change the DC value to 0 in runtime, you can see the LED turns OFF since it's updating the value in runtime.
Now if you write the code to the EEPROM (without recompiling) by using '"Write Latest Compilation through DSP" and then you self-boot it. Now you will see the LED is glowing though you turned it off in run time after compilation.
Is that what you are trying?
Regards,
Harish
Dave, Harish,
I have attached a PDF of our schematic to the original post. We are talking to the ADAU1452 via I2C and we have an 8 Megabit EEPROM connected directly to the DSP's SPI channel (similar to the eval kit).
For my simple steps to reproduce I do the following:
Have a single DC block that is mirrored in the IPAT as a read-only.
Set DC block value to 32 bit integer 0.
Perform "Compile, Link, Download"
Open IPAT, readback value of 0 (presumably from DSP RAM).
"Write Latest Compilation through DSP".
Physically reset SigmaDSP chip.
Open IPAT, readback value of 0.
Set DC block value to 32 bit integer 1.
Perform "Compile, Link, Download"
Open IPAT, readback value of 1 (presumably from DSP RAM).
"Write Latest Compilation through DSP".
Physically reset SigmaDSP chip.
Open IPAT, readback value of 0.
IPAT presents incorrect value of 0.
Use MCU via I2C to directly read DC block (bypassing IPAT) and get value of 1.
I asked our hardware engineer to try jumping SigmaDSP to disable self-boot from EEPROM. He was able to do this. While self-boot was disabled, he tried to program the EEPROM and after a reset the IPAT still readback incorrect values.
Quick update: I changed how our MCU toggles the reset pin the ADAU1452. Originally, we were holding ADAU1452 in reset while MCU booted up. ADAU1452 did not seem to like this, especially after I tried to program the ADAU1452 EEPROM. My change was to let ADAU1452 boot normally, then have the MCU strobe the ADAU1452 reset. This seemed to make programming the EEPROM more reliable and consistent.
Related follow up question: are there best practices for how to strobe the reset pin the ADAU1452? How much time should ADAU1452 be held in reset and how much time should we wait for ADAU1452 to boot up from EEPROM before doing I2C read/writes to the ADAU1452?
Thanks!
Hello compy386,
It seems like you are doing everything correctly. It must be something simple we are both missing.
What is the size of your EEPROM?
Regarding your question about the reset.
This spec is in the datasheet: 10ns
as far as waiting for bootup. This will all depend on the program size. A couple of seconds would certainly be enough but you can do some tricks to know when the selfboot is complete. First I have to say you can read pretty much right away. It is writing that could cause issues if you write a value to a parameter before it is loaded from EEPROM then the value you just wrote will be overwritten.
I have seen people put in a DC cell and program it with a value like "1". Then have the program do a parameter write to change it to some non-zero number that is different like 3. Then if you read the DC cell and it contains a 3 then the program is running and boot up is complete. I have seen others read the output of an oscilator to see it changing. If it is changing then it is running. We only have a register to read that tells you that selfboot failed but it does not tell you that selfboot has completed successfully. It was an oversight by the original design team. The selfboot is handled by a state machine in firmware so it cannot be changed.
I will contact you for more Infromation soon...
Dave T
Dave,
Thanks for the follow up. Our EEPROM is 8 Megabit. I feel like I was over-aggressive on holding the 1452 reset pin low while it first powered on and this possibly tripped up the EEPROM self-boot feature somehow or left the EEPROM or SPI manager in a funky state.
I originally wanted to blame IPAT because IPAT does act funky sometimes, but perhaps it was just a side-effect of the SPI/EEPROM having real issues being programmed.
For anyone in the future looking at this issue: along with the other reset timing changes made above, we added the ability for the MCU to set the EEPROM Self-Boot pin to disabled (no self-boot from EEPROM) during the time the EEPROM is being re-programmed. It is a bit tricky since we need to tell the MCU to go into a special mode to disable self-boot while SigmaStudio pushes the new image into the EEPROM, but it does work reliably now.
Please log in to reply.