sigmadsp_fwgen for ADAU1466
Thread Summary
The user encountered issues when replacing an ADAU1452 with an ADAU1466 in a Linux-based SPI firmware loading system. The problem was resolved by modifying the sigmadsp_fwgen script to include page selection registers, which are necessary for the ADAU1466 due to its paged memory structure. The solution involved ensuring the Linux driver correctly writes to the appropriate memory pages for complex DSP projects.AI Generated Content
Hello,
For a few years now we have a system with an embedded Linux that transmits through SPI the firmware to an ADAU1452 DSP. The firmware is made from the exported .xml then transformed with the sigmadsp_fwgen into a binary. When the Linux starts, a driver (inspired from the ADAU17xx driver, which is included in the Linux core drivers) reads that binary file, sends it through SPI, and creates the ALSA controls. Everything works without any problem.
We recently tried to replace the ADAU1452 by a ADAU1466, because they are said to have mainly the same behavior and controls, just the ADAU1466 being more powerful.
When we execute the firmware loading process explained above, we encounter some issues :
If the DSP project is simple (pass-through with just a volume and mute control), it works as expected, sound outputs and controls work.
if the DSP project is more complex (with filters and compressors), there is no output sound, but core and clocks are still working.
From what we tested until now, just a FIR filter seems to be enough to create the problem. ASRC->SDOUT works, but ASRC->FIR->SDOUT doesn't. We don't know the full list of processing that cause this problem.
Do you have an idea what could cause such behavior ? Is there some specification for the ADAU1466 when generating a .bin from the project ?
Thank you for your time and help,
Richard
sigmadsp_fwgen
Audio Signal Processors
adau1452
Audio Products
software
spi
sigmaStudio 4.7
binary
SigmaDSP Audio Processors
linux
SigmaDSP
adau1466
Show More
Hello,
what can be added, we've been using a sigmadsp_fwgen and an ADAU1452 for years without any particular issues
Thanks for your Help
JB
Hello Richard,
Taking a program from the ADAU1452 and loading it into an ADAU1466 is 100% compatible. There is zero difference in the parts when the program is compiled for the 1452. I do it almost on a daily basis on my desk because I often use the 1466 eval board and I run 1452 programs on it.
If you did not change the DLL, what I mean is on the config page you drag out the ADAU1452 and connect it to the USBi GUI. If you kept the 1452 GUI and did not change it to the 1466 then it will compile and load in EXCACTLY the same. Zero difference and the parts are fully compatible.
In thinking about this, you might get into issues if you changed the DLL to the ADAU1466 DLL. Then if the program is fairly large the compiler would know there is more memory in the 1466 and it might place an object into a different memory location. Then your Linux driver would be going to the wrong memory location to control an object. I would have expected you to use the indirect access table to fix the location of the object and in that case it should not change even if you used the 1466 DLL as long as the IPAT table stayed the same.
By the way, the actual 1466 DSP core is exactly the same. It is not "more powerful". It is things around the core that were increased. Mainly memory was increased and a few other little things were fixed or improved but the core was not touched. The extra memory was done as extra pages which is why the 13452 programs will run on the 1466 with no changes. Because those programs will not try to use the extra memory pages. It is the other way around that is a problem. Take a 1466 program that uses the paged memory and try to run it on the 1452 and the memory does not exist.
Feel free to attach your project that is not working and I can have a look.
Dave T
Hello Dave,
Thank you for your feedback. Indeed both ADAU DSP are supposed to be 100% compatible but in reality because of the memory size difference, they are not. We found something. We need to do more testing but it appears our problem comes from the fact that adau1466 has 2 pages and memory is split into Upper and Lower sections. When converting the xml to binary, the sigmadsp_genfirmware looks only for registers data ending by "Param", so the second_page_enable register and the data DMx Upper and Lower section registers were not written into the binary.
After editing the python script to include those registers structure too, we managed to get our sound back.
Now we need to check if all the ALSA controls are in the upper or lower section of memory, and to adapt our linux driver accordingly.
Richard
Hello Richard,
You missed my points. You also did not include the detail that you did change to the ADAU1466 DLL correct?
If you take a program compiled using the ADAU1452 DLL it will NEVER try to use the upper memory so it is 100% compatible.
If you change to the ADAU1466 DLL then the compiler will use the upper memory if it needs to. Then when you export the system files it will include which page the control is located on. So yes, your driver needs to take this into account and change the page. Our convention is to always leave the page on page 0 and change it to page 1 to write/read from the upper page then change it back to page 0 after the transaction. It is just a cleaner way and it keeps another object from writing to page 1 when the last time it wrote was to page 0.
Dave T
Hello Dave,
I must say I don't know why you are talking about a dll. We didn't touch anything on the SigmaStudio software, our project works perfectly on the eval board from Windows so there is no problem about any dll. The problem is when we export the SigmaStudio project to a xml file, the page registers for each control isn't present inside the "Modules" structures.
Having a problem with a dll would impact the behaviour under Windows, flashing and controlling the DSP through SigmaStudio interface, which works very fine. I can indeed see the second_page_enable register being written 0 or 1 in the capture windows.
My problem is when controlling from an onboard linux (so no dll), with a binary file generated from the.xml only. Because the page isn't included inside the xml, it cannot be translated into the binary, meaning the linux driver, that knows only the binary, has no idea if a control is on the first or second page. So it cannot recreates the SigmaStudio behavior.
I'm currently working on a solution, doing some RegEx to find correspondence between the.xml and the *PARAM.h, that I can include into the sigmadsp_fwgen python script.
After analyzing the SigmaStudio capture traces with the eval board, I noticed we needed to manage the page selection register for each ALSA controls, that is not done in the base driver we used (adau17xx) and it never bothered us because adau1452 doesn't use paged registers.
It also worked on simple project because everything was on the first page, so no need to change the page.
After including the associated page for each parameters in the binary by modifying the python script sigmadsp_fwgen and write the page registers each time an ALSA control was changed, we managed to get back our control on the DSP firmware and successfully set the volume, which was the reason why we didn't have sound.
Richard
Please log in to reply.