ADAU1401 - Non-Selfboot mode and i2c
Hi everybody,
Linking the ADAU1401 with an external chip, i can read and write i2c command and it's work as long as the evaluation board stay in selfboot mode. I integrated the .h files provide by SigmaStudio. When i switch in non-selfboot mode, it's still works with the usb-i but not anymore with my soft/chip. And when i read or write i2c command, the i2c communication is ok but nothing happen after. I read again what i write just before and it match.
I also try with more timer after the start but it don't change anything.
Is there more register to write or test or command to do in non-selfboot mode than self boot mode ? Didn't find the good clue in the .pdfs....
many thanks !
Audio Signal Processors
adau1401
SigmaDSP Audio Processors
I have been thinking about this for a few days, and I really can't think of any special register writes that would be required especially in non-selfboot mode as opposed to selfboot mode. May I ask what particular operating mode you want to use?
For example,
Do you want to boot your ADAU1401 from the EEPROM and then control parameters from the external chip?
Do you want to avoid using self-boot entirely, and simply have the external chip boot the ADAU1401?
Also, have you read this application note about using the ADAU1401 in a self-boot system?
http://www.analog.com/static/imported-files/application_notes/AN-923.pdf
Thanks for taking times on this. I would like to completely avoid the e2prom and having a full external chip boot. I read the application note and it is for selfboot mode. So i can confirm it is working... but not really interested.
What i've done for now is an empty prog with sigmastudio, loaded in the e2prom and the DSP in selfboot mode. The DSP start and then i can load my prog and data from the external chip after.
Did i mentionned i used an external clock (provide by the external chip) !? I don't think the problem comes from here but who knows. of course, the external clock is running and stable before i send any command.
One thing that needs to be taken into account is the PLL lock time. I think the control port will not be fully able to access memory until the PLL is locked and ready. Maybe that is part of the problem. Are you able to insert a wait time into the beginning of your external chip's initialization program?
indeed, i add 2 (real) seconds after the clock started and before sending i2c commands. I try with few more and didn't change anything. I noticed that the i2c commands can failed with less time.
I have another suggestion. Would you try executing the default_download() function twice? It's possible that some of the writes are not functioning correctly on the first try. Maybe if you simply called the function twice, the "problem writes" would be resolved.
i'm little busy right now, i will try as soon as possible...
This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.
Thank you,
EZ Admin
Please log in to reply.