About ADAU1452's I2C burst mode violation.
Hello all,
I got a question.
the data sheet p.36 mentions what a developer must avoid as below on I2C burst mode.
・Do not issue an autoincrement (burst) write command that exceeds the highest subaddress in the memory.
• Do not issue an autoincrement (burst) write command that writes to subaddresses that are not defined in the Global RAM and Control Register Map section.
What will happen if the above is violated and accidentally write data in prohibited area of RAM?
Best Regards,
Yuta M
Hello Yuta,
The answer is short, "Undefined".
It will all depend on what it tramples upon. There are sections of RAM that are used for some of the accelerators or other functions. Then some of the data RAM that is adjacent to other parameter RAM so you may trample on a filter or switch setting. So the result can be from "nothing happens" to "the audio quits or oscillates".
So the answer is: don't do that!
Dave T
Hello Dave,
Thank you so much for your very clear answer.
I completely understand that and I will never do that:)
Best Regards,
Yuta Mihara
:)
I will never do that:)
I have :-D
The following is what you encounter (at least via SPI):
0000-4FFF: DM0
5000-5FFF: alias of 0000-0FFF
6000-AFFF: DM1
B000-BFFF: alias of 6000-6FFF
C000-DFFF: PM
E000-EFFF: alias of C000-CFFF
F000-FBFF: register space
FC00-FFFF: mystery space (open bus?)
Register space is 16-bit (i.e. address increments every 2 bytes) while the rest is 32-bit, including mystery space. Don't try to perform a read or write that crosses the boundary of register space as this really seems to cause erratic behaviour. The other boundaries appear to be safe to cross, e.g. zeroizing all three memories using a single big write of zeros covering 0000-DFFF seems to work fine.
The aliases quite puzzle me. While it's not uncommon for memory aliasing to occur due to incomplete address decoding, I would then expect 5xxx to be an alias of 1xxx or maybe 3xxx, but definitely not 0xxx. It actually looks to me like it might be arranged on purpose, but if so I have no idea what that purpose might be.
As for mystery space: I've witnessed it (all addresses in it read the same) showing the next value after reading from a memory, e.g. if I had just read from address 0x1234 then mystery space contained the value stored at address 0x1235, presumably because the DSP had fetched it already to be prepared for the next SCK edge. However I just tried it again and now I just get nothing but zeros. Curious.
Register space doesn't seem to contain much more than is documented, and unused parts of it appear to be RAZ/WI (reads as zero, writes ignored). A few panic manager registers are missing from the datasheet but included in SigmaStudio export files. The only range which has a whole bunch of conspiciously noticable undocumented registers is F800-F8FF wherein only the SOFTRESET register (at F890) is documented.
FWIW, I've never noticed any ill effect from dumping the whole register space.
... Wait, that's actually not entirely true, although the problematic register is actually a "public" one that's just very badly documented: I discovered that reading the cycle counter (F460-F461) actually causes it to be recorded in F463-F464 (and F465-F466 if it's a new maximum), which renders those registers useless for their intended purpose of tracking the number of cycles consumed by the frame interrupt handler. It seems this only happens if both F460 and F461 are read within the same frame. So far this is the only "read-hazardous" register I've noticed.
Please log in to reply.