S32K348-GPIO EIRQ to DMA request Dear NXP Support Team, I.m trying now approach, where GPIO PTD6 has setting as EIRQ14 ,rising edge detection and I want to map this pin signal to the DMA channel, where I try get current value from PIT_1 Timer[0]. This is setup as FreeRunning. Seems that SIUL2 is set correctly for PTDA and I can see toggling on this pin when signal (1Hz) from signal generator is connect on related MCU pin. But DMA not working for me My guess here is that I have problem with finding proper chain from PTD6 ->DMAMUX-> DMA channel 4. and find where exactly I can find these information. From S32K3xx_DMAMUX_map.xlsx I got this: so here is my first issue: Which source->request is dedicated for PTD6(EIRQ14) ? And how is related Table 44 from RM manual? Here is fragments of my code which I working on now: Setup PTD6 void Setup_PTD6_EIRQ14_for_DMA(void) { /* 1. Configuration of physical pin PTD6 via MSCR register */ // PTD6 corresponds to index MSCR[102] (as seen on your screenshot) IP_SIUL2->MSCR[102] = 0; // Clear register IP_SIUL2->MSCR[102] |= (1 << 19); // IBE = 1 (Input Buffer Enable - configures pin as input) IP_SIUL2->IMCR[542-(512)] = 3u; // Optional: if the signal floats, you can enable Pull-Up (PUE=1, PUS=1) or Pull-Down (PUE=1, PUS=0) /* 2. Activation of edge detection on line EIRQ[14] */ // We want to capture the timestamp on every rising edge IP_SIUL2->IREER0 |= (1 << 14); // IREER0[EIRE14] = 1 (Enable Rising Edge) IP_SIUL2->IFEER0 &= ~(1 << 14); // IFEER0[EIRE14] = 0 (Disable Falling Edge) /* 3. Request routing: Change from Interrupt to DMA */ // This step ensures that the edge does not wake up the CPU (NVIC), but triggers the DMA line instead IP_SIUL2->DIRSR0 |= (1 << 14); // DIRSR0[DIRS14] = 1 (Select DMA Request instead of Interrupt) /* 4. Final enable of DMA request generation for EIRQ[14] */ IP_SIUL2->DIRER0 |= (1 << 14); // DIRER0[EIRE14] = 1 (Activate DMA request line) } and setup DMA channel: void Setup_eDMA_Channel4_Capture_PIT1(void) { /* 1. DMAMUX Initialization for eDMA Channel 4 */ // Map EIRQ14 (source 14) to eDMA channel 4 IP_DMAMUX_1->CHCFG[4] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u); // EIRQ14 is source 7 for DMAMUX_1 //IP_DMAMUX_0->CHCFG[4] = 0U; /* 2. TCD Configuration for Channel 4 pointing to PIT_1 (Exact S32K3 bare-metal syntax) */ // Source: Current value of PIT_1 Timer 0 IP_TCD->TCD4_SADDR = (uint32_t)&(IP_PIT_1->TIMER[0].CVAL); IP_TCD->TCD4_SOFF = 0; // Source does not increment IP_TCD->TCD4_ATTR = 0x0202; // 32-bit source, 32-bit destination // Minor Loop: Number of bytes transferred per single trigger // In S32K3 this corresponds to the NBYTES_MLOFFNO register (no minor loop linking) IP_TCD->NBYTES4.TCD4_NBYTES_MLOFFNO = 4; // Transfer 4 bytes (32-bit) per trigger // Destination: Our array in RAM IP_TCD->TCD4_DADDR = (uint32_t)dma_timestamps; IP_TCD->TCD4_DOFF = 4; // Shift by 4 bytes in RAM after each edge // Circular buffer: wrap around to the beginning after filling the entire array IP_TCD->TCD4_DLAST_SGA = -(BUFFER_SIZE * 4); // Major Loop Counter: Total number of iterations in the loop //IP_TCD->CITTER4.TCD4_CITER_ELINKNO = BUFFER_SIZE; IP_TCD->CITER4.TCD4_CITER_ELINKNO = BUFFER_SIZE; IP_TCD->BITER4.TCD4_BITER_ELINKNO = BUFFER_SIZE; /* 3. eDMA channel activation for hardware triggers via official macro */ //IP_TCD->CH4_CSR |= DMA_TCD_CH4_CSR_ERQ_MASK; /* 3. eDMA channel activation for hardware triggers (With asynchronous mode enabled) */ // Bit 0 (ERQ) = 1 -> Enables hardware triggers // Bit 2 (EARQ) = 1 -> Enables asynchronous requests from external pins (SIUL2 EIRQ) IP_TCD->CH4_CSR |= 3u; // ERQ=1, EARQ=1 } Here I guess is key line: IP_DMAMUX_1->CHCFG[4] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u); // EIRQ14 is source 7 for DMAMUX_1 where I'm little bit confused which IP_DMAMUX and which DMAMUX_CHCFG_SOURCE I need to use and where is proper information about this. Best regards Ondrej Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
"Is this meaning, that MCU have 32 TCD channels and TCD 0 to 15 is valid for DMAMUX_0 and TCD 15 to31 is for DMAMUX_1 ?"
yes, you can find these info in the datasheet, I copy it for your reference.
Re: S32K348-GPIO EIRQ to DMA request Hi Senlent, thank you for your answer. please, can you pointed me from where popup your meaning about TCD mapping? Is this meaning, that MCU have 32 TCD channels and TCD 0 to 15 is valid for DMAMUX_0 and TCD 15 to31 is for DMAMUX_1 ? So I'm still little bit confused about information regarding DMAMUX and eDMA. Best regards Ondrej Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
Your understanding is correct:
PTD6->EIRQ14->DMAMUX1.SOURCE 7.
IP_DMAMUX_1->CHCFG[4] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u); // EIRQ14 is source 7 for DMAMUX_1
However, the TDC settings are incorrect.
My understanding is that they should be as follows:
IP_DMAMUX_1->CHCFG[0] ->TCD 16
IP_DMAMUX_1->CHCFG[4] -> TCD 20 instead of TCD4
Re: S32K348-GPIO EIRQ to DMA request HI SenLent, I made some changes in my code based on my observation. Here is my latest code: main initialization: Setup_PTD6_EIRQ14_for_DMA(); Setup_PIT1_Timer0_FreeRunning(); Setup_DMAMUX_Channel0_ToTCD16_Capture_PIT1(); //clear EIRQ14 interrupt flag IP_SIUL2->DISR0 = (1 << 14); and here is rest of code: void Setup_PTD6_EIRQ14_for_DMA(void) { // 1. Aktivácia hodinového deliča pre filtre v SIUL2 (ak už nie je povolený inde) IP_SIUL2->IFCPR = 0U; // Nastavenie deličky filtra na Functional Clock (bez dodatočného delenia) // 2. Voliteľne vypnite filter pre daný EIRQ index alebo ho nastavte na minimálny počet cyklov // Pre EIRQ14 (v závislosti od mapovania registrov IFMCR): IP_SIUL2->IFMCR[14] = 0U; // 0U vypína digitálny filter, hrana prechádza okamžite ako čistý hardvérový trigger /* 1. Configuration of physical pin PTD6 via MSCR register */ // PTD6 corresponds to index MSCR[102] (as seen on your screenshot) IP_SIUL2->MSCR[102] = 0; // Clear register IP_SIUL2->MSCR[102] |= (1 << 19); // IBE = 1 (Input Buffer Enable - configures pin as input) IP_SIUL2->IMCR[542-(512)] = 3u; // Optional: if the signal floats, you can enable Pull-Up (PUE=1, PUS=1) or Pull-Down (PUE=1, PUS=0) /* 2. Activation of edge detection on line EIRQ[14] */ // We want to capture the timestamp on every rising edge IP_SIUL2->IREER0 |= (1 << 14); // IREER0[EIRE14] = 1 (Enable Rising Edge) IP_SIUL2->IFEER0 &= ~(1 << 14); // IFEER0[EIRE14] = 0 (Disable Falling Edge) /* 3. Request routing: Change from Interrupt to DMA */ // This step ensures that the edge does not wake up the CPU (NVIC), but triggers the DMA line instead IP_SIUL2->DIRSR0 |= (1 << 14); // DIRSR0[DIRS14] = 1 (Select DMA Request instead of Interrupt) /* 4. Final enable of DMA request generation for EIRQ[14] */ IP_SIUL2->DIRER0 |= (1 << 14); // DIRER0[EIRE14] = 1 (Activate DMA request line) } void Setup_DMAMUX_Channel0_ToTCD16_Capture_PIT1(void) { /* 1. DMAMUX Initialization for eDMA Channel 4 */ // Podľa NXP tabuľky prislúcha SIUL2 DMA request 4 zdrojový index 7u //IP_DMAMUX_1->CHCFG[4] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u); //follow doc ,first disable channel 4, then configure it, and finally enable it IP_DMAMUX_1->CHCFG[0] = 0u; /* 2. TCD Configuration for Channel 4 pointing to PIT_1 (Exact S32K3 bare-metal syntax) */ // Source: Current value of PIT_1 Timer 0 IP_TCD->TCD16_SADDR = (uint32_t)&(IP_PIT_1->TIMER[0].CVAL); IP_TCD->TCD16_SOFF = 0; // Source does not increment IP_TCD->TCD16_ATTR = 0x0202; // 32-bit source, 32-bit destination // Minor Loop: Number of bytes transferred per single trigger // In S32K3 this corresponds to the NBYTES_MLOFFNO register (no minor loop linking) IP_TCD->NBYTES16.TCD16_NBYTES_MLOFFNO = 4; // Transfer 4 bytes (32-bit) per trigger // Destination: Our array in RAM IP_TCD->TCD16_DADDR = (uint32_t)dma_timestamps; IP_TCD->TCD16_DOFF = 4; // Shift by 4 bytes in RAM after each edge // Circular buffer: wrap around to the beginning after filling the entire array IP_TCD->TCD16_DLAST_SGA = -(BUFFER_SIZE * 4); // Major Loop Counter: Total number of iterations in the loop //IP_TCD->CITTER20.TCD20_CITER_ELINKNO = BUFFER_SIZE; IP_TCD->CITER16.TCD16_CITER_ELINKNO = BUFFER_SIZE; IP_TCD->BITER16.TCD16_BITER_ELINKNO = BUFFER_SIZE; //IP_TCD->CH16_CSR |= 3u; // ERQ=1, EARQ=1 //enable DMAMUX channel 0 IP_DMAMUX_1->CHCFG[0] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(6u); __asm volatile ("nop"); __asm volatile ("nop"); IP_TCD->CH16_CSR |= 3u; } And I'm still not able fire up DMA transfer by EIRQ(14) when is this assert. On Debugger I can see flag appear when I change signal on MCU PTD6 pin . Next I can start manually DMA transfer by TCD16_CSR START bit and on TCD channel CITTER value is decreased and value form PIT1_TIMER[0] is stored to my dma_timestamps array. Btw: This should be defined in "normal" SRAM section. I had before set this to data_cache section , what lead to DMA "Destination bus error" new definition: __attribute__((aligned(32))) __attribute__((section(".mcal_data"))) uint32_t dma_timestamps[BUFFER_SIZE]; but If I skip manual START (need to be never set from beginning of code) and I change signal on PTD6 pin , DMA channel do nothing , CITTER register stay on initialize value. Please, can you help identify where I have problem? I still guess that I have issue with proper connection from PTD6-EIRQ(14) asserted flag to the TCD16 channel. Maybe correct source for DMAMUX channel? For DMAMUX1-CH[0] I tested all sources (1 to 😎 of SUIL2 instances listed on DMAMUX excel table, without any success , but here I'm not sure if my steps was correct too Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
I've created a demo for your reference, using PTD6 to trigger DMA for a single data transfer.
It's based on S32K344 + RTD 7.0.1.
And I've tested it;
I can assure you that my understanding is correct.
For PTD6, the source should 7.
IP_DMAMUX_1->CHCFG[0] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u);
Re: S32K348-GPIO EIRQ to DMA request Hi SenLent, about choosing DMA channel here was my imagine that I can choose freely one from related DMA_MUX groups Meantime I tested other DMA_MUX <->TCD combination and on my side working only next one IP_DMAMUX_1->CHCFG[3] and TCD16. I got try next others: IP_DMAMUX_1->CHCFG[4] and TCD17. IP_DMAMUX_1->CHCFG[0] and TCD16. And please, why exactly only IP_DMAMUX_1->CHCFG[3] and TCD16. working ? And how is the relationship between IP_DMAMUX_1->CHCFG[xx] and TCDyy ? Re: S32K348-GPIO EIRQ to DMA request Hi Senlent, thank you very match for your example. After some changes I have working example now. I attach my adjusted project , where was one important issue: SIUL ICU with DMA req enabling was set up before whole DMA TCD channel was fully configured. In that case TCD_SADDR and TCD_DADDR was empty(zero values) and after that enabling DMA req in SUIL leads to DMA error - "Source bus error" what bring me sense. After change order of this initialization. example start working for me. But I have still problem understand exact relation between DMAMUX channel and TCD channel. You wrote that DMAMUX should by configured as CHCGF[0]. After downloading and starting app in our S32k344 custom development board i found that DMAMUX-CHCFG[3] is configured and exactly in code in function Dma_Mux_Ip_Init_Privileged is line which exactly lead to this configuration: RegisterIndex = DMA_MUX_IP_GATE_OFFSET((pConfig->pChannelConfigArr[ChannelCount].Channel)); here is screenshot from lauterbach Trace32 debugger, where you can see final setup after all initialization steps: In Design studio I have next configuration after updating RTD to 7.0.1: is this correct and what does it mean that here is choice of 3 DMA Mux sources? Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
Good to hear that.
This configuration tool may cause some confusion for developers who are just getting started.
For the S32K348, there is no DMAMUX_3; only DMAMUX_0 and DMAMUX_1 exist.
•For the S32K310, S32K311, and S32K312: DMAMUX_0 channels 0–5 and DMAMUX_1 channels 0–5 are mapped to eDMA Transfer Control Descriptor (TCD) 0–5 and eDMA Transfer Control Descriptor (TCD) 6–11, respectively. Programming of DMAMUX_0 channels 6–15 and DMAMUX_1 channels 6–15 is therefore not expected; however, if programmed, any access will result in either an error response for channels 8–15 or no error response for channels 6–7.
•For the remaining S32K3xx devices: DMAMUX_0 channels 0–15 and DMAMUX_1 channels 0–15 are mapped to eDMA Transfer Control Descriptors (TCDs) 0–15 and eDMA Transfer Control Descriptors (TCDs) 16–31, respectively.
The above is taken from the data sheet, and it is easy to understand:
The “DMA Hardware Channel” corresponds to the TCD number.
When you select DMA_CHANNEL_0 ~ DMA_CHANNEL_15, DMAMUX_0 is used by default;
when you select 16–31, DMAMUX_1 is used by default.
For example, in this topic, PTD6 corresponds to Source 7 of DMAMUX_1, so “DMA Hardware Channel” can be set to any value between DMA_CHANNEL_16 and DMA_CHANNEL_31.
Let’s take another example: if you select EIRQ 7 to trigger DMA, then “Dma Hardware Channel” can be set to any value between DMA_CHANNEL_0 and DMA_CHANNEL_15. Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
Here is the right order:
IP_DMAMUX_0>CHCFG[0] and TCD0.
IP_DMAMUX_0->CHCFG[1] and TCD1.
IP_DMAMUX_0->CHCFG[2] and TCD2.
IP_DMAMUX_0->CHCFG[3] and TCD3.
IP_DMAMUX_0->CHCFG[4] and TCD4.
IP_DMAMUX_0->CHCFG[5] and TCD5.
IP_DMAMUX_0->CHCFG[6] and TCD6.
IP_DMAMUX_0->CHCFG[7] and TCD7.
IP_DMAMUX_0->CHCFG[8] and TCD8.
IP_DMAMUX_0->CHCFG[9] and TCD9.
IP_DMAMUX_0->CHCFG[10] and TCD10.
IP_DMAMUX_0->CHCFG[11] and TCD11.
IP_DMAMUX_0->CHCFG[12] and TCD12.
IP_DMAMUX_0->CHCFG[13] and TCD13.
IP_DMAMUX_0->CHCFG[14] and TCD14.
IP_DMAMUX_0->CHCFG[15] and TCD15.
IP_DMAMUX_1->CHCFG[0] and TCD16.
IP_DMAMUX_1->CHCFG[1] and TCD17.
IP_DMAMUX_1->CHCFG[2] and TCD18.
IP_DMAMUX_1->CHCFG[3] and TCD19.
IP_DMAMUX_1->CHCFG[4] and TCD20.
IP_DMAMUX_1->CHCFG[5] and TCD21.
IP_DMAMUX_1->CHCFG[6] and TCD22.
IP_DMAMUX_1->CHCFG[7] and TCD23.
IP_DMAMUX_1->CHCFG[8] and TCD24.
IP_DMAMUX_1->CHCFG[9] and TCD25.
IP_DMAMUX_1->CHCFG[10] and TCD26.
IP_DMAMUX_1->CHCFG[11] and TCD27.
IP_DMAMUX_1->CHCFG[12] and TCD28.
IP_DMAMUX_1->CHCFG[13] and TCD29.
IP_DMAMUX_1->CHCFG[14] and TCD30.
IP_DMAMUX_1->CHCFG[15] and TCD31. Re: S32K348-GPIO EIRQ to DMA request Hi Senlent, meantime I tested this same project with my other colleague , which use S32DS version 3.6.3 and Ozone debugger and his results is same as your. Seems that you have right. but I'm completely out what's going on on my side? 😞 Re: S32K348-GPIO EIRQ to DMA request Hi SenLent, I made test on latest S32 DS project and I added more DMA_MUX configurations. Here is screenshot of my setup: and here is result after download build code to our board: As you can see, your described order for assigning DMA_MUX and TCD is not followed. Is this same bug on RTD software or ? Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
It's obvious that this might be related to the debugger you're using, or perhaps the version of the debugger. Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
This is the demo you provided; I haven't made any modifications.
These are my test results.
Re: S32K348-GPIO EIRQ to DMA request here is my project, just adjusted latest one which I attached before I created 2 channel on DMA_MUX_0 as DMA_Channel_0 and DMA_Channel_1. and for these channel is assigned DMA_MUX_0->CHCFG[3] and DMA-MUX_0-CHCFG[2]. Same "mixed" order you can see on DMA_MUX_1 Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
I can't see what the problem is. Could you explain it more clearly, or provide the complete test project so I can tell you where your doubts lie? Re: S32K348-GPIO EIRQ to DMA request Hi SenLent, finaly i found where is "issue" here. Problem is that Ozone and Lauterbach just presenting different way od DMA_MUX->CHCFG and final trick is that these CHCFG register is mapped on MCU side (base adress for DMA_MUX_1 is 0x40284000) in this order: 0x40284000 ->CHCFG[3] 0x40284001 ->CHCFG[2] 0x40284002 ->CHCFG[1] 0x40284003 ->CHCFG[0] 0x40284004 ->CHCFG[7] 0x40284005 ->CHCFG[6] 0x40284006 ->CHCFG[5] 0x40284007 ->CHCFG[4] 0x40284008 ->CHCFG[11] .... see my screenshot below and from this moment my result give me sense and corresponding with your tips 🙂 Thank you for your support and I guess that this ticked can be resolved Re: S32K348-GPIO EIRQ to DMA request Hi@OndrejK
Good， please click "ACCEPT AS SOLUTION" to close this topic.
View full article
