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:
| page 1 | page 2 | |
| 0000-4fff => | DM0 0000-4fff | DM0 5000-9fff |
| 5000-5fff => | DM0 5000-5fff | invalid |
| 6000-afff => | DM1 0000-4fff | DM1 5000-9fff |
| b000-bfff => | DM1 5000-5fff | invalid |
| c000-efff => | PM 0000-2fff | PM 3000-5fff |
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:
- ADAU1462, ADAU1463: 0x3000 for DM0 and DM1, 0x2000 for PM
- ADAU1466, ADAU1467: 0x5000 for DM0 and DM1, 0x3000 for PM
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.
minor formatting and clarification
[edited by: matthijs at 3:47 AM (GMT 0) on 20 Jun 2019]
