"ADAU1462" actually appears to be an ADAU1466

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]
Parents
  • 0
    •  Analog Employees 
    on Aug 2, 2019 3:56 PM

    Hello Matthijs,

    Ken is travelling and having trouble logging into the forum so I will insert his answers here.

    Ken's response:

     

    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.

    No. There are no registers that distinguish the two parts.

     

    1. 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.

     

    Yes. Contrary to the documentation in the Rev 0 datasheet, for the first page only, the memory map of the ADA1462 does agree with that of ADAU1466. The lower amount of memory available for the ADAU1462 is reflected entirely on the second page. However, the slave control port addresses 0x5000 to 0x5FFF (on both pages) are reserved and should not be used. The behavior of reading and writing these addresses is undefined. The second page should be used to access this block of memory.

     

    The ‘6x parts all come up with the addressing pointing to the first page. For data memory, the first 20kW of each bank (DM0/DM1) are accessible from page one. Since that is equal to the amount of DM on an ADAU1452 and all registers on a ’52 are found on all ‘6x parts, any program compiled for a ’52 will run on any ‘6x without modifications. For the program memory, the first 12kW (of 16kW) of program memory is addressable from the first page. In practice, more than 12kW is only necessary at very low sample rate since the core speed and the sample rate dictate the maximum number of instructions that can be executed in a single sample period.

     

    As David has stated, any memory that appear to exist on an ADAU1462 beyond the amount documented is not tested and is not guaranteed to exist in future silicon revisions. Using any additional memory found empirically is not recommended and has no warranty expressed or implied.

     

    Hope this helps,

     

    Ken

    Here is a revised memory map:

     

     

  • There is no manufacturing defect.

    I should have added "or the datasheets seem to be incorrect about the slave interface memory map of the ADAU1462/3".

    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.

    Yes this is what I would have expected. The confusion arose because the datasheets seemed to imply they were not quite compatible from the point of view of the slave interface.

    Regarding the memory map. Table 56 and 57 in the datasheet outlines the differences however, I think it is wrong.

    That exactly. In rev C of the ADAU1462/1466 datasheet their incompatibility is implied by figures 26/27 (page 37/38), tables 56/57 (page 89), figures 82/83 (page 90/91), and all discussion that refer to the lower page as being the "lower half" of that memory (rather than the first 20Kwords for DM0/DM1 or first 12Kwords for PM), and likewise the upper page being the "upper half" (rather than "the remainder"). Such language can be found on page 27 and page 36.

    The same applies to the ADAU1463/1467 datasheet.

    for the first page only, the memory map of the ADA1462 does agree with that of ADAU1466. The lower amount of memory available for the ADAU1462 is reflected entirely on the second page.
    For data memory, the first 20kW of each bank (DM0/DM1) are accessible from page one. Since that is equal to the amount of DM on an ADAU1452 and all registers on a ’52 are found on all ‘6x parts, any program compiled for a ’52 will run on any ‘6x without modifications.

    Thank you! This is the crucial information I needed.

    If I'd have to guess, I'd speculate that referring to the two pages as "halves" was based purely on the ADAU1466/1467 (where each page is indeed half of the memory) and this characterization later resulted in the incorrect description of the memory map of the ADAU1462/1463 (where in reality the upper page of each memory is reduced in size, hence the pages are no longer halves).

    However, the slave control port addresses 0x5000 to 0x5FFF (on both pages) are reserved and should not be used. The behavior of reading and writing these addresses is undefined. The second page should be used to access this block of memory.

    Hmm, okay, that's unfortunate since it seemed to work on the first page (based on admittedly very superficial testing), and it obviously would have been nice to be able to use all of DM0/DM1 on the ADAU1462 without having to deal with paging in our software at all.

    I also seem to recall SigmaStudio's export.xml didn't use paging for DM0/DM1 when using the ADAU1462 component, even when using more than 20kW of both (whereas it did when using the ADAU1466 component), but I think Sigma Studio has been updated since then, so maybe that's the thing you mentioned having been fixed. I'll have to do a new test.

  • 0
    •  Analog Employees 
    on Aug 8, 2019 8:20 PM in reply to matthijs

    Hmm, okay, that's unfortunate since it seemed to work on the first page (based on admittedly very superficial testing), and it obviously would have been nice to be able to use all of DM0/DM1 on the ADAU1462 without having to deal with paging in our software at all.

    I also seem to recall SigmaStudio's export.xml didn't use paging for DM0/DM1 when using the ADAU1462 component, even when using more than 20kW of both (whereas it did when using the ADAU1466 component), but I think Sigma Studio has been updated since then, so maybe that's the thing you mentioned having been fixed. I'll have to do a new test

    Yes, the update I mentioned was in the export file format. The page number was something that was missed in the update for the newer parts. So now you will get that important info. 

    The external access to memory is via the SPI/I2C port and the address is limited to 16 bits. So we had to setup the extra memory as pages. I think I am remembering the reasons the designers told me about correctly. 

    Dave T

Reply
  • 0
    •  Analog Employees 
    on Aug 8, 2019 8:20 PM in reply to matthijs

    Hmm, okay, that's unfortunate since it seemed to work on the first page (based on admittedly very superficial testing), and it obviously would have been nice to be able to use all of DM0/DM1 on the ADAU1462 without having to deal with paging in our software at all.

    I also seem to recall SigmaStudio's export.xml didn't use paging for DM0/DM1 when using the ADAU1462 component, even when using more than 20kW of both (whereas it did when using the ADAU1466 component), but I think Sigma Studio has been updated since then, so maybe that's the thing you mentioned having been fixed. I'll have to do a new test

    Yes, the update I mentioned was in the export file format. The page number was something that was missed in the update for the newer parts. So now you will get that important info. 

    The external access to memory is via the SPI/I2C port and the address is limited to 16 bits. So we had to setup the extra memory as pages. I think I am remembering the reasons the designers told me about correctly. 

    Dave T

Children
No Data