We are working on a revision of our hardware using the ADAU1462-300 instead of the ADAU1452 we currently use. During initial testing however I discovered that it appears to behave like an ADAU1466 even though the part marking says ADAU1462WBCPZ300. Specifically, it appears to have 24Kwords of program memory and 2×40Kwords of data memory, and I've empirically determined the SPI => core address mapping to be as follows:
Although the ADAU1466 is code-compatible with the ADAU1462, the parts are not quite compatible from an SPI-programming point of view due to the difference in address offset applied for page 2 (SECONDPAGE_ENABLE=1) according to the documentation:
This subtle but important incompatibility means that a device that behaves like an ADAU1466 but is marked and sold as ADAU1462 should probably be considered a production defect? It also leaves me with questions on how to deal with this issue:
1. Is there an easy way to identify ADAU146x variants via SPI?
There don't seem to be any documented registers for this purpose, although I've noticed there are some undocumented ones in the range f800-f815, some of which at least differ from the ADAU1452, suggesting they might be of use for identifying device variants.
2. Does the memory map of the ADAU1462 agree with that of the ADAU1466 on the first page?
Notice from the empirically determined memory map how page 1 is not actually limited to the first half DM0/DM1 (0000-4fff) but allows access to the first 24Kwords (0000-5fff) of each. If this is also true for the ADAU1462 then all of its data memory can be accessed via page 1, which would also mean that any application (including SPI programming/control software) written for the ADAU1452 would also work with the ADAU1462 without any modification. This backwards compatibility would be extremely helpful.
If this is true for DM then the same question would go for PM: is page 1 on the ADAU1462 limited to the first half (8Kwords), or can the first 12Kwords be accessed at c000-efff on the first page? The former already suffices for ADAU1452-compatibility, but the latter would of course be nice to have. It would mean all of the data memory and 75% of the program memory of the ADAU1462 can be used without ever having to touch the SECONDPAGE_ENABLE bit.
Hello Matthijs,
There is no manufacturing defect. These are built from the same die and the memory is there but untested and not guaranteed. We only test the memory and features advertised for the smaller parts. There is a possibility that in the future it might not be there so the extra memory is also not guaranteed to be available in the future. As long as you use the correct processor GUI in SigmaStudio then the memory will be properly used.
Regarding the memory map. Table 56 and 57 in the datasheet outlines the differences however, I think it is wrong. We discovered an error and fixed it in SigmaStudio so the memory is there and available. Ken will be back in the office in a few days and will be able to give you more details. That said, if you use the Export System Files to obtain the addresses of the parameters in memory then you will know how to address them from the SPI port. We did recently fix the export feature to include the page number in the output files.
Dave T