This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DMA Control Packets initialization on RM46

Other Parts Discussed in Thread: HALCOGEN, RM46L852

Hello

I am currently using the RM46/RM44 DMA peripheral to handle a SCI communication without using CPU resources.
My product is made of two software. The first one acts as a bootloader and launches the second one (applicative).
Both of them uses the SCI through DMA.
One more thing, the bootloader does not reset to launch the applicative, it directly jumps to the applicative entry point.

I observed some issues in DMA behavior. After some more investigation, I saw that the DMA Control Packets were not reinitiliazed when I entered the applicative.

However i am paying attention to:
1) Disable the DMA before leaving the bootloader (GCTRL to 0x0 as soon as BUSY bit is low),
2) Initializing the DMA peripheral at the beginning of applicative execution.

I have tried to reset the DMA peripheral (GCTRL to 1as soon as BUSY bit is low) instead of stopping it without any success.

Finally the only solution I found was to set RTCTRL first bit and perform a memset of 0 from first DMA RAM address to latest one.

Is this behavior normal (I mean, is it normal that control packets are not equal to 0 upon reset)?
Do you see any other way to reinitialize these control packets?

Thanks for help,

Jules

  • Jules,

    I'm trying to understand your problem statement. Is the problem statement that the DMA control packets are not initialized to '0' in your warm-start of the application scenario?

    If so that is normal. The DMA control packets are implemented in a RAM not in registers.

    You might be seeing them cleared to '0' as a side-effect of a hardware auto-initialization of SRAM.
    See the TRM section 'Auto-Initialization of On-Chip SRAM Modules'. Basically the chip has hardware to do a
    memset of '0' to all the RAMs or groups of them including peripheral RAMS like DMA. You could try using this
    hardware to clear the DMA RAMs again a little 'faster' than with the software memset.

    But anyway, the DMA control packets are not supposed to be cleared just by a 'reset'.
    It actually mentions this in the DMA chapter of the TRM in the section 'Initializing RAM with Parity' where it says:

    "After power up, the RAM content including the parity bit cannot be guaranteed. To avoid parity failures
    when reading RAM, the RAM has to be initialized. The RAM can be initialized by writing known values into
    it. When the known value is written, the corresponding parity bit will be automatically calculated and
    updated.
    Another possibility to initialize the memory is to set a 4-bit key in the system module. This key triggers the
    automatic initialization of all RAMs on the microcontroller. The RAM will be initialized to 0. Depending on
    the even/odd parity selection, the parity bit will be calculated accordingly."

    Normally that 2nd option is the auto-initialization and it's done as a pretty standard step in HalCoGen startup code. So that's what is probably going on that makes the bootloader work for you.

    Best Regards,
    Anthony
  • Hi Anthony,

    Thanks for your reply. You understood my "issue".
    I perform the RAM initialization to 0 during the startup of my bootloader (as per the TI Application note referenced SPNA106D).
    But since the DMA is used (and then controls packets are updated) during bootloader execution, controls packets are not initialized when the MCU reaches the applicative software.
    My MCU system initializations are made only once during bootloader startup. When switching from bootloader to applicative, clock setup do not change, internal pbist are not performed once more and so on...
    As far as I understand, if i do not want to change my process I can go on using my aforementioned procedure; I mean setting GCTRL to 0 , setting RTCTRL to 1 and then performing a memset to 0 of the entire DMA RAM memory. Do you confirm this?

    Thanks one more time for your help,

    Jules
  • Hi Jules,

    Yes, if you are going to reconfigure the DMA controller to perform a different task - transferring ownership from the bootloader to the application - then re-initializing the DMA control packet RAM is probably necessary and definitely a good practice. The procedure you mention should be fine as long as the DMA is not operating when you clear out the control packet RAM that is ok. On the other hand you could use the hardware meminit() instead of the memset routine just to save some time, but either method is fine.

    Thanks and Best Regards,
    Anthony
  • Hi Anthony,

    For my information, could you please tell me where I could find details (which TI document) about this hardware meminit (and how to use it?).
    Thanks for help once more,

    Jules
  • Jules,

    Hi, the mechanism itself is documented in the TRM section 'Auto-Initialization of On-Chip SRAM Modules' .
    For RM46 the TRM literature number is SPNU514 www.ti.com/.../spnu514
    Specific RAM groups are listed in the Datasheet, for example for RM46L852 www.ti.com/.../spns185
    section 6.13.2 table 6-27 shows you that the DMA RAM is initialized through bit 1 of the MSIENA register.

    Please check HalCoGen as well, in the file 'sys_selftest.c' there is a function 'memoryInit()' that takes a parameter for the RAM group from table 6-27 and initializes the selected memories for you.

    -Anthony
  • I got my inputs.
    Thanks for help!

    Jules