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: OndrejK_0-1784190602227.png so here is my first issue: Which source->request  is dedicated for PTD6(EIRQ14) ? And how is related Table 44 from RM manual? OndrejK_1-1784190821068.png  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. Senlent_0-1784272853624.png 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); Senlent_1-1784689141057.png 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: OndrejK_0-1784795174339.png In Design studio I have next configuration after updating RTD to 7.0.1: OndrejK_1-1784795478141.png 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: OndrejK_0-1785138171795.png and here is result after download build code to our board: OndrejK_2-1785138306423.png 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. Senlent_0-1785142055872.png 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 OndrejK_0-1785316902701.png 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.

[S32K3] [RTD 7.0.1]BCTUモジュールにおける3つの課題 RTDコードバージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206のBCTUモジュールに3つの問題が見つかりました。詳細な問題点は以下のとおりです。   問題 1:ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの 1558 行目で、現在のコードではビットごとの OR 代入を使用しています: BctuBasePtr->FIFOERR |= FifoWatermarkMask;これを直接代入に変更する必要があります: BctuBasePtr->FIFOERR = FifoWatermarkMask;   問題2：ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの567行目と568行目に、既存のコードに誤ったビットシフト演算が含まれています。元のコードは以下のとおりです。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << インデックス) : 0U; これらの2行は、以下のように正しいシフトロジックに修正する必要があります。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (インデックス * 2u)) : 0U;   問題3: MCAL/SDKコード生成ツールとBCTUモジュールの静的ソースコードの間に型の整合性の問題があります。MCAL で生成されたコード ( Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m 、2397行目）では、ヘッダーファイルとCファイルの両方で定義されている配列は、一律にuint32型を採用しています。SDK生成コードでは、ヘッダーファイルとCファイルの型定義が一貫していません。eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.hの配列型は(249行目)は、BctuFifoDmaRawDataオプションが有効になっているかどうかに応じてuint16とuint32を切り替え、対応する配列はeclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.cの対応する配列です（317行目）はuint32型に固定されています。静的コード ( Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 、1629行目）では、送信長（2バイトまたは4バイト）はBctuFifoDmaRawData構成に基づいて動的に決定されます。BctuFifoDmaRawDataオプションのチェックを外すと、以下の異常な問題がすべて発生します。 1.SDKプロジェクトの場合:ヘッダーファイルとCファイルの配列型が不一致で、直接コン パイル失敗を引き起こします。 2. MCALプロジェクトの場合:コンパイルは成功しますが、固定されたuint32配列定義のため メモリ容量の半分が無駄になります。さらに、各uint32データユニットには2つのADC結果が含まれているため、データ解析時にuint16の高値と低値を手動で分割する必要があります。 上記の3つのバグは、公式バージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206に存在します。NXPのソフトウェアエンジニアが次回RTDリリースでこれらのBCTUモジュールの欠陥を修正できることを期待しています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft あなたの質問は社内フォーラムにエスカレーションされており、設計チームからの確認を待っています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft ご意見ありがとうございます。 ソフトウェアチームと私はこれらの問題を確認しましたが、確かにバグです。 これらの問題は社内でエスカレーションしており、今後のアップデートで修正する予定です。

小程序 您好，请问。请问有人能帮帮我吗？ 1.在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？ 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？ B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者 EMVCo 认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要单独的安全元件？ 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的 EMVCo 认证失效？ C. 自定义小程序可使用单调计数器和加密功能 (SE051P) 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？ 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。） 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐特定的去耦电容或缓冲器来处理加密操作期间的 16.5 mA 峰值电流？ 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作是可能的，那么在仅使用场功率的情况下，ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？ 虚拟测试 Re: Applet 嗨@aaschi ， 感谢您的联系！我的评论如下： 1. 在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？// 我们提供有关这些主题的文档，请通过安全文件通道索取。更多详情请参考以下内容。 Kan_Li_0-1784275947082.png 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？是的，需要签署保密协议，并且需要达到最低订购量。请联系您当地的恩智浦代表了解更多详情。 B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者，EMVCo认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要一个单独的安全元件？不，您必须使用两个安全元件——一个经过认证的支付 SE 和一个用于专有逻辑的 SE051P/自定义 SE。 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的EMVCo认证失效？//不，这不可能。 C. 自定义小程序 (SE051P) 可使用单调计数器和加密 // SE05x IoT 小程序文档支持单调计数器安全对象，因此从硬件角度来看，SE051P 也应该支持，但这取决于您的自定义小程序实现。 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？// 您无法在 SE051P 上安装 SE05x 预装的 IoT 小程序，您必须开发自己的自定义小程序。 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ SE05x IoT 小程序支持多种算法和曲线，因此 SE051P 也可能支持，但这取决于您的自定义小程序实现。 D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。）//ECDSAP-256 验证记录为 <55 毫秒；未找到签名计时。主动式非对称加密电流高达 16.5 mA。这些信息来自SE05x IoT 小程序，对于自定义小程序，则取决于您自己的实现。 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐使用特定的去耦电容或缓冲器来处理加密操作期间 16.5 mA 的峰值电流？//否确定了 CR2032 缓冲电容的具体值；设计峰值电流约为 16.5 mA，加上工作时间和电池 ESR。 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作可行，那么在仅使用场强的情况下，诸如 ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？//射频供电支持 SE051 操作，但必须确认和测试对自定义小程序加密/NVM 更新的 RF 专用支持。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: Applet 嗨，Kan， 感谢您的详细解答，非常有帮助。我会将此帖子标记为正确答案。 关于问题 1：我想通过安全文件通道请求您提到的文档（SE051P 的自定义 Java Card 小程序开发路径 — SDK、工具、Java Card / GlobalPlatform 版本和小程序配置）。 请问您能告诉我具体的操作步骤吗？具体来说： 1.我该如何访问安全文件通道？我应该在与此社区帐户关联的 NXP 支持门户上开一个私人支持案例，还是有其他途径？ 2. 在签署保密协议之前，哪些文件可以获取？哪些文件需要通过您在问题 2 中提到的保密协议/当地代表途径获取？ 我现阶段的目标是审查开发路径文档，以规划原型阶段；之后将与当地代表讨论保密协议/最低订购量。 再次感谢， 阿斯基

Applet Hi, please. Can anyone help me? 1. What is the practical development path to build and load a custom Java Card applet on the SE051P (which SDK, tools, and Java Card / GlobalPlatform version)? Is custom-applet provisioning done at the factory (pre-loaded by NXP or a partner), or can it be done post-issuance in the field via a GlobalPlatform secure channel, and what key-management requirements apply? 2. Are there licensing, NDA, or partnership requirements — or a minimum order quantity — to obtain SE051P parts together with the ability to develop and provision custom applets? B. Coexistence of payment and custom logic (one vs. two secure elements) 3. Can a single JCOP Pay (payment) platform host, simultaneously, an EMVCo-certified payment applet AND a separate custom Java Card applet with independent application logic? Or does EMVCo certification require the chip to run only the payment applet — meaning a separate secure element would be required for the custom logic? 4. If coexistence on a single chip is possible, does loading a custom applet affect or invalidate the EMVCo certification of the payment applet? C. Monotonic counter and crypto available to a custom applet (SE051P) 5. Is the native monotonic Counter secure-object accessible from a custom applet via the Java Card API, or only through the pre-installed IoT applet interface? 6. Which signature algorithms and ECC curves are available to a custom applet on the SE051P (e.g., ECDSA P-256/P-384, Ed25519)? Is internal signing of a value stored on-chip (as with the POLICY_OBJ_INTERNAL_SIGN mechanism) available from a custom applet as well? D. Power for a coin-cell (CR2032) device 7. What is the typical duration (in milliseconds) of a single ECDSA P-256 signature operation, and what is the idle/standby current of the SE051P outside active crypto operations? (So that energy per operation and standby drain can be estimated.) 8. For a part powered by a high-impedance source such as a CR2032 coin cell, does NXP recommend a specific decoupling capacitor or buffer to handle the 16.5 mA peak current during a crypto operation? 9. In the SE051P, can the contactless interface operate RF-powered (drawing energy from the reader field) for custom-applet operations, or does custom on-chip logic require external power (e.g., a battery)? If RF-powered operation is possible, are there constraints — under field power alone — on operations such as ECDSA signing, signature verification, monotonic-counter increment, secure-object update, or other non-volatile memory writes? Virtual test Re: Applet Hi @aaschi , Thanks for the reaching out! Please have my comments as below: 1. What is the practical development path to build and load a custom Java Card applet on the SE051P (which SDK, tools, and Java Card / GlobalPlatform version)? Is custom-applet provisioning done at the factory (pre-loaded by NXP or a partner), or can it be done post-issuance in the field via a GlobalPlatform secure channel, and what key-management requirements apply? // We provide docs on these topics, please request them via the secure file channel. please refer to the following for more details. Kan_Li_0-1784275947082.png 2. Are there licensing, NDA, or partnership requirements — or a minimum order quantity — to obtain SE051P parts together with the ability to develop and provision custom applets? // Yes, NDA is needed, and MOQ as well. please check with your local NXP representative for more details. B. Coexistence of payment and custom logic (one vs. two secure elements) 3. Can a single JCOP Pay (payment) platform host, simultaneously, an EMVCo-certified payment applet AND a separate custom Java Card applet with independent application logic? Or does EMVCo certification require the chip to run only the payment applet — meaning a separate secure element would be required for the custom logic?// No, you have to use two secure elements — one certified payment SE and one SE051P/custom SE for proprietary logic. 4. If coexistence on a single chip is possible, does loading a custom applet affect or invalidate the EMVCo certification of the payment applet?// No, it is not possible. C. Monotonic counter and crypto available to a custom applet (SE051P)//The SE05x IoT-applet documentation supports monotonic counter secure objects, so from hardware perspective, it should support by SE051P as well, but it depends on your custom applet implementation. 5. Is the native monotonic Counter secure-object accessible from a custom applet via the Java Card API, or only through the pre-installed IoT applet interface? // you can not install the SE05x pre-installed IoT applet on SE051P, you have to develop your own custom applet.  6. Which signature algorithms and ECC curves are available to a custom applet on the SE051P (e.g., ECDSA P-256/P-384, Ed25519)? Is internal signing of a value stored on-chip (as with the POLICY_OBJ_INTERNAL_SIGN mechanism) available from a custom applet as well? // The SE05x IoT applet supports a broad set of algorithms and curves so SE051P can support but it depends on your custom applet implementation D. Power for a coin-cell (CR2032) device 7. What is the typical duration (in milliseconds) of a single ECDSA P-256 signature operation, and what is the idle/standby current of the SE051P outside active crypto operations? (So that energy per operation and standby drain can be estimated.)//ECDSA P-256 verification is documented as <55 ms; signing timing was not found. Active asymmetric crypto current is up to 16.5 mA. Such info is from The SE05x IoT applet, for a custom applet, it depends on your own implementation. 8. For a part powered by a high-impedance source such as a CR2032 coin cell, does NXP recommend a specific decoupling capacitor or buffer to handle the 16.5 mA peak current during a crypto operation?//No specific CR2032 buffer capacitor value was found; design around 16.5 mA peak plus operation time and cell ESR. 9. In the SE051P, can the contactless interface operate RF-powered (drawing energy from the reader field) for custom-applet operations, or does custom on-chip logic require external power (e.g., a battery)? If RF-powered operation is possible, are there constraints — under field power alone — on operations such as ECDSA signing, signature verification, monotonic-counter increment, secure-object update, or other non-volatile memory writes?//RF-powered SE051 operation is supported, but RF-only support for custom applet crypto/NVM updates must be confirmed and tested. Hope that helps, 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. ------------------------------------------------------------------------------- Re: Applet Hi Kan, Thank you for the detailed answers — very helpful. I will mark the post as correct. Following up on question 1: I would like to request the documents you mentioned (custom Java Card applet development path for the SE051P — SDK, tools, Java Card / GlobalPlatform versions, and applet provisioning) via the secure file channel. Could you please let me know the exact procedure? Specifically: 1. How do I access the secure file channel — should I open a private support case on the NXP support portal linked to this community account, or is there another route? 2. Which of these documents are available before an NDA is in place, and which ones require the NDA / local representative path you mentioned in question 2? My goal at this stage is to review the development path documentation to plan the prototype phase; the NDA/MOQ discussion with the local representative would follow. Thank you again, aaschi

S32K348-GPIO EIRQ 到 DMA 请求 尊敬的恩智浦技术支持团队： 我现在尝试的方法，将 GPIO PTD6 设置为 EIRQ14，上升沿检测，我想将此引脚信号映射到 DMA 通道，我尝试从 PIT_1 Timer[0] 获取当前值。这是自由奔跑模式。 看起来 SIUL2 已正确设置为 PTDA，当信号发生器发出的信号 (1Hz) 连接到相关的 MCU 引脚时，我可以看到该引脚切换。 但是DMA对我来说不起作用 我的猜测是，我的问题在于找不到从 PTD6 -> DMAMUX -> DMA 通道 4 的正确链路，也找不到在哪里可以找到这些信息。 从 S32K3xx_DMAMUX_map.xlsx 文件中我得到了以下内容： OndrejK_0-1784190602227.png 我的第一个问题是：哪个源->请求是专用的 PTD6(EIRQ14)？ RM手册中的表44与此有何关联？ OndrejK_1-1784190821068.png 以下是我目前正在编写的部分代码： 设置 PTD6 void Setup_PTD6_EIRQ14_for_DMA ( void ) { /* 1. 通过 MSCR 寄存器配置物理引脚 PTD6 */     // PTD6 对应于索引 MSCR[102]（如您的屏幕截图所示）     IP_SIUL2 -> MSCR [ 102 ] = 0 ； // 清除寄存器     IP_SIUL2 -> MSCR [ 102 ] |= ( 1 << 19 ); // IBE = 1（输入缓冲使能 - 将引脚配置为输入）     IP_SIUL2 -> IMCR [ 542 - ( 512 )] = 3u ;     // 可选：如果信号是浮动的，您可以启用上拉（PUE=1，PUS=1）或下拉（PUE=1，PUS=0） /* 2. 激活 EIRQ[14] 线上的边缘检测 */     我们希望捕获每个上升沿的时间戳     IP_SIUL2 -> IREER0 |= ( 1 << 14 ); // IREER0[EIRE14] = 1 (启用上升沿)     IP_SIUL2 -> IFEER0 &= ~ ( 1 << 14 ); // IFEER0[EIRE14] = 0 (禁用下降沿) /* 3. 请求路由：从中断更改为 DMA */     // 此步骤确保边沿不会唤醒 CPU（NVIC），而是触发 DMA 线路。     IP_SIUL2 -> DIRSR0 |= ( 1 << 14 ); // DIRSR0[DIRS14] = 1 (选择 DMA 请求而不是中断) /* 4. 最终启用 EIRQ[14] 的 DMA 请求生成 */     IP_SIUL2 -> DIRER0 |= ( 1 << 14 ); // DIRER0[EIRE14] = 1 (激活 DMA 请求线) }   并建立DMA通道： void Setup_eDMA_Channel4_Capture_PIT1 ( void ) { /* 1. eDMA 通道 4 的 DMAMUX 初始化 */     // 将 EIRQ14（源 14）映射到 eDMA 通道 4     IP_DMAMUX_1 -> CHCFG [ 4 ] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE ( 7u ); // EIRQ14 是 DMAMUX_1 的源 7     //IP_DMAMUX_0->CHCFG[4] = 0U; /* 2. 通道 4 的 TCD 配置指向 PIT_1（完全符合 S32K3 裸机语法） */     // 来源：PIT_1 定时器 0 的当前值     IP_TCD -> TCD4_SADDR = ( uint32_t ) & ( IP_PIT_1 -> TIMER [ 0 ]. CVAL );     IP_TCD -> TCD4_SOFF  = 0 ; // 源值不递增     IP_TCD -> TCD4_ATTR  = 0x0202 ； // 32 位源，32 位目标     // 次要循环：每次触发传输的字节数     // 在 S32K3 中，这对应于 NBYTES_MLOFFNO 寄存器（无次要循环链接）     IP_TCD -> NBYTES4 . TCD4_NBYTES_MLOFFNO = 4 ; // 每次触发信号传输 4 字节（32 位）     // 目标位置：内存中的数组     IP_TCD -> TCD4_DADDR = ( uint32_t ) dma_timestamps ;     IP_TCD -> TCD4_DOFF  = 4 ; // 每次边沿移动后，RAM 中的数据左移 4 个字节     // 循环缓冲区：填充完整个数组后循环回到数组开头     IP_TCD -> TCD4_DLAST_SGA = - ( BUFFER_SIZE * 4 );     // 主要循环计数器：循环中的总迭代次数     //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 通道 */     //IP_TCD->CH4_CSR |= DMA_TCD_CH4_CSR_ERQ_MASK; /* 3. 硬件触发信号的 eDMA 通道激活（启用异步模式） */     // 位 0 (ERQ) = 1 -> 启用硬件触发信号     // 位 2 (EARQ) = 1 -> 启用来自外部引脚的异步请求 (SIUL2 EIRQ)     IP_TCD -> CH4_CSR |= 3u ； // ERQ=1，EARQ=1 }   我想关键就在这里： IP_DMAMUX_1 -> CHCFG [ 4 ] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE ( 7u ); // EIRQ14 是 DMAMUX_1 的源 7 我有点困惑，不知道应该使用哪个 IP_DMAMUX 和哪个 DMAMUX_CHCFG_SOURCE，也不知道哪里可以找到相关的正确信息。 此致 翁德雷   Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK “这是否意味着MCU有32个TCD通道，其中TCD 0到15对DMAMUX_0有效，TCD 15到31对DMAMUX_1有效？ ” 是的，这些信息可以在数据手册中找到，我复制下来供您参考。 Senlent_0-1784272853624.png Re: S32K348-GPIO EIRQ to DMA request 你好 Senlent， 感谢您的解答。 请问您能否指出您所说的TCD映射的含义是从哪里产生的？ 这是否意味着，MCU 有 32 个 TCD 通道，其中 TCD 0 到 15 对 DMAMUX_0 有效，而 TCD 15 到 31 对 DMAMUX_0 无效？ 对于 DMAMUX_1？ 所以，我对DMAMUX和eDMA的相关信息仍然有些困惑。 此致 翁德雷 Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 你的理解是正确的： 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 但是，TDC 设置不正确。 我的理解是，它们应该如下所示： IP_DMAMUX_1->CHCFG[0] ->TCD 16 IP_DMAMUX_1->CHCFG[4] -> TCD 20 而不是 TCD4 Re: S32K348-GPIO EIRQ to DMA request 嗨 SenLent， 我根据观察结果对代码进行了一些修改。 这是我最新的代码： 主初始化： Setup_PTD6_EIRQ14_for_DMA ();     setup_PIT1_Timer0_FreeRunning ();     Setup_DMAMUX_Channel0_ToTCD16_Capture_PIT1 ();      //清除 EIRQ14 中断标志      IP_SIUL2 -> DISR0 = ( 1 << 14 ); 以下是其余代码： 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 (bez dodatočného delenia) // 2. Voliteľne vypnite 过滤器预 daný EIRQ 索引 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 digitalálny过滤器，hrana prechádza okamžite ako čistý Hardvérový触发器 /* 1. 通过 MSCR 寄存器配置物理引脚 PTD6 */     // PTD6 对应于索引 MSCR[102]（如您的屏幕截图所示）     IP_SIUL2 -> MSCR [ 102 ] = 0 ； // 清除寄存器     IP_SIUL2 -> MSCR [ 102 ] |= ( 1 << 19 ); // IBE = 1（输入缓冲使能 - 将引脚配置为输入）     IP_SIUL2 -> IMCR [ 542 - ( 512 )] = 3u ;     // 可选：如果信号是浮动的，您可以启用上拉（PUE=1，PUS=1）或下拉（PUE=1，PUS=0） /* 2. 激活 EIRQ[14] 线上的边缘检测 */     我们希望捕获每个上升沿的时间戳     IP_SIUL2 -> IREER0 |= ( 1 << 14 ); // IREER0[EIRE14] = 1 (启用上升沿)     IP_SIUL2 -> IFEER0 &= ~ ( 1 << 14 ); // IFEER0[EIRE14] = 0 (禁用下降沿) /* 3. 请求路由：从中断更改为 DMA */     // 此步骤确保边沿不会唤醒 CPU（NVIC），而是触发 DMA 线路。     IP_SIUL2 -> DIRSR0 |= ( 1 << 14 ); // DIRSR0[DIRS14] = 1 (选择 DMA 请求而不是中断) /* 4. 最终启用 EIRQ[14] 的 DMA 请求生成 */     IP_SIUL2 -> DIRER0 |= ( 1 << 14 ); // DIRER0[EIRE14] = 1 (激活 DMA 请求线) }   void Setup_DMAMUX_Channel0_ToTCD16_Capture_PIT1 ( void ) { /* 1. eDMA 通道 4 的 DMAMUX 初始化 */    // Podľa NXP tabuľky prislúcha SIUL2 DMA 请求 4 zdrojový 索引 7u     //IP_DMAMUX_1->CHCFG[4] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u);     //按照文档操作，先禁用通道 4，然后配置它，最后启用它。     IP_DMAMUX_1 -> CHCFG [ 0 ] = 0u ; /* 2. 通道 4 的 TCD 配置指向 PIT_1（完全符合 S32K3 裸机语法） */     // 来源：PIT_1 定时器 0 的当前值     IP_TCD -> TCD16_SADDR = ( uint32_t ) & ( IP_PIT_1 -> TIMER [ 0 ]. CVAL );     IP_TCD -> TCD16_SOFF  = 0 ; // 源值不递增     IP_TCD -> TCD16_ATTR  = 0x0202 ； // 32 位源，32 位目标     // 次要循环：每次触发传输的字节数     // 在 S32K3 中，这对应于 NBYTES_MLOFFNO 寄存器（无次要循环链接）     IP_TCD -> NBYTES16 . TCD16_NBYTES_MLOFFNO = 4 ; // 每次触发传输 4 字节（32 位）     // 目标位置：内存中的数组     IP_TCD -> TCD16_DADDR = ( uint32_t ) dma_timestamps ;     IP_TCD -> TCD16_DOFF  = 4 ; // 每次边沿移动后，RAM 中的数据左移 4 个字节     // 循环缓冲区：填充完整个数组后循环回到数组开头     IP_TCD -> TCD16_DLAST_SGA = - ( BUFFER_SIZE * 4 );     // 主要循环计数器：循环中的总迭代次数     //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     //启用DMAMUX通道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 ; }   我仍然无法通过 EIRQ(14) 启动 DMA 传输，即使出现此断言。在调试器中，当我改变MCU PTD6引脚上的信号时，可以看到标志出现。 接下来，我可以通过 TCD16_CSR START 位手动启动 DMA 传输，TCD 通道上的 CITTER 值会减小，并且 PIT1_TIMER[0] 中的值会被存储到我的 dma_timestamps 数组中。 顺便说一下：这应该在“普通”SRAM部分定义。我之前将其设置为数据缓存段，导致出现 DMA“目标总线错误”。 新定义： __attribute__ ((对齐( 32 ))) __attribute__ ((部分( ".mcal_data" ))) uint32_t dma_timestamps [ BUFFER_SIZE ];   但是，如果我跳过手动 START（从代码开始就不需要设置），并且我更改 PTD6 引脚上的信号，DMA 通道不会执行任何操作，CITTER 寄存器保持在初始化值。 请问您能帮我找出问题所在吗？ 我仍然认为 PTD6-EIRQ(14) 钳位标志与 TCD16 通道之间的连接存在问题。 可能是DMAMUX通道的正确来源？ 对于 DMAMUX1-CH[0]，我测试了所有信号源（1 到 😎 我尝试了DMAMUX Excel表格中列出的SUIL2实例，但没有成功，而且我也不确定我的步骤是否正确。     Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 我创建了一个演示供您参考，使用 PTD6 触发 DMA 进行单次数据传输。 它基于 S32K344 + RTD 7.0.1。 我已经测试过了； 我可以向你保证，我的理解是正确的。 对于 PTD6，来源应为 7。  IP_DMAMUX_1 -> CHCFG [ 0 ] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE ( 7u ); Senlent_1-1784689141057.png Re: S32K348-GPIO EIRQ to DMA request 你好 Senlent， 非常感谢你提供的例子。 经过一些修改，我现在有了可以运行的示例。我附上了修改后的项目文件，其中存在一个重要问题： 在整个 DMA TCD 通道完全配置之前，已设置了启用 DMA 请求的 SIUL ICU。在这种情况下，TCD_SADDR 和 TCD_DADDR 为空（值为零），之后在 SUIL 中启用 DMA 请求导致 DMA 错误 - “源总线错误”，这让我明白了。 更改初始化顺序后。例如，它开始对我有用。 但我仍然不太理解DMAMUX通道和TCD通道之间的确切关系。 您写道，DMAMUX 应该配置为 CHCGF[0]。 在我们的 S32k344 定制开发板上下载并启动应用程序后，我发现 DMAMUX-CHCFG[3] 已配置，并且确切地说，在函数Dma_Mux_Ip_Init_Privileged 的代码行中，有一行代码导致了此配置： RegisterIndex = DMA_MUX_IP_GATE_OFFSET((pConfig->pChannelConfigArr[ChannelCount].Channel)); 这是 lauterbach Trace32 调试器的屏幕截图，您可以在其中看到所有初始化步骤之后的最终设置： OndrejK_0-1784795174339.png 在将 RTD 更新到 7.0.1 版本后，我在 Design Studio 中配置如下： OndrejK_1-1784795478141.png 这样理解是否正确？这里可以选择 3 个 DMA 复用源，这意味着什么？ Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 听到这个消息真好。 对于刚入门的开发人员来说，这个配置工具可能会让他们感到困惑。 对于 S32K348，没有 DMAMUX_3；只有 DMAMUX_0 和 DMAMUX_1。 •对于 S32K310、S32K311 和 S32K312：DMAMUX_0 通道 0–5 和 DMAMUX_1 通道 0–5 分别映射到 eDMA 传输控制描述符 (TCD) 0–5 和 eDMA 传输控制描述符 (TCD) 6–11。因此，不应编程 DMAMUX_0 通道 6-15 和 DMAMUX_1 通道 6-15；但是，如果进行了编程，任何访问都将导致通道 8-15 出现错误响应，或者通道 6-7 没有错误响应。 •对于其余的 S32K3xx 设备：DMAMUX_0 通道 0–15 和 DMAMUX_1 通道 0–15 分别映射到 eDMA 传输控制描述符 (TCD) 0–15 和 eDMA 传输控制描述符 (TCD) 16–31。 以上内容摘自数据手册，很容易理解： “ DMA硬件通道”对应于TCD编号。 当您选择 DMA_CHANNEL_0 到 DMA_CHANNEL_15 时，默认使用 DMAMUX_0； 当您选择 16–31 时，默认使用 DMAMUX_1。 例如，在本主题中，PTD6 对应于 DMAMUX_1 的源 7，因此“DMA 硬件通道”可以设置为 DMA_CHANNEL_16 到 DMA_CHANNEL_31 之间的任何值。 我们再举一个例子：如果您选择 EIRQ 7 来触发 DMA，则“DMA 硬件通道”可以设置为 DMA_CHANNEL_0 到 DMA_CHANNEL_15 之间的任何值。 Re: S32K348-GPIO EIRQ to DMA request 嗨 SenLent， 关于选择DMA通道，我的想法是可以从相关的DMA_MUX组中自由选择一个。 同时，我测试了其他 DMA_MUX<-> 和 TCD 的组合，在我这边只有下一个组合可以正常工作。 IP_DMAMUX_1->CHCFG[3] 和 TCD16。 接下来我尝试了其他方法： IP_DMAMUX_1->CHCFG[4] 和 TCD17。 IP_DMAMUX_1->CHCFG[0] 和 TCD16。 请问为什么只有 IP_DMAMUX_1->CHCFG[3] 和 TCD16？在职的 ？ IP_DMAMUX_1->CHCFG[xx] 与 TCDyy 之间是什么关系？ Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 正确的顺序是： IP_DMAMUX_0>CHCFG[0] 和 TCD0。 IP_DMAMUX_0->CHCFG[1] 和 TCD1。 IP_DMAMUX_0->CHCFG[2] 和 TCD2。 IP_DMAMUX_0->CHCFG[3] 和 TCD3。 IP_DMAMUX_0->CHCFG[4] 和 TCD4。 IP_DMAMUX_0->CHCFG[5] 和 TCD5。 IP_DMAMUX_0->CHCFG[6] 和 TCD6。 IP_DMAMUX_0->CHCFG[7] 和 TCD7。 IP_DMAMUX_0->CHCFG[8] 和 TCD8。 IP_DMAMUX_0->CHCFG[9] 和 TCD9。 IP_DMAMUX_0->CHCFG[10] 和 TCD10。 IP_DMAMUX_0->CHCFG[11] 和 TCD11。 IP_DMAMUX_0->CHCFG[12] 和 TCD12。 IP_DMAMUX_0->CHCFG[13] 和 TCD13。 IP_DMAMUX_0->CHCFG[14] 和 TCD14。 IP_DMAMUX_0->CHCFG[15] 和 TCD15。 IP_DMAMUX_1->CHCFG[0] 和 TCD16。 IP_DMAMUX_1->CHCFG[1] 和 TCD17。 IP_DMAMUX_1->CHCFG[2] 和 TCD18。 IP_DMAMUX_1->CHCFG[3] 和 TCD19。 IP_DMAMUX_1->CHCFG[4] 和 TCD20。 IP_DMAMUX_1->CHCFG[5] 和 TCD21。 IP_DMAMUX_1->CHCFG[6] 和 TCD22。 IP_DMAMUX_1->CHCFG[7] 和 TCD23。 IP_DMAMUX_1->CHCFG[8] 和 TCD24。 IP_DMAMUX_1->CHCFG[9] 和 TCD25。 IP_DMAMUX_1->CHCFG[10] 和 TCD26。 IP_DMAMUX_1->CHCFG[11] 和 TCD27。 IP_DMAMUX_1->CHCFG[12] 和 TCD28。 IP_DMAMUX_1->CHCFG[13] 和 TCD29。 IP_DMAMUX_1->CHCFG[14] 和 TCD30。 IP_DMAMUX_1->CHCFG[15] 和 TCD31。 Re: S32K348-GPIO EIRQ to DMA request 嗨 SenLent， 我在最新的 S32 DS 项目上进行了测试，并添加了更多 DMA_MUX 配置。 这是我的设置截图： OndrejK_0-1785138171795.png 以下是将版本代码下载到我们的板后的结果： OndrejK_2-1785138306423.png 如您所见，您所描述的 DMA_MUX 和 TCD 的分配顺序并未得到遵循。 RTD软件也存在同样的bug吗？ Re: S32K348-GPIO EIRQ to DMA request 这是我的项目，我只是调整了我之前附上的最新版本。 我在 DMA_MUX_0 上创建了 2 个通道，分别命名为 DMA_Channel_0 和 DMA_Channel_1。 对于这些通道，分配了 DMA_MUX_0->CHCFG[3] 和 DMA-MUX_0-CHCFG[2]。 DMA_MUX_1 上也出现了同样的“混合”顺序。 Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 这是您提供的演示版本；我没有做任何修改。 这是我的检测结果。 Senlent_0-1785142055872.png Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 我看不出问题出在哪里。您能否解释得更清楚一些，或者提供完整的测试项目，以便我能告诉您您的疑问出在哪里？ Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 很明显，这可能与您使用的调试器或调试器的版本有关。 Re: S32K348-GPIO EIRQ to DMA request 你好 Senlent， 同时，我与另一位同事一起测试了同一个项目，他使用的是 S32DS 3.6.3 版本。Ozone调试器及其结果与你的相同。 看来你是对的。但我完全不清楚我这边发生了什么？ 😞 Re: S32K348-GPIO EIRQ to DMA request 嗨 SenLent， 我终于找到问题所在了。 问题在于 Ozone 和 Lauterbach 只是提出了不同的 DMA_MUX->CHCFG 方法，最终的技巧是这些 CHCFG 寄存器在 MCU 端按以下顺序映射（DMA_MUX_1 的基地址为 0x40284000）： 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] …… 请看我下面的截图 OndrejK_0-1785316902701.png 从现在开始，我的结果让我有所感知，也与你的建议相符。 🙂 感谢您的支持 我想这个问题应该可以解决。 Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 好的，请点击“接受为解决方案”关闭此主题。

i.MX8QMマルチディスプレイセットアップでのAAOS 15ユーザースイッチクラッシュ こんにちは、チームの皆さん、 私たちは Android オートモーティブ OS 15(AAOS 15) を i.MX8QuadMax ボード 上で マルチ ディスプレイ 構成( メイン ディスプレイ + 乗客 ディスプレイ)で動かしています。 ユーザー 切り替え 時に デフォルトの Car Launcher に 問題 が発生しています: システムは 正常に 起動し 、 ランチャー は メインディスプレイ と 助手席側 ディスプレイの 両方 に 表示され ます 。 現在の ユーザー から 新規ユーザー や ゲスト ユーザーに 切り替え ると 、 メイン ディスプレイ と 乗客 用ディスプレイ の両方 が クラッシュ し、 使用不能 になります 。 The issue is consistently reproducible after ユーザー switching. 私たちは 以下のこと を 知り たい のです 。 i.MX8QM マルチ ディスプレイ システム での AAOS 15 での ユーザー スイッチ ングに関する 既知 の問題 はありますか? Are there any additional configurations required for passenger display handling during user スイッチ? この 問題 を さらに 分析する ために、 どのような ログ や デバッグ 情報 を 収集 す べきでしょうか ？ 何かご提案やアドバイスがあれば、ぜひお聞かせください。 ありがとうございます。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup こんにちは、 @AldoG さん。 ご説明ありがとうございます。   弊社で は、 NXP BSPを搭載したNXP i.MX8QM MEK ボード を 使用 し ています 。この 問題 は Android オートモーティブに関連しているため、 AAOS関連 の適切な サポート チャネル や フォーラム を 教え ていただければ 幸いです 質問はありますか? ありがとうございます。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup こんにちは、 NXP MEKボードを使用していますか？ もしそうなら、NXP BSPを使っていますか? なお、当サイトはAndroid オートモーティブをサポートしていませんが、BSPリリースで問題が発生した場合は支援が可能です。 よろしくお願いいたします。 アルド。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup こんにちは、 @AldoG さん。 ご 回答 ありがとうござい ます 。完全 な ログキャット、 再現 手順、 および マルチディスプレイを実現するために行った変更点 を添付し まし た 。 再現手順： センター ディスプレイ と 助手席 ディスプレイ を有効にした 状態で、 i.MX8QM 上で AAOS 15 を起動します 。 Open ユーザー Settings on the passenger display. 乗客ディスプレイで 新しいユーザー/ゲストユーザーにスイッチすることもできます。 ユーザー 切り替え 時、 com.android.car.carlauncher は 以下の動作で クラッシュします:   android.view.WindowManager$InvalidDisplayException: ウィンドウを追加できない場合――指定された表示が見つからない ログを見る限り、CarLauncher はユーザー切り替え 後に 使 えな くなった ディスプレイや 無効 な 表示 マッピングで再開しようとしているようです 。 CAN you please advise: これは i.MX8QM の AAOS 15 マルチ ユーザー/マルチディスプレイ シナリオ で 既知 の問題 な のでしょうか? ユーザー 切り替え 時に ディスプレイ を 割り当て る のは どの コンポーネント(OccupantZone、 CarUserService、 TaskDisplayArea、 または WindowManager)ですか? 二次 ディスプレイ での ランチャー 起動 に関する MUMD(マルチユーザー マルチディスプレイ) サポート に関する 既知 の 要件 や パッチ はありますか? Is there any recommended debug information we should collect to identify why the display becomes invalid after the user スイッチ?

Regarding the RTC_XTALI signal processing of MIMX9121CVVXCAA Hello, I am considering using the i.MX91 SOC MIMX9121CVVXCAA. Question: The clock for the RTC uses the clock from the oscillator circuit inside the SOC, eliminating the need for an external oscillator. I'm planning to leave the RTC_XTALI and RTC_XTALO pins unconnected. Should I pull down the RTC_XTALI pin on the board? I look forward to your reply. Re: MIMX9121CVVXCAAのRTC_XTALI信号処理について Recommendation If RTC functionality is required, follow the recommendation in UG10147 and use an external 32.768 kHz crystal (with the appropriate load capacitors), or alternatively provide an external clock to RTC_XTALI with a frequency below 50 kHz and an amplitude not exceeding NVCC_BBSM_1P8. If the RTC is not used, simply leave RTC_XTALI and RTC_XTALO unconnected (NC). Do not add a pull-down resistor. In addition, ensure that the insulation resistance from these traces to power and ground remains greater than 100 MΩ to avoid leakage caused by flux residue, moisture, or coupling to adjacent traces. The i.MX 91 does not have an independently operating internal 32.768 kHz oscillator. Therefore, if RTC functionality is not required, RTC_XTALI and RTC_XTALO should be left NC, and a pull-down resistor should not be added. This is because the datasheet specifies that the leakage path from these pins to power or ground should be greater than 100 MΩ. 推奨事項 RTC機能が必要な場合は、UG10147 の推奨に従い、32.768 kHz水晶発振子（負荷容量を含む）を接続するか、RTC_XTALI に周波数50 kHz未満、振幅が NVCC_BBSM_1P8 を超えない外部クロックを入力してください。 RTC機能を使用しない場合は、RTC_XTALI と RTC_XTALO の両方を NC（未接続） のままとしてください。プルダウン抵抗は追加しないでください。 また、フラックス残渣、湿気、または隣接配線によるリーク電流を防ぐため、これらの配線と電源／GND間の絶縁抵抗が 100 MΩ以上 となるようにしてください。 i.MX 91 には、単独で動作する内蔵32.768 kHz発振器はありません。 したがって、RTC機能を使用しない場合は、RTC_XTALI および RTC_XTALO を NC（未接続） のままとし、プルダウン抵抗を追加しないでください。データシートでは、これらのピンから電源またはGNDへのリーク経路は 100 MΩ以上 であることが要求されています。

S32Kコンパレータの許容差/オフセット S32K116の比較器でテストを行っています。 入力電圧(238mV)をINN(またはINP)に印加し、バンドギャップを基準にしてからVOSELを0から255に上げ、コンパレータ出力の変化を監視します。 入力電圧とバンドギャップの接続を入れ替えると、MCU2で異なる許容誤差/オフセットが見られるという現象が見られます。（詳細はテスト1およびテスト2を参照） 1) これはVAIOのような既知の機能なのでしょうか、それとも他の何かですか? 2) この許容差/オフセットについて安定していますか?また、校正でこれを除去できますか? （例えば、目標電圧におけるトリガーVOSELを記録するなど） テスト1：入力電圧V-、バンドギャップV+ 、低速モード Sid_Zhou_5-1784193940847.png テスト2：入力電圧V+、バンドギャップV- 、低速モード Sid_Zhou_6-1784193974436.png Re: S32K comparator tolerance/offset 1) 入力ピン CMP0_INは常にチャンネル0に設定されています。(ピン26、PTA0) はい、入力電圧は同じCMP0_INピン26、PTA0を通じて入力されています。 2) バンドギャップ 私が知りたいのは、2つのMCUの違いではありません。INNとINPを入れ替えたときの同じMCUからの許容差やオフセットの違いが原因です。この交換操作の間、バンドギャップは変化しないはずだと私は考えています。(ここでのMCU1のデータはあくまで参考資料として利用しています) 3)VDD/VDDA: 2つのMCUは同じ+3.3Vネットワーク(LDO許容範囲内)を使っています。 MCUのバンドギャップに違いがあることは十分理解していますが、やはり交換時の違いを確認しています。 4) 試験方法 上記のテストデータは入力電圧を上げているのではなく、固定入力電圧を使い、VOSELを上昇させています。(VOSELを減らす方法はまだテストしていませんが、後で確認します。) 固定VOSELで入力電圧を上下に調整する場合、同様の-9mVがあります。 IncreaseInput_FixedVOSEL.PNG 5) ヒステリシス 低速モードでのヒステリシスに関するテストデータはあります。 ここでのテストデータは、入力電圧を固定し、VOSELを増加させるものです。 Hysteresis_LowSpeedMode.PNG 6) MCUの写真 添付の写真「MCU1.PNG」と「MCU2.PNG」を参照してください。 はんだマスクは FS32K11-6LFMFM-ON96V-S12YM16 Re: S32K comparator tolerance/offset こんにちは、Sid_Zhouさん。 入力電圧はどのCMP0_INピンに接続していますか？ INNとINPを入れ替えた場合、入力電圧は依然として同じCMP0_INピンを通して入力されますか？ また、バンドギャップ電圧の範囲は0.97～1.03Vです。2つのMCUのバンドギャップ電圧の違いによって引き起こされる問題を、一時的に除外することを検討しましたか？例えば、より正確な外部電圧基準を入力するために別のCMP0_INピンを使うことはできますか? 2つのS32K1のVDD/VDDA電圧が同じかどうか確認しましたか？ デバッグ中にOFFSET=1およびHYSTCTR=0であることが確認されていましたか？ 入力電圧を上げてVOSELを記録したことに気づきました。入力電圧を下げてVOSELを記録するテストは行いましたか？また、 アナログ比較器のヒステリシス が影響を受けているかも確認してください。ただし、HYSTCTR=0に設定されているようですね。 S32K116写真を2枚撮って、MCUのマスクについて教えてくれ。 よろしくお願いいたします ロビン Re: S32K comparator tolerance/offset 詳しいご説明をありがとうございました。S32K1のデータシートにある VAIO (アナログ入力オフセット電圧)パラメータについてご懸念されていることが理解できました。 内部では、AEチームの説明を見ました: AIOオフセットはコンパレータ自体のオフセットです。INPとINNのオフセットです。 INL誤差はDNLに関する積分であるため、DNL誤差を含みます。 エラーは |V_AIO| + |INL| となります。 私の理解では、外部信号源から直接2つのアナログ電圧を入力 INP と INN にそれぞれ使い、 VAIO をテストする方がバンドギャップ電圧分圧器を使うよりも直感的だと思います。 ご質問についてですが、同じMCUの場合、VAIOは瞬間ごとにランダムに変わる値ではありませんが、動作条件、特に温度によって変動することもあります。データシートのVAIO値は、全温度範囲にわたる保証/最悪ケースの限界として理解すべきです。 しきい値を設計する際には、VAIOを無視できる値、または固定された校正済み値として扱わないでください。マージンは最悪の温度|VAIO|、さらにDAC/INLエラーも加わります。 また、以前の S32K116 コンパレータ許容についての議論も確認しました。 CMPの精度は、お客様のニーズを満たしていないようです。S32K1XXRM Rev14.2の「 44.5.5 自動比較機能 」の項で説明されている機能について検討されましたか？ S32K1データシート Rev15の「 表41. 12ビットADC特性（2.7V～3V） 」には、最大 TUE が±8LSBと記載されています。これはCMPよりも正確であるように思われる。 Re: S32K comparator tolerance/offset 詳しい説明をありがとうございました。 ADCの方が私たちのアプリケーションでは精度が高いかもしれないと指摘しました。 しかし、なぜか高レベルアーキテクチャからCMPをセーフティモニターとして使う要件があり、これをADCに変更できるかはわかりません。

S32 Design Studio for ARM v2.2のライセンスは期限切れです こんにちは、私のARM v2.2用のS32 Design Studio ライセンスが期限切れになりました。延長してもらえますか? 有効期限：2026年6月29日 製品:ARM v2.2用S32 Design Studio ライセンス：27ED-C7E9-C2B4-9D3E Re: license of S32 Design Studio for ARM v2.2 has expired こんにちは、 お客様のS32DSライセンスが延長されました。

HSE INSTALL S32K311 All the content below is copied from the attachment. S32DS version: S32DS.3.5_b220726_win32.x86_64 (1).exe RTD version: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 Support Package Version: SW32K3_S32DS_3.5.6_D2309.zip SBAF version: SBAF_S32K311_0_0_15_0 Bin file: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSE version: HSE_FW_S32K311_0_2_40_0 The bin file is s32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pink Use FULL_MEM No safe boot A problem currently encountered The program will get stuck here: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );` 图片3.png   图片4.png 图片1.png 图片5.png   图片6.png   图片2.png     Re: HSE INSTALL S32K311 This is supplementary printf information. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC configuration word -0x4039C02C: 0x00000000 Lifecycle-related information - 0x402AC200: 0x00000000 HSE Status: 0x00000000 I've looked up information online, and it seems the SBAF that comes with the chip doesn't recognize the HSE firmware I'm currently using. Re: HSE INSTALL S32K311 I suspect that SBAF failed to copy the HSE firmware from the flash memory to the HSE_NVM. If this is the problem, how should I resolve it? Re: HSE INSTALL S32K311 This is the data I printed. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSE Status: 0x00000000 HSE firmware not started (NVM empty or firmware corrupted) 111.png Re: HSE INSTALL S32K311 Hi @iiiddd  Could you please share the value of HSE_CONFIG_GPR3 (0x4039C028)? Bit 0 indicates whether the HSE Firmware is present. BR, VaneB Re: HSE INSTALL S32K311 The RTD library I'm using is called when writing UTEST. gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); The FLS_MAX_VIRTUAL_SECTOR definition will be used. My RTD library defaults to 135, but accessing the address 0x1B000000UL requires 136. Is the RTD library I'm using incompatible with HSE? Re: HSE INSTALL S32K311 Hi @iiiddd  The HSE_CONFIG_GPR3[0] bit is not set, which indicates that the HSE hardware is not present on the device. For reference, the following image shows an example of a linker file configured for the installation of the HSE FW FULL_MEM on an S32K311 device: VaneB_0-1784568701705.png Re: HSE INSTALL S32K311 When I was debugging, I found that there were data in the pflash corresponding to the hse firmware. Do you mean that sbaf failed to copy the firmware in the pflash to the hsenvm? If this is the problem, what might have caused it?

关于 MIMX9121CVVXCAA 的 RTC_XTALI 信号处理 您好，我正在考虑使用 i.MX91 SoC MIMX9121CVVXCAA。 问题： RTC 的时钟使用 SoC 内部振荡器电路的时钟，无需外部振荡器。 我计划将 RTC_XTALI 和 RTC_XTALO 引脚断开。我是否应该将板上的 RTC_XTALI 引脚拉低？期待您的回复。 Re: MIMX9121CVVXCAAのRTC_XTALI信号処理について 推荐 如果需要 RTC 功能，请按照UG10147中的建议，使用外部 32.768 kHz 晶体（带适当的负载电容），或者为RTC_XTALI提供频率低于 50 kHz 且幅度不超过NVCC_BBSM_1P8 的外部时钟。 如果 RTC 未使用，只需将RTC_XTALI和RTC_XTALO断开连接 (NC) 即可。不要添加下拉电阻。此外，确保这些走线到电源和地线的绝缘电阻大于100 MΩ ，以避免因焊剂残留、湿气或与相邻走线耦合而引起的泄漏。 i.MX 91 没有独立运行的内部 32.768 kHz 振荡器。因此，如果不需要 RTC 功能，则RTC_XTALI和RTC_XTALO应保持NC 状态，并且不应添加下拉电阻。这是因为数据手册规定，这些引脚到电源或地的漏电路径应大于100 MΩ 。 推奨事项 RTC机能が必要な场合は、 UG10147の推奨に従い、32.768kHz水晶発振子（负担负担を含む）を接続するか、 RTC_XTALIに周波数50 kHz未満、振幅がNVCC_BBSM_1P8を超えない外部クロックを入力してください。 RTC机能を使用しない场合は、 RTC_XTALIとRTC_XTALOの両方をNC （未接続）のままとしてください。プルダウン抵抗は追加しないでください。また、furakkusu残渣、湿気、または邻接配线によるリーク电流を防ぐため、これらの配线と电源／GND间の绝縁抗が100 MΩ以上となるようにしてください。 i.MX 91 には、単独で动作する内蔵32.768 kHz発振器はありません。したがって、RTC机能を使用しない场合は、 RTC_XTALIおよびRTC_XTALOをNC （未接続）のままとし、プルダウン抵抗を追加しないでください。データshitoでは、これらのピンから电源またはGNDへのリーク経路は100 MΩ以上であることが要求されています。

Local Access Windows (LAWs), memory overlap About LAW understanding : about the B4860 , just e.g B4860QDS; Local Access Windows (LAWs): in the B4860_QDS_Init.tcl file have set the Local Access Window Registers (as below have defined the phy address 0x000000, size 2Gbytes target to DDR) and in the  dpaa_demo.c of CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos add the LAW setting the phy address 0x20000000 target  to  QMAN my query or confusing is  the LAW 10 setting (0x0000000~0x7fffffff target to DDR)   memory overlapped with  QMAN software port  LAW setting the phy address 0x20000000 target  to  QMAN. memory overlapped  between LAW , is it ok? and can explain detail why it can work ? there is not descript memory overlapped situation of LAW  in the reference manual of B4860.  ## LAW10 to DDRC2  # LAWBARH  mem [CCSR_ADDR 0x000CA0] = 0x00000000  # LAWBARL  mem [CCSR_ADDR 0x000CA4] = 0x00000000  # LAWAR  mem [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap It’s interesting how local administrative systems handle data integration, especially when managing complex files like local access windows and memory overlap. Navigating these technicalities can sometimes feel as complicated as dealing with a newsportnewscourt.org schedule. Having a reliable, centralized resource to clear up the confusion makes a huge difference. Hopefully, more updates will roll out soon to make these processes much smoother for everyone involved. Re: Local Access Windows (LAWs), memory overlap Thanks for sharing the [RTD200P04 MCAL] S32M244 PWM PDB ADC MCAL demo—really helpful for developers working with embedded systems. For those handling compliance or security logging alongside hardware interfaces, reviewing Missouri offense records could offer useful insights for managing real-world data inputs. Always good to bridge technical applications with broader contextual awareness. Re: Local Access Windows (LAWs), memory overlap Please refer to the B4860 QorIQ Qonverge Multicore Baseband Processor Reference Manual, 2.3.1 Precedence of Local Access Windows.

S32 Design Studio for ARM v2.2 的许可证已过期。 您好，我的 S32 Design Studio for ARM v2.2 许可证已过期。你能帮我延长一下吗？ 有效期至：2026年6月29日 产品：S32 Design Studio for ARM v2.2 许可证：27ED-C7E9-C2B4-9D3E Re: license of S32 Design Studio for ARM v2.2 has expired 你好， 您的S32DS许可证已延期。

ローカルアクセスウィンドウ(LAW)、メモリの重複 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> LAWの理解について：B4860について、例えばB4860QDSなど。 ローカルアクセスウィンドウ(LAW): B4860_QDS_Init.tclファイル内でローカルアクセスウィンドウレジスタを設定しています(以下のように、phyアドレス0x000000、サイズ2GbytesのターゲットをDDRに定義しています) CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos の dpaa_demo.c 内 LAW設定をQMANに物理アドレス0x20000000ターゲットとして追加します。 私の疑問や混乱は、LAW 10の設定(0x0000000~0x7fffffff ターゲットをDDRに)メモリがQMANソフトウェアのポートLAWと重なっていて、ターゲット0x20000000のPHYアドレスをQMANに設定したことです。 記憶がLAWで重なっているのですが、大丈夫ですか?そして、なぜそれが機能するのか詳細を説明できますか?B4860の**リファレンス・マニュアル**には、LAWのメモリ重複状況の記述はありません。 ## LAW10からDDRC2へ # ローバー mem [CCSR_ADDR 0x000CA0] = 0x00000000 # LAWBARL mem [CCSR_ADDR 0x000CA4] = 0x00000000 # 戦争 mem [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap ローカル管理システムがデータ統合をどのように扱うかは興味深いです。特にローカルアクセスウィンドウやメモリの重複のような複雑なファイルを管理する際には。こうした細かい問題を乗り越えることは、時に、newsportnewscourt.org を扱うのと同じくらい複雑に感じることがありますスケジュール。混乱を解消するための信頼できる一元化された情報源があることは、非常に大きな違いを生む。関係者全員にとってこれらのプロセスがよりスムーズになるよう、近いうちにさらなるアップデートが実施されることを期待します。 Re: Local Access Windows (LAWs), memory overlap [RTD200P04 MCAL] S32M244 PWM PDB ADC MCALのデモを共有していただきありがとうございます。組み込みシステムを開発している開発者にとって非常に役立ちます。コンプライアンスやセキュリティログをハードウェアインターフェースと併用する方にとって、 ミズーリ州のオフェンス記録 を確認することは、実際のデータ入力を管理するための有用な洞察を提供するかもしれません。技術的なアプリケーションとより広い文脈認識をつなぐのはいつも良いことです。 Re: Local Access Windows (LAWs), memory overlap <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> B4860 QorIQ Qonverge マルチコアベースバンドプロセッサリファレンスマニュアル2.3.1「ローカルアクセスウィンドウの優先順位」をご参照ください。

NXPはMC33XS2410のプロトタイピング用にシンプルなTSSOP28ブレークアウト/アダプタボードを提供していますか？ こんにちは、皆さん 現在、12Vの自動車プロジェクトのためのプロトタイピングとテストベンチを設置中です。NXP社の推奨に従い、保護回路にはMC33XS2410（eFuse）を選定しました。 しかし、私たちは組み立て工房で、現時点ではカスタムPCBの**デザイン**や製造ができないため、0.65mmのピッチとサーマルパッドを持つHTSSOP28**パッケージ**の扱いは手配線にとって物理的に難しいです。 フル機能のFRDM-XS2410EVB評価ボードは認識していますが、この特定のテストベンチでの即時のニーズには複雑すぎ、規模も高すぎます。ピンにアクセスするための最小限の方法だけで十分です。 Aries ElectronicsのLCQT-TSSOP28ブレイクアウトボードのような汎用サードパーティアダプターを購入する前に、NXPコミュニティにお聞きしたいと思います。 NXPは、MC33XS2410のHTSSOP28パッケージを標準の2.54mm DIPピンに変換するための、低コストで最小限のブレイクアウトボードやプロトタイピングアダプターを提供していますか? そうでない場合、NXPは、このチップとの互換性が実証されている特定のサードパーティ製アダプタまたはソケットのブランドを公式に推奨していますか（露出した中央パッドの接地および放熱要件を考慮して）？ お時間とご協力、本当にありがとうございました！ 評価ボード StarCore DSP Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping トーマスさん、説明と注意点を教えていただきありがとうございます。私のカードに関しては、それが解決策だと思います。 Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping こんにちは、モハメドさん。 現在、MC33XS2410 HTSSOP28パッケージを標準の2.54 mm DIPスタイルのフットプリントに直接変換する専用の低コストブレイクアウトボードやアダプターボードは提供していません。ご指摘の通り、私たちはFRDM-XS2410EVBを提供しており、これは単純なパッケージ適応ではなく、完全な機能評価を目的としています。 重要な考慮点の一つは、MC33XS2410パッケージの露出したサーマルパッドであり、熱性能と電気性能の両方を考慮してGNDにはんだ付けされるべきです。また、露出パッドをグラウンドプレーンに接続し、生産設計では熱放散を改善するために熱ビアを使用することも推奨しています。 また、汎用ブレークアウトボードは、一般的に機能プロトタイプの作成や低消費電力のベンチテストに適している点にご注意ください。しかし、適切に設計されたPCBで得られる熱性能を通常は提供できず、テスト可能な最大連続電流を制限する可能性があります。 もし用途がデバイスの電流制限付近で動作する必要がある場合は、熱性能を慎重に評価するか、公式の評価ボードを使うことをお勧めします。 BRs、トーマス

S32K312 EVB - SD Card SPI Initialization using LPSPI Hardware PCS0 Hi, I am implementing an SD Card driver over SPI on the S32K312 EVB using RTD 6.0.0 (Non-AUTOSAR Lpspi_ Ip driver). According to the SD Physical Layer Simplified Specification, the SPI initialization sequence is: Keep CS HIGH after power-up. Generate at least 74 clock pulses (I am sending 80 clocks by transmitting 10 bytes of 0xFF). Pull CS LOW. Send CMD0 (0x40 00 00 00 00 95). Keep CS LOW while polling with 0xFF until the card responds with **R1 = 0x01`. My issue is with hardware-controlled PCS0. When using the Lpspi_Ip driver with hardware PCS0, the PCS signal is automatically asserted/deasserted by the LPSPI peripheral during SPI transfers. Because of this, I cannot generate the initial 80 clock pulses while keeping CS HIGH and then CMD0 with CS LOW, as required by the SD specification. I have the following questions: Does the S32K312 LPSPI peripheral support keeping PCS inactive (HIGH) while generating SPI clocks? Is there any Lpspi_Ip API, register configuration, or recommended method to manually control PCS or temporarily disable hardware PCS during the SD card initialization sequence? If not, is the recommended approach to configure the SD card CS pin as a GPIO and manually control it while using LPSPI only for SCK, MOSI, and MISO? Additionally, if NXP has any reference implementation, application note, example project, or SDK/RTD example demonstrating SD card communication over SPI on the S32K3 series, could you please share the reference? Thank you. Re: S32K312 EVB - SD Card SPI Initialization using LPSPI Hardware PCS0 Hi @parvathitp  The PCS (Peripheral Chip Select) signal is designed to be controlled by the LPSPI module. When a hardware PCS is selected, it is automatically asserted and deasserted by the LPSPI peripheral during SPI frame transfers. There is no dedicated API available to manually control a hardware PCS signal while it is assigned to the LPSPI module. Therefore, as you mentioned, the best approach for this case is to configure the CS pin as a GPIO. In this configuration, the CS signal is controlled through the SIUL2/GPIO APIs, and you are responsible for controlling it.  Currently, there is no S32K3-specific application note, example project, or reference document that demonstrates this exact implementation. BR, VaneB

NXP是否提供用于MC33XS2410原型设计的简易TSSOP28分线/适配器板？ 大家好， 我们目前正在为一个 12V 汽车项目搭建原型和测试平台。根据 NXP 的建议，我们为保护电路选择了 MC33XS2410（电子熔断器）。 然而，由于我们身处组装车间，目前无法设计或制造定制PCB，因此对于手工布线而言，处理HTSSOP28封装（间距为0.65mm，带有散热焊盘）在物理上具有挑战性。 虽然我们知道功能齐全的 FRDM-XS2410EVB 评估板，但它对于我们目前在这个特定测试台上的需求来说太复杂、太大、太贵了。我们只需要一种最简便的方法来访问引脚。 在购买通用第三方适配器（例如 Aries Electronics 的 LCQT-TSSOP28 分线板）之前，我们想先咨询一下 NXP 社区： NXP 是否提供低成本、极简的转接板或原型适配器，专门用于将 MC33XS2410 的 HTSSOP28 封装转换为标准的 2.54mm DIP 引脚？ 如果没有，NXP 是否正式推荐任何经过验证可与该芯片良好配合使用的第三方适配器或插座品牌（考虑到裸露中心焊盘的接地和散热要求）？ 非常感谢您抽出时间提供帮助！ 评估板 StarCore DSP Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping 感谢托马斯的解释和注意事项，我想这就是我该如何处理我的卡片的方法。 Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping 你好，穆罕默德， 目前我们没有提供专用的低成本转接板或适配器板，可以将 MC33XS2410 HTSSOP28 封装直接转换为标准的 2.54 毫米 DIP 封装。您说得对，我们提供的 FRDM-XS2410EVB 是用于全面功能评估，而不是简单的代码包，软件包适配。 一个重要的考虑因素是 MC33XS2410 封装的裸露散热焊盘，为了保证散热和电气性能，应该将其焊接至 GND。我们还建议将裸露的焊盘连接到接地平面，并且在生产设计中，使用导热过孔来改善散热。 另请注意，通用分线板通常适用于功能原型设计和低功耗台式测试。然而，它们通常无法提供设计合理的 PCB 所能达到的热性能，这可能会限制可以测试的最大连续电流。 如果您的应用需要接近设备的限流运行，我建议您仔细评估其散热性能，或者使用官方评估板。 BRs，托马斯

license of S32 Design Studio for ARM v2.2 has expired Hi, my license of S32 Design Studio for ARM v2.2 has expired. Could you please extend it for me? Expiration Date: Jun 29, 2026 Product: S32 Design Studio for ARM v2.2 license：27ED-C7E9-C2B4-9D3E Re: license of S32 Design Studio for ARM v2.2 has expired Hi,  your S32DS license has been extended. 

本地访问窗口（LAW），内存重叠 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 关于 LAW 理解：关于 B4860，例如 B4860QDS； 本地访问窗口（LAW）： 在 B4860_QDS_Init.tcl 文件中设置了本地访问窗口寄存器（如下所示，定义了物理地址 0x000000，大小 2Gbytes，目标为 DDR）。 在 CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos 目录下的 dpaa_demo.c 文件中 将 LAW 设置 phy 地址 0x20000000 添加到 QMAN 我的疑问或困惑是，LAW 10 设置（目标地址为 0x0000000~0x7fffffff 的 DDR 内存）与 QMAN 软件端口 LAW 设置（目标地址为 0x20000000 的 QMAN 内存）重叠。 LAW 内存重叠，这样可以吗？能否详细解释一下为什么可以运行？B4860 参考手册中没有描述 LAW 内存重叠的情况。 ## LAW10 至 DDRC2 # LAWBARH mem [CCSR_ADDR 0x000CA0] = 0x00000000 # 律师协会 内存 [CCSR_ADDR 0x000CA4] = 0x00000000 # LAWAR 内存 [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap 本地管理系统如何处理数据集成是一件很有趣的事情，尤其是在管理本地访问窗口和内存重叠等复杂文件时。处理这些技术细节有时会感觉像处理newsportnewscourt.org一样复杂。日程。拥有一个可靠的、集中的资源来消除困惑，会产生巨大的影响。希望后续会有更多更新推出，使这些流程对所有相关人员来说都更加顺畅。 Re: Local Access Windows (LAWs), memory overlap 感谢分享 [RTD200P04 MCAL] S32M244 PWM PDB ADC MCAL 演示——这对从事嵌入式系统开发的开发人员来说真的很有帮助。对于那些负责处理合规性或网络安全日志记录以及硬件接口的人员来说，审查密苏里州的犯罪记录可以为管理现实世界的数据输入提供有用的见解。将技术应用与更广泛的背景知识联系起来总是有益的。 Re: Local Access Windows (LAWs), memory overlap <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 请参阅 B4860 QorIQ Qonverge 多核基带处理器参考手册，2.3.1 本地访问窗口的优先级。

MIMX9121CVVXCAAのRTC_XTALI信号処理について こんにちは、i.MX91 SOC MIMX9121CVVXCAA使用を検討しています。 質問内容： RTC用のクロックはSOC内部の発振回路のクロックを使用することで、外部発振子を未実装にして RTC_XTALIとRTC_XTALOピンは何も接続しないように考えています。RTC＿XTALIのピンは基板側でプルダウンしたほうがいいのでしょうか。回答をお待ちしております。 Re: MIMX9121CVVXCAAのRTC_XTALI信号処理について 推奨事項 RTC機能が必要な場合は、 UG10147の推奨事項に従って、外部32.768kHz水晶発振器（適切な負荷コンデンサ付き）を使用するか、または、周波数が50kHz未満で振幅がNVCC_BBSM_1P8を超えない外部クロックをRTC_XTALIに供給してください。 RTCが使われていない場合は、単にそのまま RTC_XTALI と接続されていない(NC) RTC_XTALO してください。プルダウン抵抗器は追加しないでください。さらに、フラックス残留物、湿気、または隣接する配線との結合による漏洩を防ぐため、これらの配線から電源および接地までの絶縁抵抗が100 MΩ以上であることを確認してください。 i.MX 91には、独立して動作する内部32.768kHz発振器は搭載されていません。したがって、RTC機能が不要であれば、 RTC_XTALI と RTC_XTALO は NCのままにし、プルダウン抵抗を追加すべきではありません。これは、データシートに、これらのピンから電源またはグランドへのリーク経路が100 MΩ以上である必要があると規定されているためです。 推奨事項 RTC機能が必要な場合は、 UG10147の推奨、32.768 kHzの水晶発振子（負荷容量を含む）を接続するか、 RTC_XTALIに周波数50 kHz未満、振幅がNVCC_BBSM_1P8を超えない外部クロックを入力してください。 RTC機能を使用しない場合は、RTC_XTALI と RTC_XTALO の両方を NC(未接続) のままとしてください。プルダウン抵抗は追加しないでください。また、 フラックス残渣、湿気、または隣接配線によるリーク電流を防ぐため、これらの配線と電源/GND間の絶縁抵抗が 100 MΩ以上 となるようにしてください。 i.MX 91 には、単独で動作する内蔵32.768 kHz発振器はありません。したがって、 RTC機能を使用しない場合は、RTC_XTALI および RTC_XTALO を NC(未接続) のままとし、プルダウン抵抗を追加しないでください。データシートでは、これらのピンから電源またはGNDへのリーク経路は 100 MΩ以上 であることが要求されています。