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.

RM44L920: DMA-Parity error after DMA-Controlpacket initialization

Part Number: RM44L920
Other Parts Discussed in Thread: HALCOGEN

Hello,

When I enable the DMA parity (0xAU) and I start configuring the request lines + DMA control packet, I see that the ESM Group1 is reporting a 0x08 which is a DMA Parity error. Is there any possibility to avoid that as most all PBIST RAM tests are already successfully executed.

Is there a sequence I need to follow when enabling the DMA parity? I have read something connected to the auto-initlaization routine, but I don't know all the steps. Currently I enable the Party before configuring the control packets, but once I jump over the Control packet function, the ESM reports a DMA parity error.

  • Hi Krax,

    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 HALCoGen generated startup code should include the function call to initialize the DMA RAM:

    memoryInit( (uint32)((uint32)1U << 1U) /* DMA RAM */
    | (uint32)((uint32)1U << 2U) /* VIM RAM */
    | (uint32)((uint32)1U << 5U) /* CAN1 RAM */
    | (uint32)((uint32)1U << 6U) /* CAN2 RAM */
    | (uint32)((uint32)1U << 10U) /* CAN3 RAM */
    | (uint32)((uint32)1U << 8U) /* ADC1 RAM */
    | (uint32)((uint32)1U << 14U) /* ADC2 RAM */
    | (uint32)((uint32)1U << 3U) /* HET1 RAM */
    | (uint32)((uint32)1U << 4U) /* HTU1 RAM */
    | (uint32)((uint32)1U << 15U) /* HET2 RAM */
    | (uint32)((uint32)1U << 16U) /* HTU2 RAM */

    What happens if you run DMA RAM parity by calling the API: dmaParityCheck()?

  • Hello QJ Wang,

    Thanks for your fast feedback. When I call the memoryInit without any further initialization of the DMA (memoryInt(0x1 /* No DMA init */)), and later on I activate the DmaParity by calling the corresponding function you mention above, it seems to be ok for this debug cycle step. If I approach to several DMA specific initialization steps like the dmaConfigCtrlPaket which is used in a RTI context, the ESM Group1 directly reports a Parity error by setting the value 0x8 in the register. When I jump over this dmaConfigCtrlPaket, then no error is issued on the ESM register.

    Is there a specific initialization step needed? I think you mentioned in several HET Parity topics that the xPartiyCheck() needs to be called first before the execution memoryInit() with the DMA RAM init or do I need to follow a different sequence? 

  • If I approach to several DMA specific initialization steps like the dmaConfigCtrlPaket which is used in a RTI context, the ESM Group1 directly reports a Parity error by setting the value 0x8 in the register

    dmaConfigCtrlPacket() doesn't read/write the DMA memory, so calling this function should not generate parity error.

    In the start-up, code should auto-initialize all on-chip SRAMs (MCU RAM and Peripheral RAMs), and check the parity error detection mechanism for all peripheral memories (NHET RAM, ADC, DMA, MibSPI, CAN, and VIM etc).

  • Hello Qj Wang,

    thanks for your contribution. I see the flag updated whenever I assign my buffer to the DMA source/destination address which is linked to some hardware periphery.

    Nevertheless, enabling the DMA parity register before using the auto-initialization approach for the DMA RAM during the startup solved the issue. ESM stopped reporting a parity error unless I apply a corresponding test to test the diagnosis