MCUdude / SigmaDSP

A versatile Arduino library for interfacing with the ADAU1401, ADAU1701 and ADAU1702 audio DSPs
GNU Lesser General Public License v3.0
169 stars 35 forks source link

Writing EEPROM bricks the DSP #17

Closed djamps closed 3 years ago

djamps commented 3 years ago

Hello,

I have had good success so far, except for writing new EEPROMs. While using ee.writeFirmware(), the write appears a success (it no longer attempts writes until version is increased), however the DSP now fails to self boot. I have to hook up a EZ-USB and rewrite the EEPROM from Sigma Studio to restore the program. I made 100% sure nothing else on the I2C bus is interfering and DSP is held in reset during write.

I tried to dump copies of the good and bad EEPROM contents but while Sigma Studio displays them without issue, it refuses to write them to files for some reason. I have attached my project files, generated from Sigma Studio 4.6, so hopefully that is useful.

ghetto.zip

djamps commented 3 years ago

I should also mention, removing the EEPROM and using loadProgram(dsp) instead doesn't work either. These two functions are the only ones I'm having issues with. The DSP control functions are working fine when self booted from a program written to EEPROM (or link compile download direct to DSP) via Sigma Studio.

MCUdude commented 3 years ago

Thanks for reporting. It may be the power shell script that is causing issues. Can you try to replace your SigmaDSP_parameters.h with this file and try again? SigmaDSP_parameters.h.zip

MCUdude commented 3 years ago

If this doesn't work, another thing you should try is a very basic program such as the 1_volume test sketch. This is a pre-compiled DSP project that I know works.

djamps commented 3 years ago

1_volume works, even after recompiling it completely. trying some more tests now.

MCUdude commented 3 years ago

1_volume works, even after recompiling it completely. trying some more tests now.

That good. This means that the files that SigmaStudio spits out works with the script.

The code that flashes the EEPROM is an entirely separate thing and has little to do with the loadProgram(dsp) function. If there where something wrong with the program loading, I would expect it to be related to loadProgram(dsp), not the EEPROM flashing. At the moment I only have a Mac available, so I'm not able to look at your SigmaStudio project at the moment. But try to remove some of the program blocks to see if you can make the problem go away. You can also use SigmaStudio to compare the contents of a "good" EEPROM with a "bad" one to see if there are any differences. There shouldn't be any, since E2prom.Hex is just converted into a C style array, stored in SigmaDSP_parameters.h, and written to the EEPROM.

djamps commented 3 years ago

I tried writeFirmware() for 1_volume but it seems to again brick the DSP/EEPROM.

I've attached my modified version of the compiled sketch (I needed to add a tone generator and control lines for the DSP on my custom board).

To be clear, this works fine using loadProgram(). Unfortunately due to other technical issues, I need to use an EEPROM.

1_Volume.zip

MCUdude commented 3 years ago

But you're able to get it to work if you flash the EEPROM with the EZ USB programmer? Try to compare the EEPROM content that's working with the one that's not working.

djamps commented 3 years ago

It looks like I've got two copies of E2Prom.Hex (original and modified). I am deleting my last post and re-testing.

djamps commented 3 years ago

I was successful in burning the EEPROM with 1_Volume, the only differences in the final dump were FF's instead of 00's filling the rest of the EEPROM. But it works.

However, it still doesn't work for my larger sketch. Once I figure how to save the EEPROM to file, I can compare. As of now, sigma studio refuses to save files using the "Upload to file" function. It will only display them on screen with no cut/paste ability.

MCUdude commented 3 years ago

If you know another way to dump the EEPROM let me know?

You can dump the EEPROM using an Arduino sketch and print it to the serial monitor, correctly formatted with for instance printf.

djamps commented 3 years ago

I may have found the issue, and it's in the board design. I stupidly tried to use A6 as a digital out on the 328P (for DSP writeback, which I don't even need), and as a result it was controlling D6 instead, which was pulling WP low and stopping selfboot. Once I confirm these initial findings, I'll hopefully be closing this issue in shame.

djamps commented 3 years ago

Confirmed design issue. Everything is working as expected now that the WP pin state is known/good. Excellent work on this library, it saves me alot of hassle with embedded DSP programming.

MCUdude commented 3 years ago

Great to hear you figured it out! I've used this library with some massive DSP programs, and never had any issues regarding flashing or controlling the DSP blocks. Great to hear you find the library useful! I've spent quite a lot of time creating it, so it's nice to hear it is being used by others.

The library is actually quite extendable, so if you crack an algorithm (shame on AD for making it so difficult!), it's pretty straightforward to implement the algorithm as a library function.

djamps commented 3 years ago

Indeed, it's written very concisely and easy to follow, I already extended it for controlling DC sources and non-slew level controls. I'm able to store an entire DSP program (1000+ instructions) and hundreds of lines of additional code on a 328P, so the efficiency shows! I'll send you a pull request soon! Thanks again for the great work.