i.MXRT1170: How to route kXBARA1_InputDmaDone0 through XBAR1

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MXRT1170: How to route kXBARA1_InputDmaDone0 through XBAR1

Jump to solution
905 Views
michael_fischer
Contributor III

Hello,

I want to route the InputDmaDone signal through the XBAR to control a GPIO. Here I am using the i.MXRT1170-EVKB board for testing, the GPIO signal that should be controlled is GPIO_DISP_B2_10, pin 4 on J9.

For testing the code if the XBAR is correct setup I use the following code:

IOMUXC_SetPinMux(IOMUXC_GPIO_DISP_B2_10_XBAR1_INOUT38, 0U);
IOMUXC_GPR->GPR21 |= IOMUXC_GPR_GPR21_IOMUXC_XBAR_DIR_SEL_38_MASK;

/* Internal pulldown resistor enabled */
IOMUXC_SetPinConfig(IOMUXC_GPIO_DISP_B2_10_XBAR1_INOUT38, IOMUXC_SW_PAD_CTL_PAD_PULL(2));

/* Configure the XBARA signal connections for testing */
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicLow,  kXBARA1_OutputIomuxXbarInout38);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputIomuxXbarInout38);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicLow,  kXBARA1_OutputIomuxXbarInout38);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicHigh, kXBARA1_OutputIomuxXbarInout38);
XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputLogicLow,  kXBARA1_OutputIomuxXbarInout38);

An oscilloscope is connected to pin4 of J9, and I can see that the signal is toggled if I step through the last lines here. Here I have proved that my setup with the XBAR is working correct.

Now I want to control the signal by DMA. The code looks like:

static edma_handle_t dmaHandle0;

static volatile uint32_t g_Transfer_Done = 0;

static uint32_t srcBuffer1[8] __attribute__ ((aligned (32))) =
{
   0x11111111, 0x22222222, 0x33333333, 0x44444444,
   0x55555555, 0x66666666, 0x77777777, 0x88888888
};

static uint32_t destBuffer1[32] __attribute__ ((aligned (32)));


DMAMUX_EnableAlwaysOn(DMAMUX0, 0, true);
DMAMUX_EnableChannel(DMAMUX0, 0);

EDMA_CreateHandle(&dmaHandle0, DMA0, 0);
EDMA_ResetChannel(dmaHandle0.base, dmaHandle0.channel);

memset(&transferConfig, 0, sizeof(transferConfig));

EDMA_PrepareTransfer(&transferConfig, 
                     (void*)&srcBuffer1[0], 
                     32,                   
                     (void*)&destBuffer1[0], 
                     32,                    
                     32,                    
                     32,                    
                     kEDMA_MemoryToMemory); 
EDMA_SubmitTransfer(&dmaHandle0, &transferConfig);
EDMA_SetMajorOffsetConfig(DMA0, 0, -32, -32);

EDMA_SetCallback(&dmaHandle0, EDMA_Callback, NULL);

XBARA_SetSignalsConnection(XBARA1, kXBARA1_InputDmaDone0,  kXBARA1_OutputIomuxXbarInout38);

The DMA can be started with the following code:

memset(destBuffer1, 0x00, sizeof(destBuffer1));

g_Transfer_Done = 0;
EDMA_StartTransfer(&dmaHandle0);
while (0 == g_Transfer_Done)
{
   asm volatile ("nop");
}

The data was transferred by DMA correctly, this was proved by the debugger. And the DONE bit was set too. But the signal on the GPIO pin does not change. The signal is still LOW, but it must be HIGH.

Any hints are welcome.

Best regards,
Michael

0 Kudos
Reply
1 Solution
864 Views
michael_fischer
Contributor III

Hello @Kan_Li ,

>Was the Done status bit cleared by SW in your application?
The status bit is not cleared by software, the DONE bit is still set after the DMA transfer.

>Maybe you can use an oscilloscope to check if there is any pulse on the GPIO.
I think the magic word is here pulse. I assumed that the GPIO was high after the DMA transfer because the DONE bit was still set to 1.

That was my mistake because I didn't even try to trigger on an rising edge. And the pulse here is only about 5ns wide.

My primary goal was to start a secondary DMA transfer with the first DONE signal. I cannot use the link feature, because the first DMA is running on the M7 and the second DMA should run on the M4 core.

That's why I have to go via the XBAR and used the GPIO as a test to see whether it also changes during DONE.

The test with the second DMA on the M4 is still pending, but the current problem has now been solved.

Best regards,
Michael

View solution in original post

0 Kudos
Reply
2 Replies
872 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi @michael_fischer ,

 

Was the Done status bit cleared by SW in your application? Maybe you can use an oscilloscope to check if there is any pulse on the GPIO.

 

Have a great day,
Kan


-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

865 Views
michael_fischer
Contributor III

Hello @Kan_Li ,

>Was the Done status bit cleared by SW in your application?
The status bit is not cleared by software, the DONE bit is still set after the DMA transfer.

>Maybe you can use an oscilloscope to check if there is any pulse on the GPIO.
I think the magic word is here pulse. I assumed that the GPIO was high after the DMA transfer because the DONE bit was still set to 1.

That was my mistake because I didn't even try to trigger on an rising edge. And the pulse here is only about 5ns wide.

My primary goal was to start a secondary DMA transfer with the first DONE signal. I cannot use the link feature, because the first DMA is running on the M7 and the second DMA should run on the M4 core.

That's why I have to go via the XBAR and used the GPIO as a test to see whether it also changes during DONE.

The test with the second DMA on the M4 is still pending, but the current problem has now been solved.

Best regards,
Michael

0 Kudos
Reply