EngineerZone is sticking this in the 8052 forum. It should really be in the ultra-low power forum.While trying to get DMA working on a ADuCM363, I have noticed some documentation errors. These are found in Rev B of the ADuCM362-ADuCM363 Hardware reference manual.Page 61 of the document, states there are 16 DMA channels and lists them.Page 68 of the manual lists the reset value of the DMASTA register, 0x000B0000, which would correspond to a CHNLSMINUS1 value of 11 which is 12 DMA channels. However, the actual reset value of the DMASTA register, when viewed through a debugger, is 0x00110000, which corresponds to 18 channels!Page 69 documents the DMAPDBPTR register and says, "Note that 5 + log(2)M LSBs are reserved and must be written 0, where M is the number of channels."We will assume that log(2) rounds up if the value is not an integer. If we use the documented value of 16 channels, we get "5 + log(2)16" which is "5 + 4" which is 9. 9 LSBs of zero give us an alignment factor of 0x200. However, if you try to assign a DMAPDBPTR value of 0x20001200, which has the 9 LSB's of 0, the register adjusts the value to 0x20001000!If we instead assume that the CHNLSMINUS1 value in DMASTA, as read in the debugger, is correct and the device really has 18 DMA channels, then our "5 + log(2)M" calculation becomes "5 + log(2)18" which is "5 + 5" which is 10. 10 LSBs gives an alignment requirement of 0x400. And that, in fact, is the correct value to use. If the Primary Control Data Base pointer is 0x20001400, the DMAPDBPTR register does not modify it.So, at the very least, the Hardware Reference Manual is incorrect. Both in claiming that CHNLSMINUS1 is 11 (12 channels) and also that the device only has 16 DMA channels, when in fact there are 18. What are the 2 missing DMA channels? Are they just unassigned?Also, the example code in ADuCM36x_DFP.1.0.4 defines DMACHAN_DSC_ALIGN as 0x200 (Device/Include/drivers/DmaLib.h). This is incorrect. It should be 0x400. If the example code works (I haven't tested it), it is only by luck.




