IMX RT1170 DMA on CM4 Core

[danielb-tkjcy3rq]

Hi All,

I'm working on a project using imx rt1170 based custom board. I'm hoping to use the eDMA peripheral on the chip in periodic trigger mode to throttle the data DMA is transferring. I need to do this because I'm generating custom protocol signal by using DMA to transfer data to a GPIO data register. The plan is to use the CM4 for this as the CM7 will be used for application level stuff like Ethernet.

I understand that Zephyr doesn't currently support the periodic triggering I'm trying to do so I will use the NXP SDK to do this. I will use DMAMUX1 channel 0 in always on mode with eDMA LPSR channel 0 and PIT2 channel 0. I have seen this work on MCUXPresso by modifying the edma_memory_to_memory sample to add periodic triggering. But no luck when I port the code to Zephyr. The ported code builds and flashes OK but the DMA TX interrupt doesn't fire.

I also attempted removing the periodic triggering just to see DMA working but still no interrupt. I used dma_request_channel to make sure the DMA channel I'm trying to use isn't already in use.

I'm using Zephyr 3.5.0-rc3 and I've setup a multicore project based on the openamp sample.

Can someone please help with this?

Thanks,
Daniel

[danielb-tkjcy3rq]

I think I can get this to work by using the Zephyr DMA API as well as the NXP SDK. Basically I can request a periodic DMA channel and initialise it. After that, I can call the SDK function to make that channel periodic and initialise the appropriate timers to do the triggering. I have seen this work when doing MEMORY_TO_MEMORY transfers.

The issue I now have is transferring data from memory to peripheral. The code below works fine until I change 'dma_cfg.channel_direction = MEMORY_TO_MEMORY' to 'dma_cfg.channel_direction = MEMORY_TO_PERIPHERAL'. By the way, the sample below isn't calling any SDK functions directly. It is a modified version of the DMA test code found in Zephyr. Does anyone know why changing the direction to MEMORY_TO_PERIPHERAL stops the code from working?

zephyr_dma_test.txt

[danielb-tkjcy3rq]

I think I have found the issue. In the case of memory to peripheral transfer, dma_mcux_edma_configure in dma_mcux_edma.c is setting the dmamux source to the slot. My code doesn't work because I didn't set any slot that would generate the transfer request.

Even though I'm setting it to memory to peripheral, I do need the DMAMUX to be in always on mode so I can do periodic trigger using a PIT timer. I guess I will have to mod the driver somehow to add this support.

[DerekSnell]

Hi @danielb-tkjcy3rq ,

It seems you are on the right path, and getting close. Thank you for sharing your updates.

You are right, the driver dma_mcux_edma.c does not yet enable the DMAMUX periodic trigger feature you are trying to use. To setup the channel for Always On and periodic triggering, you just need to configure the CHCFG register in the DMAMUX.

Updating the dma_mcux_edma.c driver to do that would be ideal, especially if you contribute that back to the Zephyr Community. But another option is like you said: use the Zephyr DMA APIs to configure the channel, and then call the HAL APIs in the MCUXpresso SDK to configure the DMAMUX register as you need. For example, DMAMUX_EnablePeriodTrigger() and DMAMUX_EnableAlwaysOn() can be called after the DMA channel is configured.

Also, you seem to be aware since you are using channel 0, but for others, the periodic trigger feature of the DMAMUX is only available on the first 4 channels in the RT1170.

Also FYI since you are using the PIT, we have an open PR #66336 to add the PIT driver to Zephyr.

Please let us know how this goes for you. Best regards

[danielb-tkjcy3rq]

Thank you @DerekSnell!

I took the easy route for now and used the HAL API just to see it working. The DMA is transferring periodically but the timing isn't quite right. I've attached a screenshot of a Saleae capture for reference. I am configuring it to transfer data every 416us but it seems like PIT is triggering every 624us. Any idea why this could be? I suspect clock configuration issue but not sure how to check that in Zephyr. I would use clock_config.c/h in MCUXpresso.

I've edited this comment because there were some issues with the code I posted originally.

# include <zephyr/drivers/dma.h>
# include <zephyr/kernel.h>

static const uint32_t tx_data[] = {
    (1 << 10), 0x0, (1 << 10), 0,   (1 << 10), 0,   (1 << 10), 0,   (1 << 10), 0,   (1 << 10), 0,
    (1 << 10), 0,   (1 << 10), 0,   (1 << 10), 0,   (1 << 10), 0x0, (1 << 10), 0x0, (1 << 10), 0x0,
    (1 << 10), 0x0, (1 << 10), 0x0, (1 << 10), 0x0, (1 << 10), 0x0, (1 << 10), 0x0,
};

static struct gpio_dt_spec led = GPIO_DT_SPEC_GET_OR(DT_ALIAS(led0), gpios, { 0 });

static pit_chnl_t pitCh;

static void test_done(const struct device * dma_dev, void * arg, uint32_t id, int status)
{
    if (status >= 0)
    {
        printk("DMA transfer done\n");
    }
    else
    {
        printk("DMA transfer met an error\n");
    }
}

static bool test_task(const struct device * dma, uint32_t chan_id, uint32_t blen)
{
    struct dma_config dma_cfg = { 0 };
    struct dma_block_config dma_block_cfg = { 0 };

    if (!device_is_ready(dma))
    {
        printk("dma controller device is not ready\n");
        return false;
    }

    dma_cfg.channel_direction = MEMORY_TO_PERIPHERAL;
    dma_cfg.source_data_size = 4U;
    dma_cfg.dest_data_size = 4U;
    dma_cfg.source_burst_length = blen;
    dma_cfg.dest_burst_length = blen;
    dma_cfg.dma_callback = test_done;
    dma_cfg.complete_callback_en = 0U;
    dma_cfg.error_callback_en = 0U;
    dma_cfg.block_count = 1U;
    dma_cfg.head_block = &dma_block_cfg;

    printk("Preparing DMA Controller: Name=%s, Chan_ID=%u, BURST_LEN=%u\n", dma->name, chan_id, blen >> 3);

    printk("Starting the transfer\n");
    dma_block_cfg.block_size = sizeof(tx_data);
    printk("transferring %d\n", dma_block_cfg.block_size);
    dma_block_cfg.source_address = (uint32_t)tx_data;

    dma_block_cfg.dest_address = (uint32_t)&GPIO11->DR;

    if (dma_config(dma, chan_id, &dma_cfg))
    {
        printk("ERROR: transfer\n");
        return false;
    }

    if (dma_start(dma, chan_id))
    {
        printk("ERROR: transfer\n");
        return false;
    }
    PIT_StartTimer(PIT2, pitCh);
    return true;
}

int main()
{
    const struct device * dma = DEVICE_DT_GET(DT_NODELABEL(edma_lpsr0));
    enum dma_channel_filter dmaFilter = DMA_CHANNEL_PERIODIC;
    const auto channel = dma_request_channel(dma, (void *)&dmaFilter);
    if (channel < 0)
    {
        printk("Failed to find a free periodic DMA channel");
        return 0;
    }

    DMAMUX_DisableChannel(DMAMUX1, channel);
    DMAMUX_EnablePeriodTrigger(DMAMUX1, channel);
    DMAMUX_EnableAlwaysOn(DMAMUX1, channel, true);
    DMAMUX_EnableChannel(DMAMUX1, channel);

    switch (channel)
    {
        case 0: pitCh = kPIT_Chnl_0; break;
        case 1: pitCh = kPIT_Chnl_1; break;
        case 2: pitCh = kPIT_Chnl_2; break;
        case 3: pitCh = kPIT_Chnl_3; break;
        default:
        {
            printk("Invalid periodic DMA channel %u\n", channel);
            return 0;
        }
    }

    pit_config_t pitConfig;
    PIT_GetDefaultConfig(&pitConfig);
    PIT_Init(PIT2, &pitConfig);
    PIT_SetTimerPeriod(PIT2, pitCh, USEC_TO_COUNT(416, CLOCK_GetRootClockFreq(kCLOCK_Root_Bus)));
    printk("bus frequency: %d\n", CLOCK_GetRootClockFreq(kCLOCK_Root_Bus));

    if (!gpio_is_ready_dt(&led))
    {
        printk("Test GPIO is not ready\n");
        return 0;
    }

    if (gpio_pin_configure_dt(&led, GPIO_OUTPUT_LOW) < 0)
    {
        printk("Failed to configure test GPIO\n");
        return 0;
    }

    test_task(dma, channel, 4);

    while (true)
    {
        k_msleep(10);
    }
    return 0;
}

[DerekSnell]

Hi @danielb-tkjcy3rq ,
From the RT1170 Reference Manual, the PIT2 peripheral is on the LPSR domain, part of the M4 domain. And the clock root is BUS_LPSR_CLK_ROOT.

Your code configures the PIT with the kCLOCK_Root_Bus frequency. But the LPSR clock is slower, which I think explains your longer period. Can you try using the clock kCLOCK_Root_Bus_Lpsr?

Best regards

[danielb-tkjcy3rq]

@DerekSnell, I just gave kCLOCK_Root_Bus_Lpsr a go and period seems a bit erratic now.

[danielb-tkjcy3rq]

I also ran my test on MCUXpresso and used kCLOCK_Root_Bus as the clock source for PIT2. I was seeing consistent 416.6us

[DerekSnell]

Hi @danielb-tkjcy3rq ,
That is an odd waveform. Especially if they only change was the frequeny given to the PIT driver API.

My guess is still that the PIT2 period register is not configured correctly given the timer clock. On the RT1170, there is a clock output pin you can use to output these root clocks and confirm their frequency, which could help here. And I would use a debugger to confirm the PIT2 registers after it is configured, specifically the bits that configure the trigger period. Confirm they should give the clock period you want. Also, since you have it working with the MCUXpresso SDK code base without Zephyr, you can compare the PIT2 registers with that application to see how they differ.

Please let us know what you find. Best regards

[danielb-tkjcy3rq]

Thank you Derek. I will do as you suggest.

I should add add a bit more info about my project setup in case it is relevant. I've put together an dual core image based on the openamp sample and the CM4 is running the code I posted above. One odd thing that I noticed was that when I enabled CONFIG_NETWORKING for the master CM7 project, then the CM4 PIT period improved somewhat and setting the PIT period to 450us outputs 416us. It is still not quite right so I will keep investigating.

Another thing that might be relevant is that the MCU on my custom board is MIMXRT1175AVM8A unlike the EVK which has MIMXRT1176DVMAA. Also, my custom board doesn't have external regulators so I should be running the CM7 at a maximum of 600MHz. So far I have left soc_rt11xx.c unmodified but I suspect I need to make some changes there to achieve 600MHz CM7 frequency?

Another observation: I added the dhcp client sample code to the CM7 image and that works well as long as I don't wake up the CM4 (by commenting out the contents of second_core_boot() in soc_rt11xx.c). I'm very confused how the CM4 core running could interfere with the CM7 code. I think I will create a separate ticket for this issue.

[DerekSnell]

Thanks for the details, @danielb-tkjcy3rq ,
That is some odd behavior with the PIT period you are reporting.

I would first focus on configuring the root clocks to the valid frequencies given your voltage supply. And ideally, confirm those clocks with the CCM_CLKO pins. And if the PIT period issue still remains, then confirm the PIT register configuration.

Let us know what you find. Best regards

[danielb-tkjcy3rq]

Thanks @DerekSnell,

I've made some progress on this and I'm now seeing consistent 416us period on PIT2. I set the CM7 frequency to 600MHz and CM4 to 240MHz. Also started using clock kCLOCK_Root_Bus_Lpsr for PIT2.

I also managed to fix the issue where ethernet on CM7 was breaking after CM4 core started. I basically I skip clock_init() in soc_rt11xx.c by returning early if CONFIG_CPU_CORTEX_M4 is defined because I have a suspicion that the CM7 is configuring the clocks as I expect but then the CM4 starts and initialises the clocks again. For example, the code below configures PLL2 PFD3 differently depending on CONFIG_ETH_MCUX - my CM7 project uses ethernet but not the CM4 project. For my project, I think it makes sense for the master project to configure the clocks before launching the slave core. Unless I'm missing something obvious?

/* Init System Pll2 pfd3. */
#ifdef CONFIG_ETH_MCUX
	CLOCK_InitPfd(kCLOCK_PllSys2, kCLOCK_Pfd3, 24);
#else
	CLOCK_InitPfd(kCLOCK_PllSys2, kCLOCK_Pfd3, 32);
#endif

[DerekSnell]

Hi @danielb-tkjcy3rq ,
That is good to hear. It sounds like the original topic of this discussion has been resolved. Feel free to close this Discussion.

If you have other questions that are still open, I suggest you create a new Discussion focused on that topic, and we can address them there.

Best regards

[danielb-tkjcy3rq]

Thank you very much for all your help @DerekSnell!