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 Auto-Initiation and HWCHENA

Hi,

I plan to use a DMA channel for receiving CAN messages in a rotating buffer without any interruption (I plan to poll PBACTC - as i use only one DMA channel - to see if one message has been written in my buffer since my previous check).

My question is:

In the documentation (RM46 TRM) §16.2.8 Auto-Initiation:

When Auto-initiation Mode (AIM) bit of Channel Control Register (Section 16.3.2.4) register is enabled for
a channel and the channel is triggered by a software request for a block transfer, the channel will restart
again using the same channel information stored at the respective control packet after one block transfer
is completed. In the case of Hardware Request the channel needs to be retriggered each time after a
block is complete even if auto-initiation is enabled

And in the description of the HWCHENAS register for the HWCHENA bit:

Hardware channel enable bit. An active hardware DMA request cannot initiate a DMA transfer
unless the corresponding hardware enable bit is set.
The corresponding hardware enable bit is cleared automatically for the following conditions:
• At the end of a block transfer if the auto-initiation bit AIM (see CHCTRL) is not active.
• If an AHB bus error is detected for an active channel.

So, what is the expected action to "retriggered the hardware request channel" when both AIM and HWCHENA are set?

 

Bruno.


 

  • Bruno,

    Whenever a channel is used, it has to be enabled. Than a trigger condition has to happen, either software or hardware.

    If auto-initialization is not used, at the end of the transfer, the channel is automatically disabled.
    If auto-initialization is used, the channel will stay enabled, and will restart using the configuration stores in the control packet.
    In case of Hardware trigger, a new trigger condition is necessary to restart the transfer.
    In case of Software trigger, it will restart WITHOUT the need for the cpu to re-trigger this channel.

    Please let me know if this clarify your question.

  • Jean-Marc,

    Thanks you for this answer.
    I think I have understand : in my example, the transfer will be restart when a new message CAN is received. Correct?

    I've got an other question about DMA.
    In the documentation:

    The DMA acts as an independent master in the platform architecture. All DMA memory and register
    accesses are performed in user mode. If the DMA writes to registers which are only accessible in
    privileged mode, the write will not be performed.

    If I configure a RAM area to be writeable only in privileged mode (via the MPU), does it mean that the DMA could not write in this area?
    Or should I use the DMA Protection Mechanism to achieve such protection?


    Bruno.

  • Bruno,

    DMA write to destination memory (RAM, Registers) is done in user mode. (Same limitation as CPU user mode)
    So if a DMA destination memory is protected by the MPU as Privilege write region only, the DMA will not be able to write to this location.

    The DMA memory protection will work the same way as the main MPU.
    Up to 4 region can be defined in the DMA MPU and will allow the following accesses:

    • Full access
    • Read only access
    • Write only access
    • No access

    The DMA MPU region will not overwrite the main MPU region.

    Example: In DMA MPU, region 0x0800_0000 to 0x0800_FFFF is defined as Full access (Read and Write)
                      In Main MPU, region 0x0800_0000 to 0x0800_FFFF is defined as Privilege write only.

    In this situation, the DMA will not be able to write in this region.