Automotive Vehicle Comfort Control Using FRDM-A-S32K344 Microcontrollers Overview This article demonstrates the implementation of a vehicle comfort control system using the FRDM-A-S32K344 development platform. The application showcases how embedded peripherals can be used to control multiple vehicle comfort functions, including cabin cooling and electric window operation. The demo operates a DC motor and a stepper motor based on user inputs while providing real-time control through PWM generation and GPIO outputs. The project highlights the interaction between user inputs, control logic, PWM motor control, and stepper motor sequencing commonly found in automotive body electronics and comfort modules. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Vehicle Comfort Control on FRDM-A-S32K344  Learning Objectives This project demonstrates: GPIO-based input handling PWM motor control Direction control techniques Stepper motor sequencing Real-time actuator control Automotive comfort system concepts Multi-actuator control using S32K3 peripherals The example provides a practical introduction to automotive body-control applications involving cooling and window-control systems. System Architecture The application follows a command-and-control architecture:   Plain Text     User Inputs ↓ GPIO Interface ↓ Vehicle Comfort Control Logic ↓ PWM + GPIO Outputs ↓ DC Motor + Stepper Motor Architecture Diagram (Insert Vehicle Comfort Control Architecture Diagram) Figure Caption Figure 1. Vehicle comfort control system architecture. User button inputs are processed by the S32K344 microcontroller. The application determines the desired comfort function and generates either PWM-controlled outputs for the cooling fan or GPIO sequencing signals for the stepper motor representing window movement.  Control Principle The demo operates two independent comfort functions: Cooling System Control A DC motor represents a vehicle cooling fan. The MCU generates PWM signals that regulate: Fan activation Fan speed Cooling-system behavior PWM control allows smooth speed adjustments while minimizing power losses. Window Control System A stepper motor represents an electric window mechanism. The MCU controls the motor through a full-step coil sequencing algorithm. This allows: Upward movement Downward movement Direction control Precise positioning The behavior emulates typical automotive power-window systems. User Input Processing The system uses push-button inputs connected to the FRDM-A-S32K344 board. The button states are continuously monitored through GPIO inputs. Based on the detected command, the application executes the corresponding comfort function. Possible actions include: Increasing fan activity Decreasing fan activity Moving the window upward Moving the window downward The control logic translates user commands into actuator actions in real time. DC Motor Control The DC Motor 2 Click board is used to drive a 5V fan motor. PWM output generated by the S32K344 controls: Motor activation Speed variation As the PWM duty cycle changes, the fan speed changes accordingly. This illustrates a common cooling-system implementation used throughout the automotive industry. Stepper Motor Control The H-Bridge Click board controls a NEMA17 stepper motor using a full-step drive sequence. The MCU energizes the motor coils in a predefined pattern:   Plain Text     A → B → C → D   This enables: Controlled rotation Direction changes Window position simulation The process demonstrates how automotive ECUs control electromechanical comfort systems. Control Behavior The control logic can be represented as a command-response system. Example behavior: User Action System Response Fan Command PWM duty cycle adjusted Window Up Stepper advances forward Window Down Stepper advances reverse No Command Actuators remain idle Control Behavior Diagram (Insert Comfort Control Behavior Diagram) Figure Caption Figure 2. Vehicle comfort control behavior. User commands are translated into specific actuator actions. PWM signals regulate fan speed, while GPIO-driven step sequences determine stepper motor direction and movement. Hardware Setup Required Hardware FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 FRDM K64 Click Shield FRDM K64 click shieldFRDM K64 click shield DC Motor 2 Click DC Motor 2 ClickDC Motor 2 Click H-Bridge Click H-Bridge ClickH-Bridge Click 5V Fan Motor 5V Fan Motor5V Fan Motor Stepper Motor NEMA17 Stepper Motor Nema17Stepper Motor Nema17 Full setup: Comfort Full SetupComfort Full Setup This configuration enables simultaneous control of both rotational-speed and positional actuators. Software Environment The example was developed using: S32 Design Studio S32K3 Real-Time Drivers (RTD) Application Code Hub framework The software demonstrates practical usage of GPIO and PWM drivers for actuator control. Implementation Guide Step 1: Import the Project Open S32 Design Studio Import project from Application Code Hub Search for Vehicle Comfort Control example Expected result: Project appears in workspace Step 2: Build the Application Compile the project Check for errors Expected result: Successful build Step 3: Connect Hardware Install: FRDM K64 Click Shield DC Motor 2 Click H-Bridge Click Fan motor NEMA17 stepper motor Verify all wiring before powering the system. Step 4: Flash and Run Program the MCU Start execution Expected result: Application runs continuously Step 5: Functional Validation After startup: Press the control buttons Observe fan operation Observe stepper motor movement Expected result: The system immediately responds to user commands. Comfort System Examples The demonstrated functions correspond to common automotive applications. Cooling Regulation The DC motor represents: Cabin ventilation systems HVAC airflow control Cooling fan operation Electric Window Control The stepper motor represents: Window up/down movement Position control Direction control These systems are examples of comfort-oriented body electronics within modern vehicles. Possible Extensions The application can be enhanced with: Feedback-Based Control Add sensors to provide closed-loop position or speed control. Automatic Comfort Modes Implement predefined comfort profiles. CAN Communication Enable communication with other vehicle ECUs. Diagnostic Functions Add fault detection and actuator monitoring. Position Memory Store and restore window or comfort positions. Conclusion This vehicle comfort control demonstration shows how the S32K344 platform can integrate user inputs, GPIO processing, PWM generation, and electromechanical actuator control into a complete embedded automotive application. By controlling both a DC motor and a stepper motor, the project illustrates the implementation of cooling-system regulation and electric-window operation, providing a practical example of automotive comfort-module design on the S32K3 platform. Comfort ResultComfort Result The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

IMX8MPセカンダリイメージブート IMG_CNTN_SET1_OFFSETセカンダリイメージブート（RM 6.1.6.2）は、i.MX8MP上のECSPI（"SPI") NORブートで動作しますか、それともFlexSPI NOR（およびSD/eMMC）のみで動作しますか？表6-28では、「SPI」と「FlexSPI NOR」が別々のブートデバイスとして記載されており、セカンダリオフセットの有効値は「FlexSPI NORブートの場合」にのみ記載されています。 Re: IMX8MP secondary image boot こんにちは、 あなたの理解は間違っています。IMG_CNTN_SET1_OFFSETセカンダリイメージブートはSPIデバイスでも動作しますが、オフセットが異なります。 FlexSPI の有効な値は、0、1、2、3、4、5、6、および 7 です。 SPI の場合、ヒューズ値が 10 より大きい場合、セカンダリ ブートは無効になります。n = ヒューズ値が より大きい場合 10. • n == 0: オフセット = 4MB • n == 2: オフセット = 1MB • その他 & n <= 10 : オフセット = 1MB*2^n

IMX8MP secondary image boot Does IMG_CNTN_SET1_OFFSET secondary image boot (RM 6.1.6.2) work for ECSPI ("SPI") NOR boot on i.MX8MP, or only for FlexSPI NOR (and SD/eMMC)? Table 6-28 lists "SPI" and "FlexSPI NOR" as separate boot devices, and the secondary-offset valid values are stated only "for FlexSPI NOR boot." Re: IMX8MP secondary image boot Hello, Your understanding is wrong, the IMG_CNTN_SET1_OFFSET secondary image boot also work for SPI devices, only with a different offset: For FlexSPI = the valid values are: 0, 1, 2, 3, 4, 5, 6, and 7 For SPI = Secondary boot is disabled if fuse value is bigger than 10, n = fuse value bigger than 10. • n == 0: Offset = 4MB • n == 2: Offset = 1MB • Others & n <= 10 : Offset = 1MB*2^n

The plugin configuration dialog failed The prompt appears after I finish configuring the CAN Communication: “The plugin configuration dialog failed. Try to specify the connect string manually.” Re: The plugin configuration dialog failed Hello, until this issue is solved, please see a workaround discussed here. Regards, Michal Re: The plugin configuration dialog failed Hello the version 3.2.7 has been released. This version fixes the CAN plug-in dependency issue discussed in this thread. Regards, Michal

How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hello to everyone on the NXP support team. I am currently working on a project using the S32K314, RTD 7.0.0, and FreeRTOS. I am trying to implement the measurement of the voltage of an external device connected to the MCU, the internal temperature (TEMPSENSE) of the MCU, the internal voltage (ANAMUX) of the MCU, and the bandgap voltage using the MCAL's ADC module. Looking at the measurement results, the voltage of the external device and the bandgap voltage seem to be measured correctly, but the values of the internal temperature and internal voltage of the MCU are different from what I expected. Expected value: MCU internal voltage (VDD_HV_A): 8192 (2.5V, 14-bit resolution) Actual measured value: Approximately 6800–7100 (2.07–2.13V, 14-bit resolution) The MCU power supply voltage is 5.0V. The ADC hardware unit is set to ADC0, and the ADC measurement target is configured as follows: Ch8: MCU internal temperature (TEMPSENSE) Ch9: MCU Internal Voltage (ANAMUX) Chapter 10: Band Gap MCU input voltage = 5.0V ADC initialization code: void AdcAdapter_Init ( void ) { Adc_Calibrate ( ADC0 , & calStatus ) ; Adc_SetupResultBuffer ( ADC0 , Group0Result ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 | DCM_GPR_DCMRWF1_SUPPLY_MON_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_A_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_B_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_1_5_VLT_DVDR_EN ( 1 ) ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~ DCM_GPR_DCMRWF1_SUPPLY_MON_SEL_MASK ) | DCM_GPR_DCMRWF1_SUPPLY_MON_SEL ( 0U ) ; // VDD_HV_A_DIV Adc_StartGroupConversion ( ADC0 ) ; // AdcConversionStart } ADC data acquisition (all periodic tasks) void AdcAdapter_RunCyclic ( void ) { Adc_StatusType ret = ADC_IDLE ; Std_ReturnType adcStatus ; uint16 temperature ; // 変換完了チェック ret = Adc_GetGroupStatus ( ADC0 ) ; if ( ( ret == ADC_COMPLETED ) || ( ret == ADC_STREAM_COMPLETED ) ) { // 結果を取得 Adc_ReadGroup ( ADC0 , Group0Result ) ; // 次の変換を開始 Adc_StartGroupConversion ( ADC0 ) ; } else { // エラーログ } /* Adc_TempSenseGetTemp Singed Q11.4 */ adcStatus = Adc_TempSenseGetTemp ( ADC0 , mcuTemperature ) ; if ( E_OK == adcStatus ) { temperature = Adc_TempSenseCalculateTemp ( ADC0 , mcuTemperature ) ; } else { // エラーログ } } I believe the ADC values for the ADC0 group can be updated using `Adc_ReadGroup`, but I think you need to use `Adc_TempSenseGetTemp` and `Adc_TempSenseCalculateTemp` to check the MCU's internal temperature. Please let me know if I've overlooked any settings. Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for your quick response. I have already reviewed the sample code you provided and believe I have incorporated it into my code. I interpreted the table you provided as a table of register settings for each clock supplied to the ADC block. However, I was unable to determine which of the ADC settings in MCAL they correspond to. Since I am unable to provide the source code, I am attaching an image of the ADC settings. Please let me know which settings I should change. If there are any other settings screens you need, please let me know. AdcHwUnit> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi@Teruhiko I didn't see the complete ADC configuration in the information you provided, so please double-check that the ADC clock matches the datasheet requirements. If possible, you can share your test project with me, and I'll check it for you. by the way, take a look at the demo in the link below: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-TempSenser-S32DS36-RTD600-500-400-p24/ta-p/2136187 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for your advice. Following your advice, I changed the settings as shown below to set the TEMPSENSE sampling time to 1.2 usec.　 160MHz = 0.00625usec 1.2usec/0.00625usec = 192 I created a task with a 1-second cycle in FreeRTOS and acquired the ADC values for the MCU voltage (VDD_HV_A) and MCU temperature (TEMPSENSE) every second (collecting 30 seconds’ worth of data). For the MCU voltage, I used the bandgap voltage and converted it to mV using the following compensation formula. (The bandgap voltage showed almost no fluctuation, with a value of around 3975 (approximately 1.2 V) obtained.) AdcCorrection = (1200(mV) * Adc_VCC_HV_A) / Adc_bandgap Mcu Voltage = AdcCorrection * 2  (2 is the voltage division ratio of VDD_HV_A) Additionally, the McuTemp data comes from `Adc_TempSenseGetTemp(ADC0, &mcuTemperature)`. Even taking into account the ADC conversion error of +/- 5.0%, I believe the variation is too large. Are there any suggested solutions?   Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi@Teruhiko From the configuration screenshots and code you provided, I don't see any obvious errors. However, it's important to note that the temperature sensor's sampling time must be greater than 1.2µs; otherwise, it will affect the sampling accuracy. Therefore, I suggest you double check the sampling time before testing. Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 The image for ADC_Config>AdcHwUnit was compressed, resulting in a loss of resolution, so I am re-uploading it. <#1> <#2> <#3> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for attaching the documentation. Since I am currently measuring channels 32–63, I understand that this corresponds to Sampling Duration 1. Thank you for your prompt response. The issue has been resolved.　 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi@Teruhiko You can directly read the raw data from the temperature channel to observe whether there are fluctuations. If the fluctuations are large, you can continue to try increasing the sampling time. Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, I interpreted the information in Table 317 as follows. When fmc = 160 MHz: ・ Set the prescaler for calibration to 4 ・ Set the prescaler for normal ADC conversion to 2 ・ Set “ADC High Speed” to Disable The data obtained by applying these settings is shown in the table below. Although averaging reduced the variation, I feel that the variation in the MCU’s internal temperature is still quite significant. The table below shows the MCU temperature data converted from ADC values to °C. (To convert the ADC values to °C, I divided the ADC values by 16.) A variation of 2.55 degrees over a 16-point average is extremely large. I understand that the MCU temperature fluctuates depending on the processing load, but is it normal for it to change this much instantaneously? When measuring the internal temperature of the MCU, is averaging the correct approach?　 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 Hi Senlent-san, Thank you for you reply. As shown in the figure below, the values stabilized after I increased the Sampling Duration 1/Duration 2 values. I thought the default setting was Sampling Duration 0, but how can I switch between Sampling Duration 0, 1, and 2? (Based on the prescale setting, since the ADC clock is 80 MHz, the duration equivalent to 1.2 μs is 96.)

How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 NXPサポートチームの皆様、こんにちは。  現在、S32K314、RTD 7.0.0、およびFreeRTOSを使用したプロジェクトに取り組んでいます。MCALのADCモジュールを使用して、MCUに接続された外部デバイスの電圧、MCUの内部温度（TEMPSENSE）、MCUの内部電圧（ANAMUX）、およびバンドギャップ電圧の測定を実装しようとしています。測定結果を見ると、外部デバイスの電圧とバンドギャップ電圧は正しく測定されているようですが、MCUの内部温度と内部電圧の値は予想と異なっています。 期待値： MCU内部電圧（VDD_HV_A）： 8192（2.5V、14ビット分解能） 実測値： 約6800～7100（2.07～2.13V、14ビット分解能） MCUの電源電圧は5.0Vです。ADCハードウェアユニットはADC0に設定され、ADC測定対象は以下のように構成されます。  Ch8：MCU内部温度（TEMPSENSE）  Ch9：MCU内部電圧（ANAMUX）  第10章：バンドギャップ  MCU入力電圧 = 5.0V ADC初期化コード： void AdcAdapter_Init ( void ) { Adc_Calibrate ( ADC0 , & calStatus ) ; Adc_SetupResultBuffer ( ADC0 , Group0Result ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 | DCM_GPR_DCMRWF1_SUPPLY_MON_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_A_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_HV_B_VLT_DVDR_EN ( 1 ) | DCM_GPR_DCMRWF1_VDD_1_5_VLT_DVDR_EN ( 1 ) ) ; IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~ DCM_GPR_DCMRWF1_SUPPLY_MON_SEL_MASK ) | DCM_GPR_DCMRWF1_SUPPLY_MON_SEL ( 0U ) ; // VDD_HV_A_DIV Adc_StartGroupConversion ( ADC0 ) ; // AdcConversionStart } ADCデータ取得（すべての周期的なタスク） void AdcAdapter_RunCyclic ( void ) { Adc_StatusType ret = ADC_IDLE ; Std_ReturnType adcStatus ; uint16 temperature ; // 変換完了チェック ret = Adc_GetGroupStatus ( ADC0 ) ; if ( ( ret == ADC_COMPLETED ) || ( ret == ADC_STREAM_COMPLETED ) ) { // 結果を取得 Adc_ReadGroup ( ADC0 , Group0Result ) ; // 次の変換を開始 Adc_StartGroupConversion ( ADC0 ) ; } else { // エラーログ } /* Adc_TempSenseGetTemp Singed Q11.4 */ adcStatus = Adc_TempSenseGetTemp ( ADC0 , mcuTemperature ) ; if ( E_OK == adcStatus ) { temperature = Adc_TempSenseCalculateTemp ( ADC0 , mcuTemperature ) ; } else { // エラーログ } }  ADC0グループのADC値は`Adc_ReadGroup`を使用して更新できると思いますが、MCUの内部温度については`Adc_TempSenseGetTemp`と`Adc_TempSenseCalculateTemp`を使用する必要があると思います。もし私が見落としている設定があれば教えてください。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 迅速なご対応ありがとうございます。 ご提供いただいたサンプルコードは既に確認済みで、私のコードに組み込んだと考えています。 ご提供いただいた表は、ADCブロックに供給される各クロックに対するレジスタ設定の表であると解釈しました。しかし、それらがMCALのどのADC設定に対応しているのかを特定することはできませんでした。 ソースコードを提供できないため、ADC設定の画像を添付します。どの設定を変更すればよいか教えてください。 他に何か必要な設定画面があれば、お知らせください。 AdcHwUnit> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 提供された情報にはADCの完全な構成が見当たらなかったので、ADCクロックがデータシートの要件に合っているか再確認してください。 可能であれば、テストプロジェクトを共有していただければ、私が確認します。 ちなみに、下記のリンクからデモをご覧ください。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K344-TempSenser-S32DS36-RTD600-500-400-p24/ta-p/2136187 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 アドバイスありがとうございます。 ご助言に従い、TEMPSENSEのサンプリング時間を1.2マイクロ秒に設定するように、以下のように設定を変更しました。 160MHz = 0.00625マイクロ秒 1.2マイクロ秒/0.00625マイクロ秒= 192 FreeRTOSで1秒サイクルのタスクを作成し、MCU電圧(VDD_HV_A)とMCU温度(TEMPSENSE)のADC値を毎秒取得しました(30秒分のデータ収集)。 MCU電圧についてはバンドギャップ電圧を使い、以下の補償式でmVに変換しました。 （バンドギャップ電圧はほとんど変動せず、約3975（約1.2V）の値が得られた。） Adc補正 = (1200(mV) * Adc_VCC_HV_A) / Adc_バンドギャップ Mcu電圧 = アドコレーション × 2(2は電圧分割比VDD_HV_A) さらに、 McuTempデータは `Adc_TempSenseGetTemp(ADC0, &mcuTemperature)` から取得されます。 ADC変換誤差が±5.0%であることを考慮しても、このばらつきは大きすぎると思います。何か解決策の提案はありますか？   Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 ご提供いただいた設定画面のスクリーンショットとコードを見る限り、明らかなエラーは見当たりません。ただし、温度センサのサンプリング時間は1.2μsを超えなければならないことに注意が必要です。そうでなければ、サンプリングの精度に影響します。したがって、テストを行う前にサンプリング時間を再度確認することをお勧めします。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 ADC_Config>AdcHwUnitの画像が圧縮されて解像度が低下したため、再アップロードします。 <#1> <#2> <#3> Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは@輝彦 温度チャネルから生データを直接読み取って、変動があるかどうかを観察できます。変動が大きい場合は、サンプリング時間を延ばし続けるCAN。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 ご返信ありがとうございます。 下図に示すように、サンプリング期間1/期間2の値を増加させた後、値は安定しました。デフォルト設定はサンプリング持続時間0だと思っていましたが、サンプリング持続時間0、1、2の切り替えはどうすればいいのでしょうか? （プリスケール設定に基づくと、ADCクロックは80MHzなので、1.2μsに相当する期間は96となる。） Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 ドキュメントを添付してくださりありがとうございます。現在チャネル32から63を測定しているので、これはサンプリング持続時間1に対応していると理解しています。 迅速なご対応ありがとうございます。問題は解決しました。 Re: How to Measure the Internal Temperature and Voltage of an MCU Using the ADC0 こんにちは、センレントさん。 私は表317の情報を以下のように解釈しました。 fmc = 160 MHz の場合: ・キャリブレーション用のプリスケーラを4に設定する ・通常のADC変換のプリスケーラを2に設定する ・「ADC高速」を無効に設定する これらの設定を適用して得られたデータは、以下の表に示されています。 平均化することでばらつきは減りましたが、MCU内部温度の変動は依然としてかなり大きいと感じます。 以下の表は、ADC値から°Cに変換したMCU温度データを示しています。 （ADC値を摂氏に変換するために、ADC値を16で割りました。） 16点平均で2.55度の変動は極めて大きい。MCUの温度はプロセッシング負荷によって変動することは理解していますが、これほど瞬時に大きく変わるのは普通のことですか? MCUの内部温度を測定する際に、平均を取るのが正しいアプローチでしょうか?

To complement solution how to printf float number in MCUXpresso IDE Hi: In previous topics there are some discussions how to print float number in MCUXpresso IDE and SDK. To try them and summarize the final solution: 1.PRINTF the float number to UART console set below macro in project configuration->C/C++ build ->setting PRINTF_FLOAT_ENABLE=1 such code will work. float test1 = 0.15; PRINTF("%f\r\n",test1); 2.Transform float number to string by sprintf() function. there is one error in SDK user manual, " Ensure Redlib: Use floating point version of printf is selected " during project creation does not work. The default C library Redlib doesn't support floating, so it couldn't work with redlib. The correct solution are: (1)Change link library to NewLib, it's full C library and support float  printf. But notice need include in related c file, or else sprintf(float) doesn't work as expected. (2)Change link library to NewLib Nano, it's compact C library , and need click "enable print float" to enable float function, which actually add " -u _printf_float" link symbol. But notice need include in related c file, or else sprintf(float) doesn't work as expected. So the solution surely add flash & RAM consumption in project, but for i.MXRT series it's not problem. Attach is one example for RT1020 EVK. Re: To complement solution how to printf float number in MCUXpresso IDE Thank you! That solved my problem.  Re: To complement solution how to printf float number in MCUXpresso IDE Hi @daweiyou  Thank you so much for your contribution. The information was pretty helpful and it might be helpful for many people. Thank you again. Best Regards. Pablo Avalos.

S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hi We are working on Secure Debug authentication for the S32N55 platform and have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. We are now trying to extend this to the CRS domain (HSE_DEBUG_DOMAIN_APP = 0x1B) and have the following questions: --- [Q1] Is ADKP usable for CRS domain Secure Debug authentication? After provisioning ADKP via HSE_OTP_FOEM_ADKP_ATTR_ID, is it possible to use the same ADKP for CRS domain (APP) Secure Debug authentication via HSE_DEBUG_CMD_APP_CHALLENGE? --- [Q2] Does SetOwnerDebugKeyMap() need to be called separately per MU (FSS MU vs CRS MU)? Per the RM description of hseOwnerDebugKeyMapConfig_t: "This service is called for each installed device owner individually from an owning MU. HSE FW assumes the owner identity based on the MU this service request is sent to." Our current implementation calls SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING) only through FSS MU (MU0), mapping aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP. - Is a separate SetOwnerDebugKeyMap() call required through the CRS MU for CRS domain authentication? - If so, which MU number should be used for the CRS domain on S32N55? --- [Q3] Does SetOwnerDebugKeyMap() need to be called on every boot? The RM states: "Only the numOfAuthorizationRefEntries and numOfAuthenticationRefEntries are logged, rest of the entries are ignored." This implies the key mapping is volatile and not stored in NVM. Does this mean SetOwnerDebugKeyMap() must be called on every boot (after SU rights are granted) for both FSS and CRS domains? --- [Q4] Correct keyRef value for APP_CHALLENGE In hseDebugAuthorizeStartCmd_t, the keyRef field references the index mapped via hseOwnerDebugKeyMapConfig_t. Since we map aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP, we send keyRef = 0x00 for CRS domain authentication. Is this correct? --- [Q5] Response size and packet structure for APP_CHALLENGE Per hseDebugAuthorizeProofProvCmd_t byte map, the packet structure is always 32 bytes (2 packets x 8 words). HSE_CR_APP_RESPONSE_SIZE = 16U vs HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U. For APP_CHALLENGE, should the host send: - 16 bytes of AES-encrypted response + 16 bytes of zero padding = 32 bytes total? - Or only 16 bytes? Currently, after sending FLAG_START + DebugSignalMap(4 bytes) + Response(16 bytes) + FLAG_END, HSE2 does not respond and T32 hangs waiting indefinitely. When we send 32 bytes (16-byte response + 16-byte zero padding), we observe the same hang. --- For reference: - Sherpa_Cdd_AllocateChannel() always allocates MU0 (FSS) - SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302), called with SU rights - crs_auth.cmm: DEBUG_TARGET=0x1B, OID=0xFF*16, keyRef=0x00 - AUTH_MODE_REQ passes successfully (HSE_DEBUG_WAITING_RESPONSE_TO_CHG received) - Challenge received: 32 bytes - After sending Response, no ACK (0x4A4A4A4A) received from HSE2 Please see the attached CMM script and log for reference. Thank you in advance. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your suggestion. As requested, I have created a new post to track the CRS (APP domain) Secure Debug authentication issue: [S32N55 HSE2 — CRS (APP Domain) Secure Debug Authentication via hseDebugCardCmd_t] (Please search the title above in NXP Community) This issue is currently blocking our customer delivery schedule. Could you please review the new post at your earliest convenience? The CMM script (crs_auth.cmm) and log file are attached in the new post. Thank you very much for your urgent support. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, Thank you for your response.  We have additional questions regarding hseDebugCardCmd_t implementation for CRS (APP) domain Secure Debug authentication on S32N55. --- [Q1] Is the Owner ID (ownerId) in hseDebugCardInfo_t the same value as provisioned via hseOwnerDebugKeyMapConfig_t? Our device is configured in single-owner scenario where Fss_Firmware_au8Oid[] = {0xFF * 16}. Should the ownerId field in hseDebugCardCmd_t also be set to 0xFF * 16? Or does it need to match a specific value provisioned during Device Owner installation? --- [Q2] Does hseDebugCardCmd_t need to be sent after APP_CHALLENGE, or instead of hseDebugAuthorizeProofProvCmd_t? Per RM: "For APP based options, debug signals are enabled and authorized only through the debug cards authentication (see hseDebugCardCmd_t)(field is ignored)." Our current flow: 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) 2. rx_authmode → HSE_DEBUG_WAITING_RESPONSE_TO_CHG received 3. APP_CHALLENGE → rx_challenge (32 bytes received) 4. hseDebugCardCmd_t sent directly (skipping hseDebugAuthorizeProofProvCmd_t) 5. HSE2 stops responding (T32 hangs at FLAG_END of CARD_REQUEST) Should hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC) be sent BEFORE hseDebugCardCmd_t? Or should hseDebugCardCmd_t be sent directly after rx_challenge without ProofProv? --- [Q3] What is the correct Authentication Tag (authTag) computation for hseDebugCardTag_t when using MAC scheme? We are using: authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11) authTag = AES256-CMAC(key=ADKP, data=Challenge[32 bytes]) authLen = 16 Is this the correct computation? Or should the CMAC input include additional fields (OID, domain map, etc.)? --- [Q4] What is the correct packet structure for hseDebugCardCmd_t? Based on the RM byte map, our current implementation: Packet 1 (32 bytes): KRI(4B) + CMD(4B=0x5DCDEB77) + OID(16B=0xFF*16) + AuthScheme(8B=CMAC) Packet 2 (32 bytes): enabledDebugDomainMap(bit27=0x08000000) + padding(28B) Packet 3: debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B) Is this structure correct? HSE2 stops responding after receiving the OID field (0xFF bytes). --- Could you please let me know your email?  I will send you cmm file for crs auth. BRs. Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your post. Pleased to hear that the Secure Debug authentication for the S32N55 platform have successfully implemented FSS domain debug authorization using ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) via SDC-600. I will continue to help check with the details for your new issues, sorry that I did not see the attached CMM script and log for reference, would you mind uploading them again to share with us? BR Chenyin Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP Hello, @EddiePark  Thanks for your reply. There are already 6 questions existed in this post, and may take a relative long time to investigate, in order for improving the efficiency,  for additional questions, I suggest creating a new post to track. And as you mentioned, there would be scripts/logs attached for checking, but I do not see in your post, may I know if they would be uploaded again? BR Chenyin

RT1064 I2C 通信异常，频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常，但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看，这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS：将该设备的 I2C 驱动程序移植到另一台 1064 设备上，测试模块 A，在 400k 功耗下未发现问题。 原因可能是什么？ 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2：模块 A 在 100kHz 下的逻辑分析仪波形 图3：模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察，该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足，而不是模块 A 本身的异常。 即使上升时间在规格范围内，在 RT1064 上，我们仍然建议检查 LPI2C 主侧 400 kHz 配置，特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1，因为 RT1064 上的主同步延迟不仅受上升时间的影响，还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置，并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符： I2C模块时钟源 目标波特率：400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息：昨天在定位方面取得了一些进展： 我们的硬件扩容计划如下： 主板：RT1064--- ADUM1251 3.3V 至 5 V 子板：ADUM1251-模块A 5V转3.3V 经验证，在硬件链路的两层中添加 ADUM1251 后，模块 A 的通信出现异常。但移除 ADUM1251 后，通信在 400k 处恢复正常。造成这种情况的原因可能是什么？ PS：我们的硬件工程师认为 ADUM1251 只会增加通信延迟，不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好，@mayliu1 我们的产品即将发布，我们已经调查这个问题好几天了。如果您能尽快回复，我们将不胜感激！ Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形，上升时间符合要求，在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备，并测试了模块 A，没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑： 1.如果时钟在拉伸后恢复异常，还有哪些其他原因可能导致这种情况？ 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置？我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求，我们是否就不需要考虑这些寄存器设置了？ Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题，而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上，LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出，上升时间越大，同步延迟就越高。（参见第 47.3.1.4 章）时序参数） 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置，使其延迟保持在最小 SCL 低/高周期以下，RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此，如果模块 A 使总线边沿稍微变慢或改变有效负载，则总线可能在 400 kHz 时发生故障，但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率，但应根据 I2C 规范仔细验证自动生成的定时参数，特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险，建议使用经过验证的时钟源，例如 48 MHz，如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数？ PS：显然是由于自动接口分配造成的

Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi，pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey

Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi, We are currently testing an application jump from App1 to App2 on the FRDM-S32K344. Our application layout is: App1 Start Address: 0x00400000 App2 Start Address: 0x00500000 For debugging, we are using separate debug configurations with flash memory protection enabled. When debugging App1, the memory protection range is configured as: 0x00500000 to 0x005FFFFF (to protect App2) When debugging App2, the memory protection range is configured as: 0x00400000 to 0x004FFFFF (to protect App1) However, during programming through the debug configuration, we observe that the protected flash region is still being erased, even though the memory protection range has been configured. Could anyone clarify the following? Is the Flash Programmer expected to honor the configured memory protection ranges during erase/program operations? Is there any additional configuration required to prevent the protected flash region from being erased? Has anyone successfully used memory protection to preserve another application while programming only one application on the FRDM-S32K344? Logs and LD files are attached for your ref. we are using on board PE debugger Any guidance or recommendations would be greatly appreciated. Thank you. Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi @Avinpat123  I did quick test in the same version of S32 Design Studio to be sure it is working. I used the same setup – one application forced to 0x40_0000 while 0x50_0000 area is configured to be preserved and second application forced to 0x50_0000 while 0x40_0000 area is configured to be preserved: Here are the logs which shows that this configuration is taken into account: And I can see in the memory that the content is really preserved, so it works as expected. I  saw in your screenshots that you configured the address range but the “Preserve this range” check box is not enabled. Isn’t that the problem? Regards, Lukas

S32K3 ADC 外部チャネルの利用 こんにちは。NXPチーム S32K3 ADCの外部チャネルの使い方 . Re: S32K3 ADC Use of external channels こんにちは、 @VaneBさん これに関して、追加の質問があります。 もし私のデザインにマルチマックスがなくても、例えばセンサ1にADC1_X[0]、センサ2にADC1_X[1]、そしてADC1_Xセンサ3にだけ使いたい場合は、MAピンをGPIO出力ピンなど他の用途で再利用してLEDを駆動することは可能でしょうか? 私のデザインはs32k344をベースにしています Re: S32K3 ADC Use of external channels NPXチームの皆様、こんにちは。 このトピックに関連して、以下の図のようなSCHを実装することが可能かどうか確認していただけますか? サポートありがとうございます。 Re: S32K3 ADC Use of external channels @VaneB ご協力いただき、誠にありがとうございました。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin 各ADCは外部アナログ多重化器の8チャネル中1チャネルを選択するために使う3つの外部デコード信号(MA)を提供し、最大4つのマルチプレクサを設置して32の外部チャネルを接続できます。つまり、これら4つのマルチプレクサは同じMA信号を共有します。 ADCは変換対象の現在のチャネルに基づき、これらの外部アナログ多重化器を制御するよう自動設定します。マスクレジスタのビットに応じて、対応する「X」ピンがサンプリングされ、その結果が「MA」と「X」の組み合わせに対応する場所に格納されます。 当社の開発ボードには外部アナログ多重化装置が設計されていないため、そのような例は実装されていません。 Re: S32K3 ADC Use of external channels こんにちは。ヴェインB あなたのプロンプトによると、RTDで外部チャネルADCを使った例が見つかりません。もし対応するルーティンがあれば、ぜひ送っていただけると嬉しいです。どうもありがとうございます。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin RTDで役立つかもしれないADCの実装例が見つかります。 BR VaneB

MBDT中的CAN总线处理 我正在使用 NXP 的 MBDT for S32K344 来配置 FlexCAN0。我想了解 CAN 消息处理的哪些部分由 NXP 模块/工具箱管理，哪些部分需要由应用程序处理。 仲裁和缓冲区处理是否由驱动程序/工具箱管理？例如：如果我先发送 0x18FEF111，那么 0x18FEEF00 都不会出现在总线上。但如果先发送 0x18FEEF00，则两者都会被发送。当两者同时触发信号时，只会显示其中一个。 那么，在同时发送多个帧时，是否需要为每个消息 ID 分配专用的发送硬件对象？ MBDT 或 SDK 是否处理消息优先级，并在未收到 ACK 时自动重试？ 如果高优先级 ID 失败（例如，没有收到 ACK），是否会阻塞其他消息？我们如何检测并从中恢复？ 为了避免阻塞或消息丢失，模型中是否需要手动管理缓冲区分配或传输时序？ 在 MBDT 中配置多个 Tx 消息 ID 的最佳方法是什么？使用动态缓冲区。 请明确哪些是内部处理的，哪些是我们需要在应用程序中处理的。 示例模型 Re: CAN Bus Handling in MBDT 你好@SorinIBancila ， 我遇到了需要发送的帧数超过可用 HTH 硬件对象数量的情况。由于 S32CT 无法利用 CanIf 发送缓冲实现，您能否推荐一种基于 Simulink 的缓冲解决方案来解决此问题？ 谢谢，此致敬礼！ 桑德什 Re: CAN Bus Handling in MBDT 你好， 32 个 Can Hw 对象数量并非限制。根据你所使用的MCU型号，你还可以进一步提高这个限制。您可以修改 Can Hw Object Count 的数量，但如果您输入的数字过大，S32CT 将报错。 顺祝商祺！ 索林·班奇拉 Re: CAN Bus Handling in MBDT 明白了！如果我需要发送超过 32 条消息，是否应该创建额外的发送硬件对象？另外，在 S32K3 中使用 S32CT，单个 CAN 收发器或控制器下最多可以配置多少个硬件对象？ 想了解在限制条件下，如何以最佳方式构建大型消息集的 HOH。 Re: CAN Bus Handling in MBDT 你好， 你认为一次需要发送多少条信息？ 我已在 S32K358 HVBMS 参考设计上测试了以下场景： 使用单个 TX 硬件对象，并将Can 硬件对象计数设置为 32（以允许缓冲区中最多 32 条消息）。 在 Simulink 中，我向消息缓冲区填充了 32 条消息，随着缓冲区填充的进行，消息优先级也随之增加，以验证仲裁过程。 结果： 正如预期的那样，由于消息缓冲区尚未完全填充，因此发送的第一批消息优先级较低。大约在第 6 条消息时，缓冲区已满，我们可以看到优先级较高的消息会先发送。 由于你想使用单个收发器，因此实际上不可能同时发送所有消息。 顺祝商祺！ 索林·班奇拉 Re: CAN Bus Handling in MBDT 索林，你好 感谢您的意见！ 我想说明在使用动态缓冲区时，在 MBDT 中配置多个 Tx 消息 ID 的最佳方法。就我而言，该控制器用于电动汽车应用，采用基于 J1939 的 CAN 设置，涉及数百个循环消息。 在 S32CT 中为每条消息创建单独的硬件对象似乎既不可扩展也不实用。我希望使用单个 Tx 硬件对象来动态处理多个消息，并通过一个 CAN 接口同时传输它们。 请问针对这种使用场景，推荐的配置或最佳实践是什么？另外，请推荐一些我需要参考的文档，以便了解 MBDT 中配置设置的工作原理和相关函数。 Re: CAN Bus Handling in MBDT 你好， 首先，我想指出的是，S32K3xx 的 MBDT 是基于 S32K3 RTD 的版本。外围设备的配置是在 S32 配置工具中完成的，以便您可以灵活地进行所需的设置。因此，要检查 NXP 的 MBDT S32K3xx 是否支持某个功能，您可以检查外设（在 S32K3 RTD 中）使用的源代码及其在 S32 配置工具中的可用设置。 在工具箱中，您可以在此处找到 FlexCAN 外设的实现： {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 笔记！根据您使用的 MBDT S32K3 版本不同，S32K3 RTD 的名称可能会有所不同。 你问题的答案是基于我的经验，可能并不完全准确。 1、2 和 5：该工具箱不处理任何仲裁，但我不太确定 SDK 中有哪些选项可用于此目的。在你的示例中，你创建了另一个CanHardwareObject并使用它来发送第二条消息，但这种方法可能难以管理。第二个解决方案可能是增加Can Hw 对象计数，以允许缓冲区中存在更多消息。 3：S32K3 的 MBDT 不处理任何消息优先级。据我所知，FlexCAN 控制器负责重试发送消息，直到收到 ACK 为止，同时将消息阻塞在缓冲区中。 4. 检测消息是否已发送的一种方法是使用硬件中断回调中的CanIf_TxConfirmation中断来标记消息已发送。如果指定的 PDU 没有触发信号中断，则表示该消息未发送。此外，还有一个中断（ CAN_ControllerBusOff ）可用，当满足 CAN 总线关闭的条件时，该中断会产生触发信号。在 S32 配置工具中，有一个选项可以从总线关闭状态自动恢复。 如有任何疑问，请随时回复。 此致， 索林·班奇拉

RT1064 400kHzでのI2C通信異常 RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します 1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません 2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します 追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません その理由は何でしょうか? 1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形 2. 図2：モジュールAの100kHzにおけるロジックアナライザの波形 3. 図3：モジュールBの400kHzにおける波形 i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 追加のご説明ありがとうございます。これは非常に重要な指摘です。   あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。 ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。 プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。 特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。 I2Cモジュールクロックソース 目標ボーレート：400Kbps PRESCALE FILTSCL / FILTSDA セソルド クロックロ CLKHI データビデオ お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 追加情報として、昨日ポジショニングにいくつかの進展がありました: ハードウェア拡張は以下の通りです: マザーボード:RT1064--- ADUM1251 3.3V～5V サブボード：ADUM1251 - モジュールA 5V～3.3V 検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか? 追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています Re: RT1064 I2C communication abnormality at 400kHz こんにちは、@mayliu1 当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです! Re: RT1064 I2C communication abnormality at 400kHz ハイ 補足情報 1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました 2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました 以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー 疑い： 1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか 2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした ----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか? Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。 RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。 リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。（第47.3.1.4章を参照）タイミングパラメータ） マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例 したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 10 MHzのLPI2C機能クロックは、RT1064リファレンスマニュアルの400 kbpsのタイミング設定例には記載されていません。 このクロックを使用すれば400kbpsのボーレートを生成することは可能ですが、自動生成されるタイミングパラメータは、特にtLOW、tHIGH、セットアップ/ホールドタイミング、およびデータ有効タイミングに関して、I2C仕様と照らし合わせて慎重に検証する必要があります。 デザインリスクを減らすために、リファレンス・マニュアルに示されている48 MHzなどの検証済みクロックソースを使用することが推奨されています。 Re: RT1064 I2C communication abnormality at 400kHz 以下は印刷設定です。どのパラメータを調整する必要があるでしょうか？ 追伸:どうやら自動インターフェース割り当てによるようです

RT1064 I2C communication abnormality at 400kHz The I2C2 interface of the RT1064 device connects to Module A. Communication anomalies occur at 400kHz, but it functions properly at 100kHz 1. Connecting module B of a different model within the same series at 400kHz is no problem 2. In terms of waveform, it is equivalent to an anomaly occurring when the host clock is stretched and then restored after connecting to Module A PS: Implement the I2C driver port of the device to another 1064 device, test module A, no issues at 400k What might be the reason？ 1. Figure 1 Module A Abnormal Waveform of Logic Analyzer at 400kHz 2. Figure 2: Waveform of Logic Analyzer for Module A at 100kHz 3. Figure 3: Waveform of Module B at 400kHz i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thanks for the additional clarification — this is a very important observation.   From your observations, the issue appears more likely to be related to insufficient 400 kHz I2C timing margin caused by the two-stage ADUM1251 isolation link, rather than an abnormality of Module A itself. Even if the rise time is within spec, on RT1064, we still recommend checking the LPI2C master-side 400 kHz configuration, especially MCFGR2[FILTSCL/FILTSDA] and MCCR0/MCCR1 , because the master synchronization latency on RT1064 is affected not only by rise time, but also by the digital filter and timing parameter settings. We suggest reading out the actual configuration used in your project and comparing it with Table 47-5, “LPI2C Example Timing Configurations,” in Chapter 47 of the RT1064 Reference Manual . In particular, please check whether the following settings match to the example values for your selected clock condition: I2C module clock source Target baud rate: 400Kbps PRESCALE FILTSCL / FILTSDA SETHOLD CLKLO CLKHI DATAVD Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Additional information, there was some progress in positioning yesterday: Our hardware expansion is: Motherboard: RT1064--- ADUM1251    3.3 V to 5 V Subboard: ADUM1251- Module A          5v to 3.3v After verification, it was found that after adding ADUM1251 to the two layers of the hardware link, module A had abnormal communication. However, after removing it, communication returned to normal at 400k. What could be the reason for this？ PS: Our hardware engineers believe that ADUM1251 only increases communication latency and has no other impact Re: RT1064 I2C communication abnormality at 400kHz Hi,@mayliu1 Our product is about to be released, and we have been investigating this issue for several days. If we could receive your response as soon as possible, we would greatly appreciate it！ Re: RT1064 I2C communication abnormality at 400kHz Hi  Supplementary information 1. Our two hardware engineers checked the waveform of the problem through an oscilloscope, and the rise time met the requirements, within 100+ns 2. I ported I2C initialization and read-write function drivers to another type of RT1064 device,  and tested module A without any issues The following figure shows the waveform of another device module A testing logic analyzer doubt: 1. If the clock recovers abnormally after stretching, what other reasons could be causing it 2. Is there a dedicated function to set settings such as MCFGR2 mentioned in the last reply? I didn't see any interface to be set in the I2C initialization process ----If the rise time is met, do we not need to consider these register settings？ Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 ， Thank you so much for your interest in our products and for using our community. I think that this is most likely not a Module A issue, but a 400 kHz timing-margin issue on that specific RT1064 LPI2C2 bus. On RT1064, LPI2C timing is affected by bus rise time, bus loading, pull-up resistors, and glitch-filter latency.  RT1064RM  reference manual describe  that larger rise time increases synchronization latency.  (refer to chapter 47.3.1.4 Timing Parameters) The master glitch filters MCFGR2[FILTSCL/FILTSDA] must be set so their latency stays below the minimum SCL low/high period, and RT1064 provides example 400 kbps timing settings in MCCR0/MCCR1 .  Please check the Table 47-5. LPI2C Example Timing Configurations So if Module A makes the bus edges slightly slower or changes the effective loading, the bus may fail at 400 kHz but still work at 100 kHz .  Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Below is the configuration for printing. Which parameter may need to be adjusted? PS:apparently due to automatic interface allocation Re: RT1064 I2C communication abnormality at 400kHz A 10 MHz LPI2C functional clock is not listed in the RT1064 Reference Manual example timing configurations for 400 kbps. Although it is possible to generate a 400 kbps baud rate with this clock, the automatically generated timing parameters should be carefully verified against the I2C specification, particularly with respect to tLOW, tHIGH, setup/hold timing, and data valid timing. To reduce design risk, it is recommended to use a validated clock source, such as 48 MHz, as shown in the Reference Manual.

MC33774 デイジーチェーン デュアルループ接続 こんにちは。 現在、MC33665AとMC33774を使用してダブルチェーンループバック構造を形成するAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1はそれぞれMADD0とMADD1として構成されており、すべてのコマンドは現在MADD0経由で送信されています。PORT0とDC1の間だけをデイジーチェーン接続すると、通信は正常です。しかし、PORT1とDC2の間にもデイジーチェーン接続すると、33774が応答フレームで応答できないことがわかりました。これはなぜでしょうか？33665のPORT構成が正しいこと、および33774のSYS_TPL_CFG.RESPCFGが00 SAMEモードに設定されていることは確認済みです。 現在、私はMC33665AとMC33774を組み合わせたデュアルリングループ構成のAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1をそれぞれMADD0とMADD1として設定し、現在すべてのコマンドはMADD0経由で送信されています。 PORT0とDC1の間だけをデイジーチェーン接続した場合、通信は正常に動作します。しかし、PORT1とDC2の間にデイジーチェーン接続も行った後、MC33774にリクエストを送信しても応答しなくなりました。 なぜこのようなことが起こるのでしょうか？ MC33665 PORT の設定を読み返して確認したところ、正しいことが分かりました。また、MC33774 で SYS_TPL_CFG.RESPCFG = 00 (SAME モード) を設定しました。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは。 1. MADD=1の位置からDADDの割り当てを反転させる必要があるかどうかを知りたいです。 2. 現在のSYS_PORT0_CFG構成は、TIMEOUT=0、CADD=1、MADD=0、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1です。 SYS_PORT1_CFG は、TIMEOUT=0、CADD=1、MADD=1、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1 で構成されています。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは、 AN13910 TPLループバック推奨によると、2つのMC33665A TPLポートがループバックリングとしてコネクテッドである場合、あなたが見ている挙動を引き起こすいくつかの設定要件があります。 ループバック構成の場合： デバイスアドレス（DADD）は、リングの一方の側からは昇順で、ループバック側からは逆順で割り当てることをお勧めします（あなたの画像にはそれが確認できません）。 2つのポートがループバックとしてコネクテッドされている場合、重複データがMC33665バッファに入るのを防ぐために、どちらか一方のポートはSYS_PORTx_CFG[RX] = 0であるべきです。 さらに、いずれかのポートのSYS_PORTx_CFG[ALLCHAINS]が0である必要があります。両方のループバックポートがALLCHAINSコマンドを受け入れている場合、文書にはこれが信号の競合や通信エラーを引き起こす可能性があると記載されています。 SYS_PORT0_CFGとSYS_PORT1_CFG(特にEN、RX、ALLCHAINS、MADD、CADD)の価値観を共有していただけますか?それは、ループバックポートがAN13910の推奨事項に従って構成されているかどうかを判断するのに役立ちます。

S32N55 HSE2 — 使用 ADKP 的 CRS(APP) 功能域安全调试身份验证 HI 我们正在为 S32N55 平台开发安全调试身份验证，并且已经通过 SDC-600 使用 ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) 成功实现了 FSS 功能域调试授权。 我们现在正尝试将其扩展到 CRS 功能域（HSE_DEBUG_DOMAIN_APP = 0x1B），并有以下问题： --- [Q1] ADKP 是否可用于 CRS 功能域安全调试身份验证？ 通过 HSE_OTP_FOEM_ADKP_ATTR_ID 配置 ADKP 后，是否可以使用同一个 ADKP 通过 HSE_DEBUG_CMD_APP_CHALLENGE 进行 CRS 功能域（APP）安全调试身份验证？ --- [Q2] SetOwnerDebugKeyMap() 是否需要针对每个 MU（FSS MU 与 CRS MU）单独调用？ 根据 RM 对 hseOwnerDebugKeyMapConfig_t 的描述： “这项服务由拥有该设备的 MU 为每个已安装设备的所有者单独调用。 HSE FW 会根据发送此服务请求的 MU 来假定所有者身份。 我们目前的实现仅通过 FSS MU (MU0) 调用 SetOwnerDebugKeyMap() (HSE_SRV_ID_DEBUG_KEY_MAPPING)，映射 aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP。 - CRS 功能域身份验证是否需要通过 CRS MU 单独调用 SetOwnerDebugKeyMap()？ - 如果是这样，S32N55 上的 CRS 功能域应该使用哪个 MU 编号？ --- [Q3] 每次启动时都需要调用 SetOwnerDebugKeyMap() 吗？ RM表示： “仅记录 numOfAuthorizationRefEntries 和 numOfAuthenticationRefEntries， 其余条目将被忽略。 这意味着密钥映射是易失性的，不会存储在非易失性存储器 (NVM) 中。这是否意味着对于 FSS 和 CRS 域，每次启动时（在授予 SU 权限之后）都必须调用 SetOwnerDebugKeyMap()？ --- [Q4] 更正 APP_CHALLENGE 的 keyRef 值 在 hseDebugAuthorizeStartCmd_t 中，keyRef 字段引用通过 hseOwnerDebugKeyMapConfig_t 映射的索引。由于我们将 aOwnerAuthRef[0] 映射为 HSE_OTP_KEY_FOEM_ADKP，因此我们发送 keyRef = 0x00 来进行 CRS 功能域身份验证。这样对吗？ --- [Q5] APP_CHALLENGE 的响应大小和数据包结构 根据 hseDebugAuthorizeProofProvCmd_t 字节映射，数据包结构始终为 32 字节（2 个数据包 x 8 个字）。HSE_CR_APP_RESPONSE_SIZE = 16U 与 HSE_CR_FSS_OR_HSE_RESPONSE_SIZE = 32U。 对于 APP_CHALLENGE，主机是否应该发送： - 16 字节的 AES 加密响应 + 16 字节的零填充 = 总共 32 字节？ 或者只有 16 字节？ 目前，在发送 FLAG_START + DebugSignalMap(4 字节) + Response(16 字节) + FLAG_END 后，HSE2 没有响应，T32 无限期地挂起等待。当我们发送 32 字节（16 字节响应 + 16 字节零填充）时，会观察到同样的卡顿现象。 --- 供参考： - Sherpa_Cdd_AllocateChannel() 总是分配 MU0 (FSS) - SetOwnerDebugKeyMap(): aOwnerAuthRef[0] = HSE_OTP_KEY_FOEM_ADKP (0x00000302)，使用 SU 权限调用 - crs_auth.cmm：DEBUG_TARGET=0x1B，OID=0xFF*16，keyRef=0x00 - AUTH_MODE_REQ 请求成功通过（已收到 HSE_DEBUG_WAITING_RESPONSE_TO_CHG 信号） - 已接收挑战码：32 字节 发送响应后，未收到来自 HSE2 的 ACK (0x4A4A4A4A)。 请参阅附件中的CMM脚本和日志以供参考。 提前谢谢您。 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， 谢谢你的建议。应要求，我创建了一个新帖子来跟踪 CRS（APP 功能域）安全调试身份验证问题： [S32N55 HSE2 — CRS（应用程序功能域）通过 hseDebugCardCmd_t 进行安全调试身份验证] （请在NXP社区搜索以上标题） 这个问题目前影响了我们的客户发货计划。请您在方便的时候尽快查看一下这篇新文章。 CMM脚本（crs_auth.cmm）新帖子中附上了日志文件。 非常感谢您的及时支持。 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， 感谢您的回复。 我们对 S32N55 上 CRS (APP) 功能域安全调试身份验证的 hseDebugCardCmd_t 实现还有其他疑问。 --- [Q1] hseDebugCardInfo_t 中的 Owner ID (ownerId) 是否与通过 hseOwnerDebugKeyMapConfig_t 配置的值相同？ 我们的设备配置为单所有者场景，其中 Fss_Firmware_au8Oid[] = {0xFF * 16}。 hseDebugCardCmd_t 中的 ownerId 字段是否也应设置为 0xFF * 16？ 或者它是否需要与设备所有者安装期间配置的特定值相匹配？ --- [Q2] hseDebugCardCmd_t 是否需要在 APP_CHALLENGE 之后发送，还是应该代替 hseDebugAuthorizeProofProvCmd_t 发送？ 根据 RM 的说法：“对于基于 APP 的选项，调试信号仅通过调试卡身份验证启用和授权（参见 hseDebugCardCmd_t）（该字段被忽略）。” 我们目前的流程： 1. AUTH_MODE_REQ (DEBUG_TARGET=0x1B) 2. rx_authmode → 已收到 HSE_DEBUG_WAITING_RESPONSE_TO_CHG 3. APP_CHALLENGE → rx_challenge（已接收 32 字节） 4. 直接发送 hseDebugCardCmd_t（跳过 hseDebugAuthorizeProofProvCmd_t） 5. HSE2 停止响应（T32 卡在 CARD_REQUEST 的 FLAG_END 处挂起） 是否应该在发送 hseDebugCardCmd_t 之前发送 hseDebugAuthorizeProofProvCmd_t (appChallengeAuth = AES256-CMAC)？ 或者，是否应该在不发送 ProofProv 的情况下，直接在 rx_challenge 之后发送 hseDebugCardCmd_t？ --- [Q3] 使用 MAC 方案时，hseDebugCardTag_t 的正确认证标签 (authTag) 计算方法是什么？ 我们正在使用： authScheme.macScheme.macAlgo = HSE_MAC_ALGO_CMAC (0x11) authTag = AES256-CMAC(key=ADKP, data=Challenge[32 字节]) authLen = 16 这个计算结果正确吗？或者 CMAC 输入是否应包含其他字段（OID、功能域映射等）？ --- [Q4] hseDebugCardCmd_t 的正确数据包结构是什么？ 基于 RM 字节映射，我们目前的实现方式如下： 数据包 1（32 字节）：KRI（4 字节）+ CMD（4 字节=0x5DCDEB77）+ OID（16 字节=0xFF*16）+ AuthScheme（8 字节=CMAC） 数据包 2（32 字节）：启用调试域映射（bit27=0x08000000）+ 填充（28B） 数据包 3：debugDomainMapping(4B) + numOfAllowedUids(2B) + reserved(2B) + authLen(2B) + reserved(2B) + authTag(256B) 这个结构正确吗？HSE2 在接收到 OID 字段（0xFF 字节）后停止响应。 --- 请问您的邮箱地址是什么？我会把用于 CRS 认证的 CMM 文件发给你。 BRs。 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， @EddiePark 感谢你的帖子。 很高兴听到S32N55 平台的安全调试认证已经通过 SDC-600 使用 ADKP (HSE_OTP_FOEM_ADKP_ATTR_ID) 成功实现了 FSS 功能域调试授权。 我会继续协助您核实新问题的详细信息。很抱歉我没有看到您提供的 CMM 脚本和日志，能否请您再次上传以便我们参考？ BR 陈银 Re: S32N55 HSE2 — CRS(APP) Domain Secure Debug Authentication using ADKP 你好， @EddiePark 感谢您的回复。 本帖中已有 6 个问题，可能需要较长时间进行调查，为了提高效率，对于其他问题，我建议另开新帖进行跟踪。 正如您所提到的，会有脚本/日志作为附件供检查，但我没有在您的帖子中看到，请问它们是否会再次上传？ BR 陈银

IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Hello, We are looking for an explanation for a non-working DDR4 timing set. In short, the timings generated by the DDR Tool passed calibration and stress tests, but led to sporadic Linux kernel crashes during boot, with an "undefined instruction" error. Setup (raw facts): - The SoC is an i.MX8M Mini Solo (single Cortex-A53), DDR4 (Winbond W664GG6RB-06) at 1200 MHz (DDR4-2400) in 1:2 DFI (DDR PHY Interface) frequency-ratio mode, with a single x16 4 Gb device (512 MB, no ECC). - The BSP is NXP L4.14.98_2.0.0 (Linux 4.14.98, U-Boot 2018.03); the DDR config was generated with MSCALE DDR Tool v3.31 (Windows version) and PHY training firmware v201709. The same firmware is used in Yocto to build the U-Boot image. - We are qualifying one common timing set for three interchangeable 4 Gb x16 DDR4 parts (Alliance AS4C256M16D4, ISSI IS43QR16256B, Winbond W664GG6RB-06), all operated at 1200 MHz. - To meet the slowest part's (Winbond) tRCD/tRP/tAA (~14.16 ns at the 2400 bin) we set CL=17 (17-17-17), which the Tool encodes as MR0 = 0x0864 with the matching CL-derived registers (e.g. DFITMG0 = 0x038C8207, DRAMTMG2 = 0x0609050D). - The DRAM runs static at the 2400 setpoint (DVFS/busfreq disabled in the device tree), so there is no frequency scaling by Linux at runtime. Observations: - The 17-17-17 config passes the DDR Tool stress test (~24 h) and U-Boot mtest (~1 h) with no errors. - Under Linux (on boots that reach the shell prompt) it also passes stressapptest + fio (crc32c-verified), continuously and even at Tj = 84 °C, for over an hour with zero data errors. - Nevertheless, Linux sporadically crashes during boot with "Internal error: undefined instruction" (corrupted kernel .text), ~1.1 s into the kernel, on roughly 5–7 % of cold boots (measured with an automated cold power-cycle loop). - The failure is die-independent: the CL=17 image crashes the same way on a second of these parts (ISSI), while the CL=16 image boots Linux reliably on that same ISSI part. - Both even-CL configs boot Linux reliably: 16-16-16 (our long-standing production timing) and a newly built 18-18-18 (no kernel crashes observed) — only the odd-CL 17-17-17 fails. - Only the CL-derived registers differ between the failing and working configs (MR0 CAS bits, DFITMG0 dfi_t_rddata_en, DRAMTMG2 read latency / rd2wr, DFITMG2 rdcslat, ODTCFG rd_odt_delay). Hypothesis: We suspect odd CAS latency at the 1:2 DFI ratio is the root cause: the read-data return latency is CL/2 in DFI clocks — a non-integer 8.5 for CL=17 versus integer 8.0 / 9.0 for CL=16 / 18. Since the read FIFO (written by DQS, read by the controller clock, Reference Manual §9.3.2.2.2) handles the steady state and steady stress passes, we suspect the marginality surfaces at read burst-to-burst transitions, where odd CL's half-DFI-clock offset would hit a first/last-beat edge case the RM does not document. Questions: Is odd CAS latency (e.g. CL=17) supported on the i.MX8M Mini DDR4 PHY in 1:2 DFI mode, or are there known constraints/errata for odd CL? In particular — can the DDR Tool produce an odd-CL configuration that passes its own stress test yet is marginal under real boot traffic, and is there a recommended way to constrain read burst-to-burst timing for odd CL? Attached: kernel crash console dump, the CL=17 .ds script for the DDR Tool, and the produced ddr4_timing.c. Any advice will be appreciated. Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Sorry, somehow attachments didn't attach. Here are they.

调试 Flash 脚本覆盖“保护内部闪存区域”设置 您好， 我们目前正在测试FRDM-S32K344上从App1到App2的应用程序跳转。 我们的应用程序布局如下： 应用程序1起始地址： 0x00400000 应用程序2起始地址： 0x00500000 为了进行调试，我们使用了启用闪存保护的独立调试配置。 调试App1时，内存保护范围配置如下： 0x00500000 到 0x005FFFFF（用于保护 App2） 调试App2时，内存保护范围配置如下： 0x00400000 到 0x004FFFFF（用于保护 App1） 然而，在通过调试配置进行编程时，我们发现即使已经配置了内存保护范围，受保护的闪存区域仍然会被擦除。 请问有人能解释一下以下问题吗？ Flash Programmer 在擦除/编程操作期间是否应遵守配置的内存保护范围？ 是否需要进行任何额外的配置来防止受保护的闪存区域被擦除？ 有没有人成功地使用内存保护功能，在 FRDM-S32K344 上只编写一个应用程序的同时，保留另一个应用程序？ 日志文件和 LD 文件已附上，供您参考。 我们正在使用板上 PE 调试器 任何指导或建议都将不胜感激。 谢谢！ Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好@Avinpat123 我在相同版本的 S32 Design Studio 中进行了快速测试，以确保它能够正常工作。我使用了相同的设置——一个应用程序被强制使用 0x40_0000 地址，而 0x50_0000 地址区域配置为保留；第二个应用程序被强制使用 0x50_0000 地址，而 0x40_0000 地址区域配置为保留： 以下日志显示此配置已被应用： 而且我可以看到内存中的内容确实被保留了下来，所以它运行正常。 我从你的截图中看到你配置了地址范围，但是“保留此范围”复选框没有启用。问题不就出在这里吗？ 此致， Lukas

MBDTにおけるCANバス処理 FlexCAN0の設定には、NXPのS32K344用MBDTを使用しています。CANメッセージ処理のどの部分がNXPのブロックやツールボックスで管理され、何がアプリケーションで処理されるべきかを理解したいです。 仲裁やバッファの処理はドライバやツールボックスで管理されていますか?例：最初に0x18FEF111を送信すると、0x18FEEF00はバス上に表示されません。しかし、0x18FEEF00を先に送信すると、両方とも送信されます。両方を同時に送信すると、どちらか一方のみが表示されます。 SO、複数のフレームを同時に送信する際、各メッセージIDに専用のTxハードウェアオブジェクトを割り当てる必要がありますか? MBDTやSDKsはメッセージの優先順位付けを処理し、ACKが届かない場合に自動的に再試行しますか? 優先度の高いIDが失敗した場合（例えば、ACKが返ってこなかった場合）、他のメッセージもブロックされますか？これをどのように検知し、復旧すればよいのでしょうか？ ブロックやメッセージの喪失を避けるために、モデル内でバッファの割り当てや送信タイミングを手動で管理する必要がありますか? MBDTで複数のTxメッセージIDを設定する最適な方法は何ですか？動的バッファを使用する場合。 社内で何が処理されるのか、アプリケーションで何が処理されるのかを明確にしてください。 サンプル・モデル Re: CAN Bus Handling in MBDT こんにちは、 @SorinIBancila さん、 利用可能なHTHハードウェアオブジェクトの数よりも多くのフレームを送信する必要がある状況に遭遇しました。CanIf送信バッファリング実装はS32CTでは活用できないため、この問題に対してsimulinkベースのバッファソリューションをおすすめしてもらえますか? ありがとうございます。 サンデシュ Re: CAN Bus Handling in MBDT こんにちは、 32 CANのハードウェアオブジェクト数は制限ではありません。MCUによってはさらに制限を上げることも可能です。CANオブジェクトカウントの上限を変更できますが、数字を大きくするとS32CTがエラーを出します。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT 理解した！SO、32以上のメッセージを送信する必要がある場合、追加のTx Hardware Objectを作成するべきでしょうか?また、S32CTを使ったS32K3で単一のCANトランシーバまたはコントローラの下で設定できるハードウェアオブジェクトの最大数はどれくらいですか? 制限内に収まるように、大規模なメッセージセットに対してHOH（階層型ヘッダー）を構成する最適な方法を理解したいと考えています。 Re: CAN Bus Handling in MBDT こんにちは、 一度に何件のメッセージを送信する必要があると思いますか？ S32K358 HVBMSリファレンスデザインで以下のシナリオをテストしました: 単一の送信ハードウェアオブジェクトを使い、Can Hw Objectカウント を32に設定します(バッファ内に最大32メッセージを許可するため)。 Simulinkでは、調停プロセスを検証するために、メッセージバッファに32個のメッセージを格納し、バッファにメッセージが格納されるにつれて優先度を上げました。 結果： 予想通り、メッセージバッファが完全に満たされていないため、最初に送信されるメッセージは優先度が低くなります。6番目のメッセージあたりでバッファが埋められ、CANの優先度の高いメッセージが最初に送信されるのがわかります。 単一のトランシーバを使いたい場合、すべてのメッセージを同時に送信することは実際には不可能です。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT こんにちは、ソリンさん。 ご意見ありがとうございます！ 動的バッファを使用する場合に、MBDTで複数の送信メッセージIDを設定する最適な方法を明確にしたいと思いました。私の場合、コントローラはJ1939ベースのCANセットアップでEVアプリケーションに使われており、数百のサイクリックメッセージが関わっています。 S32CTでメッセージごとに個別のハードウェアオブジェクトを作成する方法は、拡張性にも実用性にも欠けるように思われる。単一のTxハードウェアオブジェクトを使って複数のメッセージを動的に処理し、1つのCANインターフェースを通じて同時に送信したいと考えています。 このユースケースで推奨されるセットアップやベストプラクティスについて教えていただけませんか?また、MBDTで使われる設定設定や関連関数の仕組みを理解するために参照しなければならないドキュメントもぜひ教えてください。 Re: CAN Bus Handling in MBDT こんにちは、 まず最初に、S32K3xx用のMBDTはS32K3 RTDをベースに構築されていることを指摘しておきたいと思います。ペリフェラルの設定はS32設定ツールで行い、必要な設定に完全な柔軟性を持たせます。つまり、NXPのMBDT S32K3xxで機能がサポートされているかどうかを確認するには、ペリフェラル(S32K3 RTDで使用されている)のソースコードとS32設定ツールの利用可能な設定を確認できます。 ツールボックスには、FlexCANペリフェラルの実装がこちらにあります: {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 注記！S32K3 RTDの名称は、使用するMBDT S32K3のバージョンによって異なる場合があります。 ご質問への回答は私の経験に基づくものであり、必ずしも完全に正確とは限りません。 1 & 2 & 5:ツールボックスは仲裁を扱っていませんが、SDKでこのマターに関してどんなオプションがあるのかはよくわかりません。あなたの例では、別のCanHardwareObjectを作成してそれを使って 2 番目のメッセージを送信していますが、この方法は管理が難しいかもしれません。2つ目の解決策は、バッファにより多くのメッセージを入れるためにCan Hw Object Countを作成することです。 3：S32K3 用の MBDT はメッセージの優先順位付けを処理しません。私の知る限り、FlexCANコントローラの役割は、ACKが受信されるまでメッセージを再送信しつつ、バッファ内でメッセージをブロックすることです。 4. メッセージが送信されたかどうかを検出する方法の1つは、ハードウェア割り込みコールバックで割り込みCanIf_TxConfirmationを使用して、メッセージが送信されたことをマークすることです。指定されたPDUに対して割り込みが発生しない場合、メッセージは送信されなかったことを意味します。さらに、CANバスオフの条件を満たすとトリガーされる別の割り込み(CAN_ControllerBusOff)が利用可能です。S32設定ツールには、バスオフ状態から自動的に復旧するオプションがあります。 ご質問があれば、遠慮なくご返信ください。 よろしくお願いします、 ソリン・バンシラ