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.
I finally have access to eZone again. Below is a better graphic of the correct memory map for the ADAU1462/63. As you say, references to page one being the "lower half" of memory are incorrect. I am working on updating the data sheet, but it will be a while before the revision is complete as there are a number of errors. My apologies.
I think you will find that writes to the slave control port in the address range 0x5000 to 0x5FFF do have a mapping in data memory, but not an exclusive mapping. Writes to other addresses may alias to the same block of memory. That is why we strongly recommend against writing to those addresses.
Regarding the generated code, the SigmaStudio team is revisiting this. I'm not sure of the status in SigmaStudio version 4.4, but I do know that the team is checking to make sure that it conforms with this map.
Ken.M said:I think you will find that writes to the slave control port in the address range 0x5000 to 0x5FFF do have a mapping in data memory, but not an exclusive mapping. Writes to other addresses may alias to the same block of memory. That is why we strongly recommend against writing to those addresses.
Thank you. I understand that accessing 0x5000-0x5FFF on the first page will alias 0x0000-0x0FFF on the second page, since both would access 0x5000-0x5FFF of DM0 (and similarly 0xB000-0xBFFF on first page and 0x6000-0x6FFF on the second page both access 0x5000-0x5FFF of DM1). I don't see this as an objection to using those ranges on the first page, especially since doing so would allow me to avoid having to support paging in the first place, hence I'd never access the second page.
Thank you again for your response, this has fully cleared up the situation for me.