Low power demo application on FRDM-KL03Z board with KSDK 1.1.0 This document describes the creation of the Low power demo application (Low power demo application on FRDM-KL03Z board ) in KDS 2.0.0  with latest version of KSDK 1.1.0. It is an update of the previous document because the KSDK 1.1.0 implementation brings new features that makes design of a low power demo application more complicated. This document describes the creation of the following low power demo application: When the application starts the green LED blink one time, The RTC device  alarm is set to 15 second  (external oscillator 32768Hz is used) to wakeup CPU and the CPU enters the VLLS1 mode (VLLS0 mode cannot be used with external oscillator).  The CPU wake up is possible by the following ways: - When you push the SW2 button the processor is woken and the green LED start blinking (5 times). - When you short the pin PTB6 to ground 5 times (the pin is available on the 8 pin header connector – pin number 4; you can for example connect a button to the pin number 4 and ground) the processor is woken and the green LED start blinking (5 times). - When selected RTC timeout expired (15 seconds) the processor is woken by the alarm interrupt and the green LED start blinking (5 times). The application is initialized again and recovery from the VLLS1 mode is executed. The alarm is set again to 15 second and the CPU enters the VLLS1 mode again. Preparation First of all the KDS 2.0.0 and KSDK 1.1.0 must be installed. You can find instructions in the document  How to install Kinetis SDK 1.1.0 support in KDS 2.0.0. New project When you properly install and update all the software you are prepared to create the Low power demo application. Create a new Kinetis design Studio project: Select the FRDM-KL03Z board Select the Kinetis SDK path to the KSDK 1.1.0 and select Processor Expert The application is created and there are not any warnings reported in the Problems window. But there is another issue. The fsl_os_abstraction component in the OSs group is added into application (it was not in the KSDK 1.0.0) and it allocated LPTMR device in the inherited fsl_lptmr_hal  component: The only solution of this conflict is removal of this component (the low power demo needn’t any OS; it is a simple application only). But this component is used by fsl_clock_manager and the fsl_clock_manager is used by PinSettings componnet. So you must remove all these component ( fsl_os_abstraction, fsl_clock_manager, PinSettings). When the PinSettings is removed from the project all signal names are also removed and you must select pins in the Cpu component again: The PinSettings component must be replaced by Init_GPIO component that allows settings of GPIO pins including routing and electrical properties. Add the Init_GPIO component into the project and set following properties (switch to Advance view): Select Device - GPIOB Set Settings/Clock Gate to Enabled. Set Settings/Pin 0 group to Initialize and select following properties of this pin (LLWU_P4): Pin Direction – Input Pull resistor – Enabled Pull selection  - Pull Up Set Settings/Pin 6 group to Initialize and select following properties of this pin (LPTMR_ALT3): Pin Direction – Input Pull resistor – Enabled Pull selection  - Pull Up Set Settings/Pin 11 group to Initialize and select following properties of this pin (PTB11 – GREEN LED): Pin Direction – Output Output value  – 1 Set Pin selection/routing/Pin 11 to Enabled. The Pin 11 group is open and the PTB11 is selected as the Pin (GPIO functionality). These settings provide initialization code for routing of selected pins and also GPIO functionality for PTB11 that used for driving of the green LED of the RGB LED on the freedom board. There is also necessary to change the linker settings when you have installed the new version of GCC tools (according to the document How to install Kinetis SDK 1.1.0 support in KDS 2.0.0 - Additional Steps for Kinetis L family chapter) Open the context menu of the project, select Properties item and change the Other linker flags settings to “-specs=nano.specs -specs=nosys.specs”, in C/C++ Build / Settings,  Tools Settigns tab, Cross ARM C++ Linker/Miscellaneous: Tip: If you want to know details of compiled code and the code size, you can use the following options to create extended list file and print code size info on the following Toolchains tab: You can generate Processor Expert code and process Build of the application without any error and warning. When the Build is finished the following information is provided in the Console window: 'Invoking: Cross ARM GNU Create Listing' arm-none-eabi-objdump --source --all-headers --demangle --line-numbers --wide "Low power demo KL03.elf" > "Low power demo KL03.lst" 'Finished building: Low power demo KL03.lst' ' ' 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf" text         data          bss          dec          hex      filename 1480          108          876         2464          9a0      Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' ' ' Note: You can see that the memory footprint is quite small because all SDK component are removed. Routing of pins Routing of pins is provided by Init_GPIO and other components in the project. There will be used following pins: SW2 - ADC0_SE9/PTB0/IRQ_5/LLWU_P4/EXTRG_IN/SPI0_SCK/I2C0_SCL – input pin for the SW2 button on the board as LLWU wakeup pin GPIO pin – PTB6/IRQ_2/LPTMR0_ALT3/TPM1_CH1/TPM1_CLKIN1 – input pin of LPTMR device LED_GREEN - PTB11/TPM0_CH0/SPI0_MISO - output pin that driver the green LED of the RGB LED on the board Adding Processor Expert components Now you can add all components for the low power demo application. fsl_gpio_hal to control GPIO pins Init_LLWU and fsl_llwu_hal components to control LLWU device Init_SRTC and fsl_rtc_hal to control RTC device Init_LPTMR and fsl_lptmr_hal to control LPTMR device fsl_smc_hal to control SMC (System Mode Controller) device CPU device We are going to use external oscillator 32768Hz and we need to configure device to allow Very Low Leakage Stop modes. There we set following properties in the Component Inspector of the CPU (switch to Advance view): Check that the Clock settings/Clock Sources/System oscillator 0 is Enabled and set Enable in stop to Enabled. The Clock source, clock pins and clock frequency are preset for the FRDM-KL03Z board Go to the Clock configuration/Clock Configuration 0 and set: Internal reference clock/Slow IRC frequency to 2MHz (it is enough for our demo application and it also decrease power consumption). MCG lite settings/MCG mode set to LIRC_2M Very low power mode to Enabled (leave setting of VLP mode entry to User because the VLLS1 mode is entered after blinking; we will write the code to enter VLLS1 mode) System clocks/Core clock set to 0.5Mhz System clocks/Bus clock set to 0.5Mhz (it allow us to enter very low leakage stop modes) Set Low Power mode setings/Acknowledge isolation to Not allowed value (we will do it in the user code) GPIO pins Open the Component Inspector of fsl_gpio_hal componet, switch to Advance view and set following properties: Select Device - GPIOB LLWU (Low-Leakage Wakeup unit) device Open the Component Inspector of Init_LLWU, switch to Advance view and set following properties: Set Settings/External Source/Pin 4 to Any edge value (we will use this pin that is connected to SW2 button) Set Pins/Pin 4 to Enabled and select  the Pin ADC0_SE9/PTB0/IRQ_5/LLWU_P4/EXTRG_IN/SPI0_SCK/I2C0_SCL in the item below Set Initialization/Utilize after reset values to no We will use the LLWU to wake-up the CPU and we need not any interrupt. RTC (Real Time Clock) device Open the Component Inspector of Init_SRTC, switch to Advance view and set following properties: Set Settings/Clock gate to Enabled Set Settings/Oscillator settings/Oscillator state to Enabled (it enable external oscillator also in stop modes) Set Settings/Time settings/Alarm time [s] to 15 (15 seconds timeout to wake-up from VLLS1 mode) Set Interrupts/ RTC interrupt/Interrupt request to Enabled Set Interrupts/ RTC interrupt/Time overflow interrupt to Disabled Set Interrupts/ RTC interrupt/Time invalid interrupt to Disabled Set Initialization/Time counter to Enabled Set Initialization/Utilize after reset values to no LPTMR (Low-Power Timer) device Open the Component Inspector of Init_LPTMR, switch to Advance view and set following properties: Set  Settings/Clock gate to Enabled Set Settings/Clock settings/Clock select to Internal 1kHz LPO (this clock source is enabled in the VLLS1 mode) Set Settings/Clock settings/Prescale value/Glitch filter to Prescaler/64; Glitch Filter 32 (it will eliminates glitches on connected button that will be used for generating pulses) Set Settings/Compare value to 4 (the LPTMR interrupt is invoked when the compare value is equal to counter and the counter value is increased, i.e. 5 pulses on the input pins invoke the LPTMR interrupt) Set Settings/Timer mode to Pulse Counter (we will use the timer to count external pulses on the input pin 3) Set Settings/Pin select to Input 3 Set Settings/Pin polarity to Active Low Set Pins/Input pin 3 to Enabled and select PTB6/IRQ_2/LPTMR0_ALT3/TPM1_CH1, TPM_CLKIN1 in Pin 3 item. Set Interrupts/Interrupt request to Enabled Set Interrupts/Timer interrupt to Enabled (we will use the timer interrupt to wakeup CPU from VLLS1 mode after 5 pulses on the input 3 pin) Set Initialization/Timer enable to yes Set Initialization/Utilize after reset values to no We have finished design time settings of Processor Expert components and we are ready to write the application code. When you generate code and Build the application there will not be any error or warning. The Processor Expert project looks as follow: Application code During the component settings we have enabled two interrupt – RTC interrupt and LPTMR interrupt. Therefore we need to write theses interrupt service routines. If you look for example into RTC.h file, you can find the declaration of the RTC_IRQHandler interrupt routine. So we can use the declaration to write the definition of the routine in the main.c program module: #define RTC_ALARM_TIMEOUT_SEC 15 /* RTC interrupt service routine */ PE_ISR(RTC_IRQHandler) { if (RTC_HAL_HasAlarmOccured(RTC_BASE)) {   // set the next alarm in RTC_ALARM_TIMEOUT_SEC seconds (clear also the TAF flag)   RTC_HAL_SetAlarmReg(RTC_BASE,RTC_HAL_GetAlarmReg(RTC_BASE) + RTC_ALARM_TIMEOUT_SEC); } if (RTC_HAL_IsTimeInvalid(RTC_BASE)) {        /* clear TIF (Time Invalid Flag) by stop of the counter and setting TSR reg */        RTC_HAL_EnableCounter(RTC_BASE, false);        RTC_HAL_SetSecsReg(RTC_BASE, 0);        /* enable counter */        RTC_HAL_EnableCounter(RTC_BASE, true); } } This interrupt routine services the Alarm interrupt in case that it is invoked during blinking of the green LED in the run mode (clear the flag and set the new Alarm time) and also it services the Invalid Time interrupt that can occur during recovering from the VLLS1 mode. Please note, that RTC module is little bit special , it runs in all  run, wait and stop modes and the reset enables the Time Invalid interrupt bit (TIIE bit in RTC_IER) and invoke the Time Invalid interrupt on reset (POR or software reset). Therefore we need to clear the Invalid Time flag otherwise the application remain invoking RTC interrupt in an infinite cycle and the application does not work at all (it is also one of the issue that has not a straight forward solution). The RTC interrupt routine (defined above) shall properly serve all case we need in our application. Please note, that RTC interrupt always cause the wake-up from low-leakage stops modes (it is not configurable by LLWU on KL03 derivatives – see the chip-specific LLWU information). In addition, the after reset value of RTC_SR register is 0x01 (TIF flag is set). Therefore when the RTC is not initialized and a low-leakage stop mode is entered the CPU is immediately woken-up due to the RTC module interrupt flag (TIF flag is set). I.e. you must always properly initialize RTC module and clear all flags before you enter a low-leakage stop mode. We need also a service routine for the LPTMR device that is used for waking up from VLSS1 mode. This is a simple interrupt service routine that just clear the LPTMR interrupt flag: /* LPTMR interrupt service routine */ PE_ISR(LPTMR0_IRQHandler) {   /* clear LPTMR interrupt flag */   LPTMR_HAL_ClearIntFlag(LPTMR0_BASE); } Now we can write the main function. We will need a temporary count variables for blinking: /* Write your local variable definition here */ volatile uint32_t i; // for waiting uint8_t blink_count; We need also a definition of the pin PTB11 that drivers the GREEN LED /* PTB11 - LED GREEN pin */ #define LED_GREEN_PIN 11 And the number of LED blinking: #define LED_BLINK 5 After devices initialization in PE_low_level_init() we need to check the reason of reset (POR reset or VLLS1 recovery). Thus we can write following code: /* Write your code here */   if (RCM_SRS0 == 0x01) { /* test the reason of reset - wakeup on VLLS */     if(PMC->REGSC &  PMC_REGSC_ACKISO_MASK) {       PMC->REGSC |= PMC_REGSC_ACKISO_MASK; /* VLLSx recovery */     }     for (blink_count = 0; blink_count < LED_BLINK; blink_count++) {        // green LED blinking     GPIO_HAL_ClearPinOutput(GPIOB_BASE,LED_GREEN_PIN);        for (i = 0; i<40000; i++);     GPIO_HAL_SetPinOutput(GPIOB_BASE,LED_GREEN_PIN);         for (i = 0; i<40000; i++);   }     // set the next alarm in "RTC_ALARM_TIMEOUT_SEC" seconds (clear also the TAF flag)     RTC_HAL_SetAlarmReg(RTC_BASE,RTC_HAL_GetAlarmReg(RTC_BASE)+RTC_ALARM_TIMEOUT_SEC);   } else {       /* power-on reset */       /* switch the green LED on */     GPIO_HAL_ClearPinOutput(GPIOB_BASE,LED_GREEN_PIN);        /* wait a while */        for (i = 0; i<40000; i++);        /* switch the green LED off */     GPIO_HAL_SetPinOutput(GPIOB_BASE,LED_GREEN_PIN);   } In case of VLLS1 recovery we acknowledge the pin isolation ACKISO bit in the PMC_REGSC register. This bit must be cleared to allow normal run mode of all pins. Then five blinking of the green LED follows (it is just a simple code for demo purposes only; you can write your own more sophisticated code for blinking by TPMx device with Init_TPM component if you want). In case of POR reset one blink of the green LED is processed. When the reset/wakup state is served by the our application code the VLLS1 mode can be entered. As the first step, we need to be sure that there are not any interrupt flags set to wake-up the CPU from VLLS1 mode so we clear LLWU and SW2 pin (PTB0) interrupt flags and then we enter VLLS1 mode by using enter_vllsx function: /* clear LLWU flag for the selected pin 4 - PTB0 */ LLWU_F1 |= LLWU_F1_WUF4_MASK; /* clear interrupt flag of the SW2 pin - PTB0 */ PORTB_PCR0 |= PORT_PCR_ISF_MASK; // enter the VLLS3 //enter_vllsx((smc_por_option_t)NULL,kSmcStopSub3); // enter the VLLS0 - RTC and LPTMR do not work becuase of external crystal clock source does not work in the VLLS0 mode //enter_vllsx(kSmcPorEnabled, kSmcStopSub0); // enter the VLLS1 enter_vllsx((smc_por_option_t)NULL,kSmcStopSub1); // switch the green LED on - error state when the VLLSx mode is not entered GPIO_HAL_ClearPinOutput(GPIOB_BASE,LED_GREEN_PIN);  There is also code for switching on the green LED in case the VLLS1 mode is not entered (indication of the error state). The enter_vllsx function is defined by the following way (it is used existing function from a demo KSDK demo example): /* * VLLSx mode entry routinue */ static void enter_vllsx(smc_por_option_t PORPOValue, smc_stop_submode_t VLLSValue) {        smc_power_mode_config_t smcConfig;        /* set power mode to specific VLLSx mode */        smcConfig.porOption = true;        smcConfig.porOptionValue = (smc_por_option_t) PORPOValue;        smcConfig.powerModeName = kPowerModeVlls;        smcConfig.stopSubMode = (smc_stop_submode_t) VLLSValue;        SMC_HAL_SetMode(SMC_BASE, &smcConfig); } It is all code we need for our low power demo application. The application can be built and run now. 'Invoking: Cross ARM GNU Create Listing' arm-none-eabi-objdump --source --all-headers --demangle --line-numbers --wide "Low power demo KL03.elf" > "Low power demo KL03.lst" 'Finished building: Low power demo KL03.lst' ' ' 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf" text         data          bss          dec          hex      filename 7828          112          896         8836         2284      Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' ' ' Note: You can see that the code size has increased because SDK functions have been used in the application. This is partly due to usage assert function that allows reporting of error by using standard libraries. If you needn’t this functionality and you need just a compact code (to decrease the power consumption) you can do it by the following way: Open Properties of the Low power demo KL03 application, select C/C++Build/Settings, on the Tool Settings tab, select Cross ARM C Compiler/Preprocessor and add NDEBUG symbol in the Defined symbols list: When you Clean and Build the application again the code size is reduced: 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf" text         data          bss          dec          hex      filename 3192          108          876         4176         1050      Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' ' ' 08:20:28 Build Finished (took 15s.886ms) There is also additional step that allows you to reduce the code size of the application. You can set Optimization Level of GNU C tools. Open Properties of the Low power demo KL03 application, select C/C++Build/Settings, on the Tool Settings tab, select Optimization and set the Optimization Level to requested value (please note that some of the level are not suitable for debugging): Debugging The application contain predefined  debug connect by default. . When you open the context menu of the project in the Project Explorer window and select Debug As/Debug Configurations.... The Debug Configurations window is opened and you can select and configure all predefined debug configurations (OpenOCD, PE Micro, Segger J-link). The default configuration can be easily used with the Freedom board (OpenSDA interface – j-link or PE Micro). You can just select the right debug connection and click on the Debug for debugging of your application. In the Debug Configuration window open the GDB SEGGER J-Link Debugger  group and select the Low power demo KL03 Debug configuration. See the Debugger tab, there is already filled MKL03Z32xxx4 Device name. Uncheck Allocate console for semihosting and SWO (SWO is not support by OpenSDA SEGGER J-link). Go to on Startup tab and uncheck the Enable SWO option (SWO is not supported by OpenSDA SEGGER J-link). Click on the Apply and Debug button and the debugger starts (you must have the FRDM-KL03Z board connect to the workstation). You can now start the application (click on the Resume button) and check the functionality. The debugger is disconnected due to VLLS1 mode entry. But the application run and can be used. If you want to connect a button for the LPTMR pulses generating you can connect one pin of the button to the PTB6 on pin #4 of 8-pins connector J1 and the second pin of the button to the GND to the pin #7 of the 10-pins connector J2, see below: You can use this demo application as a start point of your real low power application. I hope it will help you and save your time of your first low power application implementation in the Processor Expert. There is also possible to measure power consumption of the CPU in VLLS1 mode. It is described in the FRDM-KL03 User Guide. Just unsolder R27 and R28 and solder a header pins to J10 position of the board. You must use jumper for J10 now to connect power supply for the CPU and when the jumper is removed you can use these two pins to measure the energy consumption of the CPU (e.g. by a multimeter)

规则 - 2015 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 注册要求 最低技能 需要具有 C 或 Java 的使用经验。 需要具有 Linux 系统使用经验。 具有嵌入式编程经验者优先，但不是必须的。 团队 来自布加勒斯特理工大学或军事技术学院的一至三名成员。 2015年Linux嵌入式挑战赛

iMX28 WinCE 6.0 UART 驱动程序更新以修复 RX DMA 数据丢失问题。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 最新的 iMX28 WinCE 6.0 BSP“WCE600_MX28_SDK1008”存在 UART RX DMA 数据丢失问题。 测试用例以重现该问题： 使用 UART 电缆连接 iMX28 UART1 和 PC，然后在 iMX28 和 PC 端运行一些 UART 测试应用程序，PC 可以向 IMX28 发送文件，文件大小应大于默认 RX DMA 缓冲区大小 1024 字节，然后从 iMX28 端，将会丢失数据。 附件“SERIALAPP.zip”是更新的UART驱动程序代码，用于修复此问题，您可以解压缩并将其更新到“ wince600\platform\common\src\soc\common_fsl_v2_pdk1_9\serialapp ”文件夹，并重建WinCE映像。 本次更新针对 UART RX DMA 实现了以下改进： 1.添加DMA恢复代码。 当 DMA 模式下发生 UART 错误时，驱动程序将重新初始化 DMA 以进行下一次传输。 2.将UART DMA超时中断设置为5ms。“#定义SERIAL_DMA_RX_TIMEOUT 5” UART DMA中断发生后，IST需要将数据从DMA缓冲区复制到MDD缓冲区，因此需要时间。默认的BSP已经把这个延迟设置为31位传输时间，这个时间非常短，如果PC向iMX28发送“DMA缓冲区+1”个字节，在第一次DMA缓冲区满中断发生后，很快就会发生第二次DMA超时中断，这个中断将会丢失，因为驱动程序仍在处理预中断。 3. 更新 MDD 代码以确保发送到 PDD 的缓冲区始终大于 RX DMA 缓冲区。 此 MDD 代码修改仅在 DMA 模式下有效，因此对 PIO 模式没有影响。 4.更新UART DMA中断处理程序代码。 当发生UART DMA中断时，立即设置下一次DMA传输，这样DMA就可以继续用另一个DMA缓冲区接收数据，同时IST会将数据从预DMA缓冲区复制到MDD缓冲区。 回复：iMX28 WinCE 6.0 UART 驱动程序更新以修复 RX DMA 数据丢失问题。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您看到我关于这个问题的长篇文章了吗？我发现是循环缓冲区的处理导致了 RX DMA 数据丢失。这篇文章中有很多信息，但我的修复似乎与您的不同，所以看起来我可能也需要研究您的更改！ i.MX28 Windows CE BSP 串行端口错误导致接收数据丢失 Mark

MAPS 启动和介绍 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 梁平主讲 基于 ARM ®技术的 DwF Kinetis MCU 南京站 — 2015 年 3 月 12 日 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 梁平主讲 基于 ARM ®技术的 DwF Kinetis MCU 南京站 — 2015 年 3 月 12 日 Arm® 处理器 Kinetis Cortex ® -M 微控制器

MMA9553L 计步器使用指南     MMA9553L是飞思卡尔的一款计步传感器，本文就如何快速使用该传感器做一个简单介绍。    你可能还见到过MMA955xL， 它与MMA9553L是什么关系呢？简单的来说MMA955xL是一个统称，它包括MMA9550L、MMA9551L、MMA9553L和MMA9559L这几个具体型号，其实这四种传感器在硬件上都是一样的。其内部主要由ColdFire 内核、模拟前端、Flash、IIC和SPI接口等部分组成，原理框图如下图所示：    它们的不同之处在于内部的Firmware不同，Firmware在芯片出厂时就已经固化在芯片里面了，不同的Firmware对于不同的功能。这里介绍的MMA9553L主要就用作计步器功能。        MMA9553L和MCU之间可以通过IIC接口或者SPI接口通讯，所以使用MMA9553L的首要前提是把MCU的IIC或者SPI调通。接口调通之后就可以来操作此传感器了。这里以IIC为例来说明。附件为参考代码。 测试平台：IAR7.2 + FRDM_KL25Z+FRDM-FXS-MULTI FRDM-FXS-MULTI开发板上带有MMA9553L，将FRDM-FXS-MULTI开发板和FRDM_KL25Z连接在一起就可以使用了。     下面分析一下源代码：        首先是调用初始化函数pedometer_init()，此函数主要调用以下几个函数：      pedometer_write_config();       // config     pedometer_enable();         // enable pedometer     pedometer_int0_enable();    // enable INT_O pin     pedometer_active();         // active MMA9553 pedometer_wakeup();   // wakeup 在此重点分析前两个函数。第一个函数 pedometer_write_config()，该函数的具体实现如下： void pedometer_write_config(void) {     unsigned char Buf[]={0x15,0x20,0x00,0x10,                            0x0C,0xE0,                            0x13,0x20,                            0x00,0x96,                            0x60,0x50,                            0xAF,0x50,                            0x04,0x03,                            0x05,0x01,                            0x00,0x00};     dvMMA9553_Write(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 20); } 此函数很简单，就是通过IIC给9553发送一条命令，命令的内容Buf数组中的20个字节    的数据。 dvMMA9553_Write()函数的第一个参数代表MMA9553L的地址，为0x4C。datasheet中有说明。 #define MMA9553_Slave_Addr  0x4C dvMMA9553_Write()函数的第二个参数代表寄存器地址，为0x00。 #define MMA9553_Sub_Addr    0x00 发送的这一串命令：0x15,0x20,0x00,0x10,0x0C,0xE0,0x13,0x20,0x00,0x96,0x60,0x50,0xAF,0x50,0x04,0x03,0x05,0x01,0x00,0x00 具体是什么含义呢？ 0x15：表示Application ID，计步器的Application ID就是0x15 0x20：表示这条命令是Write Config command，即这条命令是用来写Configuration 寄存器的。 0x00：表示配置寄存器的偏移地址。 0x10：表示要写16字节的内容。 0x0C,0xE0,0x13,0x20,0x00,0x96,0x60,0x50,0xAF,0x50,0x04,0x03,0x05,0x01,0x00,0x00 这16字节就是写入配置寄存器中的具体内容。 配置寄存器共用8个，分别是Sleep Minimum register，Sleep Maximum register，Sleep Count Threshold register，Configuration/Step Length register，Height/Weight register，Filter register，Speed Period/Step Coalesce register，Activity Count Threshold register，每个寄存器为16 bit（2 字节），所以总共16字节。 第二个函数 pedometer_enable()，该函数的具体实现如下： void pedometer_enable(void) {     unsigned char Buf[]={0x17,0x20,0x05,0x01,0x00};     dvMMA9553_Write(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 5); } 这次写入的命令是0x17,0x20,0x05,0x01,0x00 0x17：表示Application ID 0x20：表示这条命令是Write Config command 0x05,0x01,0x00 这三个表示在偏移地址0x5处，写入一个字节的数据0x00 其他几个函数也类似，都是写入一条命令，对某种Application的配置寄存进行设置。 初始化完了，现在就可以读取步数了。 通过调用pedometer_main() 函数就可以读取到步数。 该函数的实现如下： void pedometer_main(void) {     unsigned char Buf[20];     pedometer_cmd_readstatus(); // read  status      while(1)         {            dvMMA9553_Read(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 2);            if(Buf[1]==0x80)            {               dvMMA9553_Read(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 16);               break;             }         }         m_status.StepCount = Buf[6] * 256 + Buf[7];         m_status.Distance  = Buf[8] * 256 + Buf[9];         m_status.Calories  = Buf[12] * 256 + Buf[13]; } 主要调用了两个函数，一是pedometer_cmd_readstatus()，这个函数的实现如下： void pedometer_cmd_readstatus(void) {     unsigned char Buf[]={0x15,0x30,0x00,0x0C};     dvMMA9553_Write(MMA9553_Slave_Addr, MMA9553_Sub_Addr, Buf, 4 ); } 它是发送了0x15,0x30,0x00,0x0C这条命令 0x15：表示Application ID 0x30：表示Read Status command 0x00：表示偏移地址 0x0C：表示需要读的字节数为12 之后调用dvMMA9553_Read()函数，通过IIC读取16字节的数据（4字节起始信息+12字节status register内容），读到的16字节数据如下： Step count register寄存器如下，通过其值可以算出步数来。    另外还可以读取三轴加速度的值，过程与读取步数是类似的，也是先写配置寄存器，然后再读取状态寄存器。   总的来说操作MMA955L的关键搞清楚有两个重要的寄存器：配置寄存器和状态寄存器。配置寄存器可读可写，状态寄存器只可读。 写配置寄存器，格式是： APP_ID+0x20+offset+number+number字节的内容 读配置寄存器，格式为： 先发送：APP_ID+0x10+offset+number， 再通过IIC读number+4字节的内容，前4字节为起始信息。 读状态寄存器,格式为： 先发送：APP_ID+0x30+offset+number，再通过IIC读number+4字节的内容，前4字节为起始信息。 读Command 回的内容如下：

Install Packages.txt

MCUXpresso IDE v11.8.1 现已推出 我们很高兴地宣布 MCUXpresso IDE v11.8.1（build 1197）现已推出。 这是一个基于之前的 MCUXpresso IDE v11.8.0 版本的维护版本，我们建议所有现有用户下载并安装这个新版本。   安装程序下载 要下载所有平台的安装程序，请登录我们的下载网站： https://www.nxp.com/mcuxpresso/ide/download   文档 更多信息可在更新后的用户指南及其他文档中查阅，这些文档可通过 IDE 的“帮助”菜单访问内置帮助系统，或以 PDF 格式从安装目录中获取。   未来版本的发布通知 如需接收有关未来版本发布的通知，请关注：MCUXpresso IDE - 发布历史   变更摘要 - 版本 11.8.1 - 2023 年 10 月 升级：更新的 SEGGER J-Link 软件 (v7.92l)。 已升级：更新的 PEmicro 插件（v5.7.3）。 新增：支持 i.MX RT1180 设备和 MIMXRT1180-EVK 板。 新增：支持 KE1xZ512 器件和 X-FRDM-KE17Z512 开发板。 新增：支持 MCXA153 设备和 FRDM-MCXA153 开发板。 改进：[工具链集成] 在支持的编译器方言列表中添加了 C++20 和 C++23 条目。 修复：[Debugger][RW61x] 当安全项目位于闪存中时，连接脚本在 SYSRESET 后不会暂停。 修复：[Flash Programmer] 与 Flash blank 命令相关的一些问题。 已修复：[SDK 集成] 更改设备包时，未考虑设备特定的预处理器定义。   已知问题 请参阅安装布局中的 KnownIssues.txt 文件以获取详细列表。  

i.MX7D DRAM Register Programming Aids Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. These are detailed programming aids for the registers associated with DRAM initialization (LPDDR3, DDR3, and LPDDR2). The last work sheet tab in the tool formats the register settings for use with the ARM DS5 debugger. It can also be used with the windows executable for the DDR Stress Test (note the removal of debugger specific commands in this tab). These programming aids were developed for internal NXP validation boards. This tool serves as an aid to assist with programming the DDR interface of the MX7D and is based on the DDR initialization scripts developed for NXP boards and no guarantees are made by this tool. The following are some general notes regarding this tool: The default configuration for the tool is to enable bank interleaving. Refer to the "How To Use" tab in the tool as a starting point to use this tool. The tool can be configured for one of the three memory types supported by the MX7D.  However, three separate programming aids are provided based on the DRAM type: LPDDR3, LPDDR2, and DDR3.  Therefore, you may use the tool pre-configured for your desired memory type as a starting point. The DRAM controller IP in MX7D is different from the MX6 series MMDC controller. Results from DRAM calibration may be updated for the following registers: DDR_PHY_OFFSET_WR_CON0 (0x30790030) and DDR_PHY_OFFSET_RD_CON0 (0x30790020).  Also, the MX7D memory map DRAM starting address is fixed at 0x80000000. Some of the CCM programming at the beginning of the DRAM initialization script (in the "DStream .ds file" tab) were automatically generated and in very few cases may involve writing to reserved bits, however, these writes to reserved bits are simply ignored. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. For questions or additional assistance using this tool, please contact your local sales or FAE. Re: i.MX7D DRAM Register Programming Aid Hi LinWang, Thank you for bringing this to my attention.  I have made the necessary changes per the thread you referenced. Thanks, Mike Re: i.MX7D DRAM Register Programming Aid Hello Michael, One ZQ cali related bug had been idendified, please refer to thread.i.MX7 : ZQ calibration sequence is inconsistent with reference manual Update programming aid will be appreciated.

i.MX RT1064 - PEmicro 连接助手错误和启动配置意外更改 您好， 我正在使用i.MX RT1064控制器，并通过 MCUXpresso IDE 中的PEmicro Multilink接口进行调试/烧录。 有时，我在尝试连接目标设备时会遇到附件中的“PEmicro 连接助手”错误。这个问题似乎是随机发生的；我还没有发现任何特定的软件活动、代码更改或硬件事件会持续触发信号它。 我观察到，当出现此错误时，控制器的启动配置似乎发生了意外变化。在这种状态下，我无法对设备进行刷机或调试。我目前唯一能恢复的方法是将启动配置恢复到其原始设置——内部闪存模式，之后刷写和调试功能就能再次正常工作了。 一些补充细节： MCU：i.MX RT1064 调试探针：PEmicro 多链路通用 Rev E IDE：MCUXpresso IDE 有人遇到过类似的问题吗？ 我希望您能就以下方面提供指导： 什么原因会导致启动配置意外更改？ 是否存在调试器或应用程序代码可能影响启动配置的已知场景。 防止这种情况发生的建议方法。 能否在不手动更改的情况下通过软件更改启动配置 我附上了错误信息的截图供您参考。 谢谢！ i.MX RT106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好， 您能帮我解答以下问题吗？ 你用的是定制主板还是EVK主板？ 您使用的是哪个版本的SDK和IDE？ 你烧断过熔丝吗？ 您提到需要将启动配置恢复到内部闪存模式——您目前使用的是哪种启动配置？ 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 我使用的是定制电路板，但这个问题在 EVK 上也出现过。 SDK 版本：26.03.00 IDE 版本：25.6.136 我们没有烧断熔丝。 我们通常使用内部启动模式来烧录代码并进行正常操作，但它会随机导致一些意想不到的问题，所以我们将其更改为串行下载模式，擦除闪存，然后再将其改回内部启动模式，之后再次烧录代码。 请查看附件图片以获取启动配置信息。 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好@Subhasri_S ， 通过在 POR_B 的上升沿对 BOOT_MODE0 和 BOOT_MODE1 输入进行采样来初始化 BOOT_MODE 寄存器。对这些输入进行采样后，它们的后续状态不会影响内部 BOOT_MODE 寄存器的内容。 如果 BT_FUSE_SEL = 0，则可以使用 GPIO 引脚而不是 eFuse 来设置特定的启动配置参数。 能否请您在问题出现时，在 RESET 过程中测量一下 BOOT_MODE 和 BT_CFG 引脚的值？ 关于此问题的另一种可能结论，请参阅以下知识库文章： 知识库： RT板恢复调试器连接问题 “当闪存中包含异常应用程序（访问内存不存在、内存损坏、时钟配置错误等）时，会导致板处于未知状态，此时调试器无法控制内核。但是，当将核心置于串行下载器模式时，它将使核心处于已知状态，这样，调试器就可以控制核心。 因此，当RT板出现调试器问题时，尝试在串行下载模式下批量擦除外部闪存，这样就能使板载调试器恢复正常状态。 此致， 巴勃罗

S32K388 FXOSC GM_SEL 推荐值（适用于 8/16/20/40 MHz 晶体） NXP社区的各位好， 我正在做一个 S32K388 项目，并配置 FXOSC（快速晶振（晶体振荡器））。我在参考手册中看到 GM_SEL 用于选择 FXOSC 放大器的跨导，但我找不到将晶体频率与 GM_SEL 值对应起来的清晰推荐表。 当前配置： 晶体：16 MHz 无源晶体 GM_SEL = 12 (0xC，~0.7016x) EOCV = 157 OSC_BYP = 0（晶体模式） COMP_EN = 1 对于 16 MHz 的频率，这种方法效果很好。 我的问题：我希望支持多种晶体选项：8 MHz、16 MHz、20 MHz 和 40 MHz。 请问谁能分享一下各个频率的推荐GM_SEL值？或者能否提供一份 NXP 应用笔记或表格，其中提供了这方面的指导？ 具体来说： 对于每个标准 FXOSC 频率（8/16/20/40 MHz），是否有推荐的 GM_SEL 值？ 对于 20 MHz 晶体，为了获得可靠的振荡，GM_SEL 是否应该从 12 增加到 15（最大值）？ GM_SEL 的选择主要取决于晶体频率、ESR、负载电容，还是所有这些因素？ 任何指导或参考资料都将不胜感激。 顺祝商祺！ Re: S32K388 FXOSC GM_SEL recommended values for 8/16/20/40 MHz crystals 嗨@xlele 在《S32K3 MCU 通用硬件设计包》中包含的《S32K3xx 微控制器硬件设计指南》修订版 E2 的 3.2 节中提到，“当 GM > 5 × gmcrit 时，晶振（晶体振荡器）电路可提供非常安全稳定的振荡”，并且还定义了 gmcrit 的计算方法。 此外，在 S32K3xx 数据手册第 14 版的 11.4 节中，针对 ALC 禁用模式，提供了 GM = 4'b0010 的通用推荐设置。 最后，例如，如果根据晶体规格，需要跨导 G = 12 mA/V 来确定 CTRL[GM_SEL] 值： 12 mA = 18.5 mA × N N = 12 mA / 18.5 mA = 0.6486 寄存器设置支持的最近值对应于 CTRL[GM_SEL] = 1010b → 0.6681× BR，VaneB

BMA7318 固件驱动程序 我们正在为BESS市场开发HV 电池管理系统和电池组。我在哪里可以下载 BMA7318 固件驱动程序，用于我们的软件开发或任何其他 BMS7318 示例代码。我们已经与恩智浦签订了 NDA 协议？ Re: BMA7318 Firmware Drivers 嗨，托马斯、 看起来 BMA7318 驱动程序在 电池管理系统 SDK " Lite SDK " 版本中。但是，当我查看 "下载 "时，却没有看到 Lite SDK？ srnp6037_0-1779094020762.png Re: BMA7318 Firmware Drivers 您好， 有关 BMA7318 固件驱动程序和示例软件，请参阅 BMS 软件 SDK，其中包含所有 BCC 设备（包括 BMA7xxx 系列）的生产级驱动程序和参考实现： https://www.nxp.com/design/design-center/software/embedded-software/nxp-battery-management-software-development-kit-and-toolchain:BMS-SW   BRs, Tomas   Re: BMA7318 Firmware Drivers 嗨，托马斯、 我绑定了，点击链接时会将我带到我的个人资料页面。没有成功。 谢谢！ 纳迦 Re: BMA7318 Firmware Drivers 您好， 请尝试从以下链接下载，可以使用 NXP 软件帐户： BMS Light SDK AUTOSAR 4.4 R21-11 版本 0.8.0 CD02 BRs, Tomas

i.MX RT1176 中外部闪存执行冻结 你好！我正在为 i.MX RT1176 开发代码。我的代码通过外部闪存（型号 MX25UM51345G）和 XIP 运行，某些功能通过 RAM 运行。 启动工作正常，但执行大约 30 秒后处理器会死机。在连接调试器时，我发现 PC 被外部闪存中的一条指令卡住了（不一定是同一条指令或功能），而步进/恢复执行也无济于事（仍然卡在同一个 PC 上）。不产生故障。 我读取了 FlexSPI、SEMC 和 Cortex M-7 寄存器寄存器，但似乎一切正常。 核心冻结后，我可以强制 PC 进入 RAM（使用调试器），代码执行正常，直到代码尝试跳回闪存。 此外，在这种状态下从 RAM 执行的代码似乎能够读取闪存数据。 既然从闪存中读取数据是正常的，我想这可能是从闪存中获取指令的问题，但我不能肯定。即使是从闪存获取指令的问题，我也不知道该如何调试。 如有任何帮助，将不胜感激。 i.MX-RT1170 i.MXRT Re: External flash execution freeze in i.MX RT1176 谢谢您的建议。 我研究过是否可能存在你所说的冲突，但我的代码都没有向外部闪存写入、配置、发送 IP 命令等。 我还检查了 FLEXSPI 模块中的 INTR 寄存器，以确保在系统试图执行闪存中的指令时卡住之前没有产生错误，结果也没有产生错误。有没有办法（寄存器或位）检查是否发生了碰撞？在我不修改闪存的情况下，会发生这种碰撞吗（比如说预取和指令取入碰撞？） 谢谢 Re: External flash execution freeze in i.MX RT1176 嗨，@isstivenalive、 感谢您对 NXP MIMXRT 系列的关注！ 根据您描述的症状，MCU 似乎运行正常。RAM 中的代码运行正常，系统可以从闪存读取数据和向闪存写入数据，但 XIP 却卡住了。 我认为目前最可能的根本原因是 AHB 预取/缓存与运行期间在同一 XIP 闪存上执行的 IP 命令、LUT/模式更新或擦除/写入操作之间发生了冲突。请检查是否在类似操作中出现问题。 如果需要在系统运行时对同一 XIP Flash 进行任何 IP 命令或配置更改，则必须将代码加载到 SRAM 中才能执行。 使用单个闪存设备时，闪存在繁忙时不会对进一步的访问做出响应。它还指出，与闪存写入相关的代码应从内部 SRAM 运行，应禁用中断以避免意外访问 Flash，并且 LUT 更新需要重置软件以避免冲突问题。 有一个最简单的故障排除方法：首先禁用所有闪存操作，然后只运行 XIP，看看是否能解决之前的问题。有关详情，请参阅此 AN：https://www.nxp.com/docs/en/application-note/AN12564.pdf。 致以最诚挚的问候， Gavin Re: External flash execution freeze in i.MX RT1176 嗨，@isstivenalive、 我不知道有专用 FlexSPI 寄存器位报告 “预取/指令提取冲突”。INTR 只报告已定义的错误/超时，因此干净的 INTR 并不能完全排除 XIP 读路径问题。 在这种情况下，下一个疑点应该是纯 XIP 读路径条件：FlexSPI AHB 预取/缓存行为、Cortex-M7 推测/缓存行取回、MPU 内存属性、FlexSPI 采样时钟/DQS/DLL 时序余量，以及八进制 DDR 闪存的 LUT/虚拟/模式配置。 为了缩小范围，请尝试以下测试。 禁用 FlexSPI AHB 预取 这只是为了先进行调试，检查挂起是否与 AHB 预取/缓冲区行为有关。 减少 FlexSPI 根时钟/串行时钟 如果问题在较低的时钟消失，则更多地指向 DQS/DLL 采样余量、电路板级信号完整性或虚拟周期时序。 暂时禁用指令缓存/数据缓存或查看 MPU 属性 重新检查 AHB 读取 LUT 和闪存时序配置 检查挂起后的 FlexSPI 状态 致以最诚挚的问候， Gavin

S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) 同期モードで応答なし こんにちは、 私はS32N55プラットフォームを使用したお客様プロジェクトに取り組んでおり、HSE_OTP_FOEM_ADKP_ATTR_IDを指定してSetAttributeを初めて呼び出す際に問題が発生しています。 --- [環境] - プラットフォーム：S32N55 EVB（シリコンB0） - GrayVIP: 1.0.24 - FSS FW SDK: 1.13.0以降 - 現在のライフサイクル：OEM_OPEN（GetAttributeで確認済み） - ADKP: プロビジョニングされていません（初回試行） - HSEタイムアウト: CRYPTO_43_HSE_TIMEOUT_DURATION_U32 = 1,000,000,000 --- [問題] SetAttribute を HSE_OTP_FOEM_ADKP_ATTR_ID で呼び出した場合、HSE は同期モードで応答を返しません。Mu_Ip_IsResponseReady() は決して TRUE を返さないため、タイムアウト値に関係なくタイムアウトが発生します。 その他の SetAttribute 呼び出し (例:HSE_OTP_GO_SECURE_ATTR_ID) は同じ同期メカニズムで正しく動作します。 --- [コード] hseSrvDescriptor_t xLocalDesc = {0}; hseSetAttrSrv_t* pSetAttrReq; xLocalDesc.srvId = HSE_SRV_ID_SET_ATTR; pSetAttrReq = &(xLocalDesc.hseSrv.setAttrReq); pSetAttrReq->attrId = HSE_OTP_FOEM_ADKP_ATTR_ID; pSetAttrReq->attrLen = sizeof(hseAttrOtpFoemAdkp_t); /* 32バイト */ pSetAttrReq->pAttr = Hse_Ip_ToAHBAddress((HOST_ADDR)pAdkpBuf); xHseIpReq.eReqType = HSE_IP_REQTYPE_SYNC; xHseIpReq.u32Timeout = CRYPTO_43_HSE_TIMEOUT_DURATION_U32; hseResp = Hse_Ip_ServiceRequest(u8MuInst, u8MuCh, &xHseIpReq, (hseSrvDescriptor_t *)Hse_Ip_ToAHBAddress( (HOST_ADDR)&g_hseShared.axHseSrvDesc[u8MuInst][u8MuCh])); /* HSE は決して応答しない - Mu_Ip_IsResponseReady() は常に FALSE を返す */ --- [SetAttribute呼び出し前に前提条件を確認します] 1. LCはOEM_OPENです（GetAttributeで確認済み）。 2. このデバイスではADKPが一度もプロビジョニングされていません。 3. ADKPバッファはキャッシュ不可能な共有メモリに配置されます。 4. アドレスは Hse_Ip_ToAHBAddress() を介して変換されます --- [観察事項1 - 非同期モード] GrayVIP リファレンス実装 (Fss_Firmware_ProgSecureFuseADK) を見ると、 ADKP の SetAttribute は、WaitEvent を使用した非同期メカニズムで呼び出されます。 RetVal = Fss_Sem_SetHseAttribute(&setAttr); if (E_OK == hseResponse) ヤージュ WaitEvent(FSS_SEM_HSESETATTR_EVENT_NAME); RetVal = Fss_Sem_GetHseAsynResponse(); } これは、S32N55 HSE2 では OTP 書き込み操作に非同期モードが必要になる可能性があることを示唆しています。 --- [観察事項2 - VGPIOヒューズ電源有効化] GrayVIPでは、Fss_Firmware_FuseProgramming()によってヒューズプログラミング機能が有効になります。 ブート構成ヒューズを書き込む前に、VGPIO を介して以下の情報を取得します。 VGPIO_Type *pVgpio = (VGPIO_Type *)FUSE_VDD_EN_PORT_ADDRESS; pVgpio->OV[FUSE_VDD_EN_BANK].PMOS = (1 << FUSE_VDD_EN_PIN); pVgpio->OV[FUSE_VDD_EN_BANK].OE |= (1 << FUSE_VDD_EN_PIN); pVgpio->OV[FUSE_VDD_EN_BANK].OVS = (1 << FUSE_VDD_EN_PIN); しかし、Fss_Firmware_ProgSecureFuseADK() (ADKP書き込み) は明示的に これを電源投入シーケンスと呼ぶ。以下の点については不明です。 1. HSE2 は OTP 属性書き込みのためにヒューズ電源を内部的に処理します。 2. SetAttribute(ADKP)を実行する前に、VGPIOヒューズ電源の有効化も必要です。 さらに、GrayVIPにはヒューズ電源無効化シーケンスは含まれていません。 書く。VGPIOヒューズ電源を有効にしたままにしておくことについて懸念しています OTP書き込み後に意図しないヒューズ書き込みやセキュリティ上の問題が発生する可能性があります。 --- 【質問】 1.SetAttribute(ADKP) で同期モード (HSE_IP_REQTYPE_SYNC) がサポートされていますか？ または、S32N55 HSE2でのOTP書き込み操作には非同期モードが必須ですか？ 2. VGPIOヒューズプログラミング電源有効化は呼び出し前に必要ですか？ SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID)? 3. VGPIOヒューズ電源有効化が必要な場合、正しい手順は何ですか？ OTP書き込み完了後に無効にするには？ 4. SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) を呼び出す前に、他に前提条件はありますか？ それは文書化されていない可能性がある？ これは、お客様へのプロジェクト納品における重大な障害となっています。 何かご助言いただければ大変ありがたいです。 よろしくお願いします。 Re: S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) No Response in Synchronous Mode エディ・パークさん、こんにちは。 ご質問への回答は以下のとおりです。 SetAttribute(ADKP) では同期モード (HSE_IP_REQTYPE_SYNC) がサポートされていますか、それとも S32N55 HSE2 での OTP 書き込み操作には非同期モードが必須ですか？ FSSファームウェアから私が理解できる範囲では、そうではありません。ご覧のとおり、あなたが言及したWaitおよびClear関数呼び出しは、条件付きコンパイル#ifdef FSS_SEM_HSESETATTR_EVENT_NAMEによって保護されています。こうすることで、リクエストが処理された後も確実に処理を続行できます。 SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID)を呼び出す前に、VGPIOヒューズのプログラミング電源有効化が必要ですか？ いいえ、そうではありません。HSE2 で処理されるワンタイムプログラマブルワードには 2 種類あり、1 つは fusebox と呼ばれ、hseSrvProgFuse_t サービスによって処理されます。これには VDD_EFUSE への電源供給が必要で、これは S32N55 RDB の GPIO ピンとトランジスタによって制御されます。もう一方のタイプは通常単にOTPと呼ばれ、これらはVDD_EFUSEの電源投入を必要としないため、GPIOをオンにする必要もありません。 私が言及している電力ドメインについては、リファレンスマニュアル、特に図35「FSS電力ドメイン」 [S32N55リファレンスマニュアル、改訂版2、2025年6月30日、241ページ]で確認できます。 VGPIOヒューズの電源有効化が必要な場合、OTP書き込み完了後にそれを無効にする正しい手順は何ですか？ ボードによりますが、S32N55 RDB ではコードに示されている GPIO によって制御されますが、カスタムボードではジャンパーまたは 0 オーム抵抗器になる場合があります。したがって、RDBではピンをオフにするだけでVDD_EFUSEの電源がオフになります。また、J18で制御することもできます。このコネクタにジャンパーがあると、GPIOの状態に関係なく、VDD_EFUSEは常にオンになります。 SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) を呼び出す前に、文書化されていない追加の前提条件はありますか？ 未知の前提条件を示唆するような情報は何も見つかりませんでした。HSE2の他のサービスを問題なく利用できたことはありますか？ 他に質問があれば、遠慮なくお尋ねください。 なお、他の投稿でも述べたように、S32N55はまだ試作段階であるため、この件に関する私の専門知識はまだ最高レベルには達していません。とはいえ、できる限りお手伝いさせていただきます。 Re: S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) No Response in Synchronous Mode こんにちは、 @EddiePark さん、 この件については、より専門的なサポートを受けるために、社内チームに連絡する必要があります。彼らから最新情報が入り次第、ご連絡いたします。 ご理解とご協力に感謝いたします。 Re: S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) No Response in Synchronous Mode こんにちは、 S32N55 上で HSE2 SetAttribute サービスを使用して ADKP (アプリケーションデバッグキー/パスワード) をプログラムしようとしていますが、HSE2 から応答がありません。 --- ＃＃ 環境 - プラットフォーム: S32N55 EVB - GrayVIP バージョン: SW32N5_GRAYVIP_1_0_22_0 - FSS FW バージョン: S32N_FSS_FW_R21-11_1.10.0 - EB Tresos バージョン: 29.0.0 - 呼び出し元: FSS M7 コア、Fss_FW_Init_Task() 内 --- ## 私たちが試したこと ### 試行 1: 同期モード (HSE_IP_REQTYPE_SYNC) 「`c」 xLocalDesc.srvId = HSE_SRV_ID_SET_ATTR; pSetAttrReq->attrId = HSE_OTP_FOEM_ADKP_ATTR_ID; pSetAttrReq->attrLen = 32U; /* hseAttrOtpFoemKey_t サイズ */ pSetAttrReq->pAttr = Hse_Ip_ToAHBAddress((HOST_ADDR)pAttr); RetVal = Sherpa_Cdd_Execute(&xLocalDesc); /* 同期 */ 「`」 結果：タイムアウト - HSE2からの応答なし ### 試行2：非同期モード（HSE_IP_REQTYPE_ASYNC_IRQ） 「`c」 g_xSherpaHseIpReq.eReqType = HSE_IP_REQTYPE_ASYNC_IRQ; g_xSherpaHseIpReq.pfCallback = &Sherpa_Cdd_HseCallback; /* IRQコールバックによってポーリングbDoneフラグが設定されます */ ((FALSE == g_xSherpaCallbackParam.bDone) && (u32Timeout > 0U)) の間 ヤージュ u32タイムアウト--; } 「`」 結果：タイムアウト - bDoneがTRUEに設定されませんでした（コールバックが呼び出されませんでした） ### 試行3：VGPIO VDD_EFUSE電源有効化 「`c」 /* VGPIO経由でVDD_EFUSEを有効にする */ pVgpio->OV[BANK].PMOS = (1U << PIN); pVgpio->OV[BANK].OE |= (1U << PIN); pVgpio->OV[BANK].OVS = (1U << PIN); 「`」 結果：ShutdownHookが呼び出されました（VGPIOレジスタへのアクセス時にバスエラーが発生しました） --- ## 現在の実装 「`c」 Std_ReturnType SecureDebug_SetADKP(const uint8_t* pDebugKey) ヤージュ /* 1. LC == OEM_OPEN を確認する */ eRetVal = Sherpa_Cdd_GetAttribute(HSE_OTP_LIFECYCLE_ATTR_ID, ...); if (HSE_LC_OEM_OPEN != *pLcInSharedMem) { break; } /* 2. ADKPが既にプログラムされているか確認する */ eRetVal = Sherpa_Cdd_GetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID, ...); if (E_OK == eRetVal) { /* 既にプログラム済み */ break; } /* 3. 32バイトのキーをキャッシュ不可能な共有バッファにコピーする */ memcpy(pAdkpInSharedMem, pDebugKey, HSE_OTP_FOEM_KEY_SIZE); __DMB(); __ DSB(); /* 4. SetAttribute */ eRetVal = Sherpa_Cdd_SetAttribute( HSE_OTP_FOEM_ADKP_ATTR_ID、 HSE_OTP_FOEM_KEY_SIZE、/* 32バイト */ (void*)pAdkpInSharedMem); } 「`」 --- ## 質問 1.HSE2ファームウェアリファレンスマニュアルの図12によると、入力サイズが16の場合、HSEはそれを通常のAES-128キーとして扱います。入力サイズが16でない場合、HSEはそれをキーハンドルとして扱います。S32N55 HSE2のADKPサイズは16バイト（AES-128）ですか、それとも32バイトですか？ 2. HSE_OTP_FOEM_ADKP_ATTR_ID SetAttribute には、VDD_EFUSE 電源 (J18 ジャンパーまたは VGPIO) が必要ですか？（以前のNXPの回答では、OTPタイプには必要なく、ヒューズボックスタイプにのみ必要であると述べられていました。） 3. S32N55 HSE2では、セキュアADKPプロビジョニング（RAMキースロット＋キーハンドル経由）が推奨される方法ですか？ 「`c」 /* AES-128キーをRAMスロットにインポート */ SecureStorage_CipherKey_Import(RAM_SLOT, pDebugKey, 16U); /* キーハンドルを使用して属性を設定します */ Sherpa_Cdd_SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID, sizeof(hseKeyHandle_t)、 &keyHandle); 「`」 4. 前提条件となる手順はありますか（例：ADKP_MASTERヒューズ設定）をADKPプログラミング前に確認すべき事項で、見落としている可能性のあるものはありますか？ 5. S32N55 で HSE_OTP_FOEM_ADKP_ATTR_ID SetAttribute に使用する正しい MU インスタンスは何ですか？ Re: S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) No Response in Synchronous Mode こんにちは、 HSE_FW_S32N5_1_0_24_0に関する以前のご回答ありがとうございました。 HSE_FW_S32N5_1_0_24_0を使用して再テストを実施しましたので、その結果を共有し、さらに1つ質問をしたいと思います。 --- ## 更新1：ADKPプロビジョニング結果 HSE_FW_S32N5_1_0_24_0にアップグレード後、ADKPプロビジョニングが正常に動作するようになりました。 GetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID)を呼び出すことで、ADKPが正常にプログラムされたことを確認しました。この呼び出しは、SHA3_384参照値とともにE_OKを返します。 以前のタイムアウト/シャットダウンの問題（リリースノートではバージョン1.0.24.0より前のバージョンのバグとして報告されていた）は解決されました。 --- ## アップデート2：通話場所 通話場所も重要であることが分かりました。 SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) は、Fss_Btm_PlatformApi_SetFssCohortState(FSS_BTM_COHORT_RUNNING) の後に呼び出す必要があります。 それを早く呼び出す（例：Crypto_43_HSE_Init の直後に実行したところ、HSE2 から応答がありませんでした。 --- ## 質問: VDD_EFUSE 電源有効化要件 前回のNXPコミュニティの投稿では、次のように述べました。 「OTP属性（HSE_OTP_FOEM_ADKP_ATTR_ID）はVDD_EFUSE電源を必要としません。 ヒューズボックスの操作とは異なります（hseSrvProgFuse_t）。 しかしながら、VGPIO経由でVDD_EFUSEを有効にしようとしたところ、ShutdownHook（バスエラー）が発生したため、この点を再確認したいと思います。 「`c」 VGPIO_Type *pVgpio = (VGPIO_Type *)SECURE_DEBUG_FUSE_VDD_ADDR; pVgpio->OV[SECURE_DEBUG_FUSE_VDD_BANK].PMOS = (1U << SECURE_DEBUG_FUSE_VDD_PIN); pVgpio->OV[SECURE_DEBUG_FUSE_VDD_BANK].OE |= (1U << SECURE_DEBUG_FUSE_VDD_PIN); pVgpio->OV[SECURE_DEBUG_FUSE_VDD_BANK].OVS = (1U << SECURE_DEBUG_FUSE_VDD_PIN); 「`」 質問: 1.S32N55のHSE_OTP_FOEM_ADKP_ATTR_ID SetAttributeでは、VDD_EFUSE電源（J18ジャンパーまたはVGPIO）は本当に不要なのでしょうか？ 2. VDD_EFUSEが不要な場合、なぜADKPのプロビジョニングはFss_Btm_PlatformApi_SetFssCohortState()の後にのみ機能するのでしょうか？ これは電源の問題ではなく、タイミングや初期化の問題でしょうか？ 3. S32N55 EVB の VDD_EFUSE 制御のための正しい VGPIO アドレスとピン構成は何ですか。 他のOTP操作に必要な場合（例：MCK、SRKH）？ よろしくお願いします。 Re: S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) No Response in Synchronous Mode ハイ 早速のご返信ありがとうございます。 HSE_FW_S32N5_1_0_24_0を使用してテストします。 検査結果が出たらまたご連絡します。 Re: S32N55 HSE2 - SetAttribute(HSE_OTP_FOEM_ADKP_ATTR_ID) No Response in Synchronous Mode こんにちは、 @EddiePark さん、 フィードバックをいただきました。驚くほど速かったことを付け加えておきます。S32N5 HSEファームウェア1.0.24.0のリリースノートには、以下の内容が記載されています。 HSE は、OTP ヒューズの SET/GET ATTR を使用して SRKH/ODAK、ADKP、MCK などのキー関連の OTP ヒューズを設定/取得している間にシャットダウンします。 したがって、バージョン1.0.24.0より古いバージョンを使用している場合、これが問題の原因である可能性があります。S32N HSE FWのバージョン1.0.24.0にアクセスするにはライセンスを更新する必要があったため、アカウントにそのバージョン（またはそれ以降のバージョン）が表示されない場合は、NXPの担当者に連絡してアクティベーションを依頼する必要があるかもしれません。 バージョン1.0.24.0以降で再度テストしていただき、動作が変わったかどうかをお知らせください。

I.MX93，A55 boot failure when M33 is initialized from U-boot Hello NXP Engineers, We are attempting to initialize the M33 core from U-Boot on the i.MX93 EVK board, but we are encountering some issues during the process. Below are the steps we followed for M33 initialization. As you can see, the auxiliary core is up and running, and we are able to observe the demo code being executed through the M33 debug port: u-boot=> fatload mmc 0:1 0x98000000 sdk20-app.bin 13680 bytes read in 4 ms (3.3 MiB/s) u-boot=> cp.b 0x98000000 0x201e0000 0x10000 u-boot=> bootaux 0x1ffe0000 0 ## Starting auxiliary core addr = 0x1FFE0000... However, when we attempt to boot the A55 using the "boot" command, we encounter the following failure conditions: [ 1.874795] remoteproc remoteproc0: imx-rproc is available [ 1.880384] remoteproc remoteproc0: attaching to imx-rproc [ 1.885904] Unable to handle kernel paging request at virtual address ffff8000433d3e00 [ 1.893806] Mem abort info: [ 1.896591] ESR = 0x0000000096000005 [ 1.900331] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.905635] SET = 0, FnV = 0 [ 1.908681] EA = 0, S1PTW = 0 [ 1.911814] FSC = 0x05: level 1 translation fault [ 1.916684] Data abort info: [ 1.919553] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 1.925030] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.930079] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.935379] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082031000 [ 1.942069] [ffff8000433d3e00] pgd=10000000fffff003, p4d=10000000fffff003, pud=0000000000000000 [ 1.950763] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 1.957016] Modules linked in: [ 1.960060] CPU: 0 PID: 26 Comm: kworker/u4:1 Not tainted 6.6.23-lts-next-g812033a2bd7c #1 [ 1.968308] Hardware name: NXP i.MX93 11X11 EVK board (DT) [ 1.973779] Workqueue: events_unbound deferred_probe_work_func [ 1.979610] pstate: 00400009 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.986560] pc : rproc_handle_resources.constprop.0+0x64/0x18c [ 1.992384] lr : rproc_boot+0x37c/0x57c [ 1.996206] sp : ffff80008245b9f0 [ 1.999508] x29: ffff80008245b9f0 x28: ffff800081b3e510 x27: ffff00007fbcfb98 [ 2.006632] x26: 0000000000000007 x25: ffff800083610000 x24: ffff8000433d3e00 [ 2.013756] x23: 0000000000000000 x22: ffff000004caa038 x21: ffff800082163798 [ 2.020880] x20: 0000000000000000 x19: ffff000004caa000 x18: 0000000000000006 [ 2.028004] x17: ffff800082109330 x16: 000000009fc9d337 x15: c0ffee00c0ffee00 [ 2.035128] x14: c0ffee00c0ffee00 x13: c0ffee00c0ffee00 x12: c0ffee00c0ffee00 [ 2.042252] x11: c0ffee00c0ffee00 x10: c0ffee00c0ffee00 x9 : c0ffee00c0ffee00 [ 2.049376] x8 : c0ffee00c0ffee00 x7 : c0ffee00c0ffee00 x6 : c0ffee00c0ffee00 [ 2.056500] x5 : ffff0000043ce400 x4 : ffff8000823d5000 x3 : 000000003f0015fc [ 2.063624] x2 : 00000000c0ffee00 x1 : ffff8000433d3e04 x0 : ffff8000823d5000 [ 2.070748] Call trace: [ 2.073185] rproc_handle_resources.constprop.0+0x64/0x18c [ 2.078661] rproc_boot+0x37c/0x57c [ 2.082136] rproc_add+0x144/0x17c [ 2.085525] imx_rproc_probe+0x4d0/0x5e0 [ 2.089433] platform_probe+0x68/0xc8 [ 2.093091] really_probe+0x148/0x2b0 [ 2.096739] __driver_probe_device+0x78/0x12c [ 2.101081] driver_probe_device+0x3c/0x15c [ 2.105250] __device_attach_driver+0xb8/0x134 [ 2.109679] bus_for_each_drv+0x88/0xe8 [ 2.113501] __device_attach+0xa0/0x190 [ 2.117323] device_initial_probe+0x14/0x20 [ 2.121491] bus_probe_device+0xac/0xb0 [ 2.125313] deferred_probe_work_func+0x80/0xb8 [ 2.129829] process_one_work+0x138/0x248 [ 2.133833] worker_thread+0x320/0x438 [ 2.137568] kthread+0x110/0x114 [ 2.140783] ret_from_fork+0x10/0x20 [ 2.144357] Code: 6b020063 8b22c098 91001301 540007c4 (b862c880) [ 2.150431] ---[ end trace 0000000000000000 ]--- We suspect that this is a memory address issue, so we tried reserving the M33 address in the Device Tree Source (DTS) as shown below: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; linux,cma { compatible = "shared-dma-pool"; reusable; alloc-ranges = <0 0x80000000 0 0x40000000>; size = <0 0x10000000>; linux,cma-default; }; ethosu_mem: ethosu_region@C0000000 { compatible = "shared-dma-pool"; reusable; reg = <0x0 0xC0000000 0x0 0x10000000>; }; vdev0vring0: vdev0vring0@a4000000 { reg = <0 0xa4000000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@a4008000 { reg = <0 0xa4008000 0 0x8000>; no-map; }; vdev1vring0: vdev1vring0@a4010000 { reg = <0 0xa4010000 0 0x8000>; no-map; }; vdev1vring1: vdev1vring1@a4018000 { reg = <0 0xa4018000 0 0x8000>; no-map; }; rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x1000>; no-map; }; vdevbuffer: vdevbuffer@a4020000 { compatible = "shared-dma-pool"; reg = <0 0xa4020000 0 0x100000>; no-map; }; ele_reserved: ele-reserved@a4120000 { compatible = "shared-dma-pool"; reg = <0 0xa4120000 0 0x100000>; no-map; }; cm33_reserved: cm33_reserved@1ffe0000 { compatible = "shared-dma-pool"; reg = <0 0x1ffe0000 0 0x10000>; no-map; }; }; Despite these changes, the issue persists. We would greatly appreciate any suggestions or solutions from NXP regarding this problem. Thank you in advance. Best regards, Vinisha. Re: I.MX93，A55 boot failure when M33 is initialized from U-boot @vinisha can you please attach your full dts so that we may check ? Re: I.MX93，A55 boot failure when M33 is initialized from U-boot Hi @vinisha, Have you found a solution for this issues? Thanks!

用于 IMX8MP 中 MJPG 解码的 VPU？ 我有一个 USB 摄像头，它能提供 MJPG（Motion-JPEG，压缩格式）。 我使用的是带有 VPU Hantro 的 IM8MP 在这种情况下，有什么 VPU 函数可以用来解压缩吗？ 本文件简要介绍 https://docs.nxp.com/bundle/RM00294/page/topics/imx_6_vpu_main_features.html 该流水线需要 60% cpu gst-launch-1.0v4l2src 设备=/dev/video2！image/jpeg,width=1280,height=720 ！jpegdec ！imxvideoconvert_g2d ！赝品 有什么 VPU 功能可以帮助我们减少 CPU 占用？ 多媒体 Re: VPU for MJPG decoding in IMX8MP? 你好 joanxie 能否请您指点一二？ 谢谢！ Re: VPU for MJPG decoding in IMX8MP? 你好 甚至当我尝试运行这个 gst-launch-1.0videotestsrc ！imxvideoconvert_g2d ！队伍vpuenc_hevc ！多队列 ！vpudec ！fakesink 将管道设置为 PAUSED ... ====== VPUDEC: 4.10.0版本于 2025 年 11 月 27 日 18:04:02。====== wrapper: 3.0.0(VPUWRAPPER_ARM64_LINUX 版本 on Nov 27 2025 18:03:51) vpulib: 1.1.1 固件： 1.1.1.836202415 ====== vpuenc: 4.10.0版本于 2025 年 11 月 27 日 18:04:02。====== wrapper: 3.0.0(VPUWRAPPER_ARM64_LINUX 版本 on Nov 27 2025 18:03:52) vpulib: 1.1.1 固件： 1.1.1.43690 Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock：GstSystemClock 重新分配延迟... 0:07:59.5 / 99:99:99. 它需要 199% 的 CPU，CPU 是否被使用了？ perf 显示 7.82% libgstvideo-1.0.so.0.2600.0[.] 0x00000000000219e4 6.63% libhantro_vc8000e.so.1 [.] EncAsicFrameStart 5.76% libgstvideo-1.0.so.0.2600.0[.] 0x00000000000219f8 5.49% [k] DecRefreshRegs 3.92% libgstvideo-1.0.so.0.2600.0[.] 0x00000000000219e0 3.89% libgstvideo-1.0.so.0.2600.0[.] 0x00000000000219f0 3.89% libgstvideo-1.0.so.0.2600.0[.] 0x0000000000021a00 3.05% libhantro.so.1 [.] SwShowBits 2.94% [kernel] [k] DecFlushRegs.isra.0 2.69% libgstvideo-1.0.so.0.2600.0[.] 0x00000000000219ec 1.45% libc.so.6 [.] 0x00000000000a3194 1.23% libc.so.6 [.] 0x00000000000a3188 1.21% orcexec.0La54a (deleted) [.] 0x0000000000000040 1.19% libgstvideo-1.0.so.0.2600.0[.] 0x00000000000219e8 1.16% libhantro.so.1 [.] DWLPrivateAreaReadByte 0.80% libhantro_vc8000e.so.1 [.] VCEncStrmEncodeExt 0.77% orcexec.0La54a (deleted) [.] 0x0000000000000044 0.69% orcexec.0La54a (deleted) [.] 0x0000000000000038 0.56% libhantro.so.1[.] SwFlushBits 0.53% [k] _raw_spin_unlock_irqrestore 0.48% libgstvideotestsrc.so [.] 0x0000000000008450 0.48% libgstvideotestsrc.so [.] 0x0000000000008448 0.46% libc.so.6[.] 0x00000000000a3184 0.46% libhantro_vc8000e.so.1 [.] EncAsicGetRegisterValue 0.46% libc.so.6 [.] 0x00000000000a318c 0.45% orcexec.0La54a (deleted) [.] 0x0000000000000034 0.35% libhantro.so.1 [.] FlushDecRegisters 0.34% libhantro.so.1 [.] RefreshDecRegisters 0.33% [k] [k] el0_svc 0.32% libgobject-2.0.so.0.8400.4[.] g_type_check_instance_is_fundamentally_a 0.32% libhantro.so.1 [.] HevcDecDecode 0.31% libhantro.so.1 [.] SetDecRegister 0.30% orcexec.0La54a (deleted) [.] 0x000000000000012c 不确定是否使用了 VPU。如何确认？ lsof | grep hantro gst-launc 1516 root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 root 15u CHR 510,0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 root 31u CHR 511、0 0t0 161 /dev/mxc_hantro gst-launc 1516 1517 gst-launc root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1517 gst-launc root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1517 gst-launc root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1517 gst-launc root 15u CHR 510、0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1517 gst-launc root 31u CHR 511,0 0t0 161 /dev/mxc_hantro gst-launc 1516 1518 gst-launc root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1518 gst-launc root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1518 gst-launc root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1518 gst-launc root 15u CHR 510、0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1518 gst-launc root 31u CHR 511,0 0t0 161 /dev/mxc_hantro gst-launc 1516 1519 pool-spaw root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1519 pool-spaw root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1519 pool-spaw root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1519 pool-spaw root 15u CHR 510、0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1519 pool-spaw root 31u CHR 511,0 0t0 161 /dev/mxc_hantro gst-launc 1516 1520 multiqueu root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1520 multiqueu root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1520 multiqueu root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1520 multiqueu root 15u CHR 510,0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1520 multiqueu root 31u CHR 511,0 0t0 161 /dev/mxc_hantro gst-launc 1516 1521 queue0：sr root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1521 queue0:sr root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1521 queue0:sr root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1521 queue0:sr root 15u CHR 510,0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1521 queue0：sr root 31u CHR 511,0 0t0 161 /dev/mxc_hantro gst-launc 1516 1522 videotest root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1522 videotest root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1522 videotest root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1522 videotest root 15u CHR 510,0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1522 videotest root 31u CHR 511,0 0t0 161 /dev/mxc_hantro gst-launc 1516 1523 gmain root mem REG 179,1 224656 2117 /usr/lib/libhantro.so.1 gst-launc 1516 1523 gmain root mem REG 179,1 353928 2322 /usr/lib/libhantro_vc8000e.so.1 gst-launc 1516 1523 gmain root mem CHR 510,0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1523 gmain root 15u CHR 510,0 0t0 162 /dev/mxc_hantro_vc8000e gst-launc 1516 1523 gmain root 31u CHR 511,0 0t0 161 /dev/mxc_hantro Re: VPU for MJPG decoding in IMX8MP? 你好@jake4 希望你一切都好。 请尝试以下管道： gst-launch-1.0 v4l2src device=/dev/video2 ! image/jpeg,width=1280,height=720 ! v4l2jpegdec ! imxvideoconvert_g2d ! fakesink 不建议使用 videotestsrc. 这是一个纯软件生成器。它使用 CPU 来创建测试图案的每个像素。 顺祝商祺！ 萨拉斯 Re: VPU for MJPG decoding in IMX8MP? 嗨 @Manuel_Salas 收到这个 gst-launch-1.0v4l2src 设备=/dev/video3！image/jpeg,width=1280,height=720 ！v4l2jpegdec ！imxvideoconvert_g2d ！fakesink WARNING: erroneous pipeline: no element "v4l2jpegdec" Thanks gst-inspect-1.0 | grep v4l2 video4linux2: v4l2convert: V4L2 Video 变流器 video4linux2: v4l2deviceprovider (GstDeviceProviderFactory) video4linux2: v4l2h264dec: V4L2 H264 Decoder video4linux2: v4l2h264enc: V4L2 H.264 Encoder video4linux2: v4l2h265dec: V4L2 H265 Decoder video4linux2: v4l2h265enc: V4L2 H.265 Encoder video4linux2: v4l2radio: Radio (video4linux2) Tuner video4linux2: v4l2sink: Video (video4linux2) Sink video4linux2: v4l2src: Video (video4linux2) Source video4linux2: v4l2vp8dec: V4L2 VP8 Decoder video4linux2: v4l2vp9dec: V4L2 VP9 Decoder Re: VPU for MJPG decoding in IMX8MP? 你好@Manuel_Salas 我使用的是 IMX8MPlus，它支持 jpeg VPU 解码吗？ 谢谢！ Re: VPU for MJPG decoding in IMX8MP? 有没有其他建议的方法来实现这一目标？ 我们有一个 USB 摄像头，它能提供 MPJG 压缩图像，我们需要用硬件加速来处理它，以避免 CPU 负载，有什么建议吗？ Re: VPU for MJPG decoding in IMX8MP? 你好@jake4 请尝试以下方法： $ gst-launch-1.0 v4l2src device=/dev/video3 ! image/jpeg,width=1280,height=720 ! jpegparse ! vpudec ! imxvideoconvert_g2d ! fakesink vpudec 使用 Hantro VPU。 如果这对你有用，请告诉我。 顺祝商祺！ 萨拉斯 Re: VPU for MJPG decoding in IMX8MP? 你好@Manuel_Salas 运行时会出现如下错误。 gst-launch-1.0v4l2src 设备=/dev/video2！image/jpeg,width=1280,height=720 ！jpegparse ！vpudec ！imxvideoconvert_g2d ！fakesink 警告：管道错误：无法将 jpegparse0 链接到 vpudec0 gst-inspect-1.0 vpudec 显示如下，看来它无法处理 jpeg 图像 谢谢！ 工厂详情： 等级 二级 (128) 长名 基于 IMX VPU 的视频解码器 Klass 编解码器/解码器/视频 描述 将压缩视频解码为原始数据 作者 多媒体团队 插件详情： 名称 vpu 说明 VPU 视频编解码器 文件名 /usr/lib/gstreamer-1.0/libgstvpu.so 版本 4.10.0 许可证 LGPL 源模块 imx-gst1.0-plugin 二进制包 Freescle Gstreamer 多媒体插件起源 URL http://www.freescale.com GObject +----GInitiallyUnowned +----GstObject +----GstElement +----GstVideoDecoder +----GstVpuDec 元素标志： 焊盘模板： SINK 模板：'sink' 可用性：始终 功能： 视频/x-h265 视频/x-vp9 视频/x-vp8 视频/x-h264 SRC 模板：'src' 可用性：Always Capabilities: video/x-raw format：{ (string)NV12, (string)I420, (string)YV12, (string)Y42B, (string)NV16, (string)Y444, (string)NV24, (string)NV12_10LE } width: [ 1, 2147483647 ] height: [ 1, 2147483647 ] framerate：[ 0/1, 2147483647/1 ]

s32 design studio 没有 3.5 版本 您好， ，我需要 s32 design studio 3.5，但在搜索时，3.6 和 3.4 版本清晰显示，而 3.5 版本却没有出现在我的账户中。 它确实出现在另一个人的账户中。 我该怎么办？ Re: There is no version 3.5 of s32 design studio HI 只有以前可以访问 S32DS 3.5 的用户才能看到它。 新用户将不再自动看到 S32DS 3.5。 如果需要，这里有 S32DS 3.5 的下载链接： https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=S32DS-3-5 顺便问一下，客户为什么不使用最新的 S32DSv3.6.6？ 我在 " S32 Design Studio 3.6.0 发布公告 " 中看到了以下信息： 旧版 S32Design Studio 3.5.x 附带的 开发、附加组件和扩展包与 3. 6.0 版本兼容 在 S32Design Studio 3.5.x 之上发布的 RTD 和运行时软件版本使用智能兼容机制向后兼容 S32Design Studio 3.6.0 祝好， Robin ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------

Inquiry regarding T2080 Boot Flash settings Dear friends, I'm using T2080 + VxWorks bootloader + NOR boot flash (tACC=120ns, tOE=35ns). When powering on, it intermittently boots only up to bootlaoder (unable to load vxworks kernel). I am using a TRAD_NOR of 97ns for the T2080 CPU's IFC_FTIM1. I think it fully satisfies the NOR flash's tOE(35ns). 1. Do I need to modify TRAD_NOR to satify the tACC(120ns)? 2. When accessing NOR boot (tACC=120ns, tOE=35ns) from the T2080(ifc_clk=11.5ns), could you please tell me the frequently configured IFC_FTIM0~3 values and known precautions? Thank you in advance for your answer. QorIQ T2 Devices Re: Inquiry regarding T2080 Boot Flash settings Please kindly share the NOR Flash timing sequence diagram for tOE and tACC, or the corresponding NOR datasheet. If possible, please also indicate the page numbers where these parameters are specified. Thank you. Re: Inquiry regarding T2080 Boot Flash settings Thank you for your reply. I'm using S29GL01GT from cypress. tACC=120ns (max) and tOE=35ns(max), tCE=120ns(max). Re: Inquiry regarding T2080 Boot Flash settings Thanks June-Lu TACO is using 11 cycles and I have confirmed that the address prior to the CS has stabilized.  It appears to satisfy the requirements listed in the datasheet, but intermittemnt boot errors are still occurring. When I inquire withAO tools like ChatGPT, they suggest that TRAD must satisfy tACC+delay(affected by temperature, etc.). What are your thoughts on this? And, Could you tell me the T2080 boot loader settings commonly used, such as u-boot? (IFC_FTIM0/1 settings and boot flash model) Thank you. Re: Inquiry regarding T2080 Boot Flash settings Would you kindly confirm your IFC module input clock?  According to the T2080 Reference Manual (Figure 4-3), it is ip_clk, which is 1/2 of the platform clock. The valid range of the platform clock is listed in the datasheet (Table 121), and it depends on your configuration. Could you please check whether IFC_CLK is the same as ip_clk? I checked the T1023RDB platform using the S29GL01GS (although it is NO-ADM). It is very similar to S29GL01GT, and its timing configuration can be used as an initial reference.  On this platform, the platform clock is configured to 400 MHz:  https://github.com/nxp-qoriq/u-boot/blob/LSDK-1703/include/configs/T102xRDB.h#L328 Regarding additional delays (for example, those affected by temperature), you may refer to the QorIQ T2080 Datasheet, Figures 20 and 21, which show a maximum output delay of 2.5 ns and a minimum output hold time of –2 ns. When tACO and tRAd are configured, the actual CE_B and OE_B timing will be longer than the programmed values by at least 0.5 ns. Even considering variations due to temperature and layout, 3 × 11.5 ns = 34.5 ns compared with the 23 ns requirement still provides sufficient margin. You may also refer to the T2080 Reference Manual, Section 13.4.2 (Programming Model for Flash Interface Timing), which allows adding one more IFC module input clock cycle to further enlarge the margin. In any case, it is recommended to verify the waveform using an oscilloscope to confirm that the timing meets the requirements. You could set the waveform and IFC registers setting to further checking. Re: Inquiry regarding T2080 Boot Flash settings Thanks June-Lu, I'm using clock as below.  - Platform clock: 533.33Mhz  - ip_clk :  266.66Mhz (IFC module input clock)  - IFC_CLK : 88.88Mhz (IFC external clock) Looking at the reference data you provided (T102xRDB.h), TRAD is set to 0x1A. It's platform clock is 400Mhz, then ip_clk is 200Mhz, so I extimate that TRAD = 5ns * 26(0x1A) = 130ns. In other words, it appears that TRAD is designed to satisfy the Flash's tACC(120ns) rather than tOE(35ns) Re: Inquiry regarding T2080 Boot Flash settings Please confirm the definitions of TACC and TOE. I checked the S29GL01GT datasheet I have. According to it, TACC is the address-to-output delay, tCE is the chip enable–to-output delay, and tOE is the output enable–to-output delay. Are these definitions the same as in your datasheet? Regarding Figure 17, is it the same as the one shown below? Figure 17.png Re: Inquiry regarding T2080 Boot Flash settings Dear June-Lu, I checked my datasheet again, and it is the same. Re: Inquiry regarding T2080 Boot Flash settings The T2080 RM formula for TRAD_NOR explicitly uses TOEmax plus 2*Board Delay plus setup time. It's related to the tOE. tACC/tCE should be checked against the combined path tACO + tRAD, not against TRAD_NOR alone. The parameters in the T102xRDB.h will leave enough margins to access the board. You could using all the setting to check if it could solve your issue, if it could solve your problem, then you could adjust your parameters per the RM and datasheet. Any further question, please kindly share the waveform and all IFC registers setting. Re: Inquiry regarding T2080 Boot Flash settings Dear June-Lu, I am still curious why set TRAD to 130ns (greater than tACC) in the u-boot code, but your answer was very helpful. Thank you for your help. Re: Inquiry regarding T2080 Boot Flash settings Setting TRAD to 130 ns is recommended to provide sufficient margin. However, you may also test a smaller value, such as 97 ns, which is expected to work. Please kindly keep me updated on your results. Thanks.

PFE L2ブリッジにおけるポートベースVLAN（PVID）マッピングとタグなし外部トラフィックのサポート 1. 環境 プラットフォーム: S32G3 ソフトウェア: * NXP RTD: SW32G_RTD_4.4_5.0.0_QLP04 * PFEファームウェア：1.12.0 * ツール: libfci_cli PFEはVLAN_BRIDGEモードで動作しています。 --- 2. 目標 外部トラフィックはすべてタグなしで保持しつつ、ポートベースのVLANアイソレータはPFE内部でのみ実装したいと考えています。 望ましい動作: 「`」 emac0 ↔ hif0 (内部VLAN 10) emac1 ↔ hif1 (内部VLAN 20) emac2 ↔ hif2 (内部VLAN 30) 「`」 つまり、 * 外部PCはVLANタグなしでフレームを送受信する * VLANは、ポートベースのトラフィック分離のためにPFE内部でのみ使用されます。 * 目的は、マスター/スレーブアーキテクチャにおける不要なブロードキャスト/フラッディングを防止することです。 --- 3. 現在の構成 VLANとブリッジドメインは以下のように設定されます。 主なコマンド: 「`sh # ブリッジドメインとインターフェースの設定 libfci_cli bd-add --vlan 10 libfci_cli bd-add --vlan 20 libfci_cli bd-add --vlan 30 libfci_cli bd-update --vlan 10 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD libfci_cli bd-update --vlan 20 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD libfci_cli bd-update --vlan 30 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD libfci_cli bd-insif --vlan 10 --i hif0 --tag OFF libfci_cli bd-insif --vlan 10 --i emac0 --tag OFF libfci_cli bd-insif --vlan 20 --i hif1 --tag OFF libfci_cli bd-insif --vlan 20 --i emac1 --tag OFF libfci_cli bd-insif --vlan 30 --i hif2 --tag OFF libfci_cli bd-insif --vlan 30 --i emac2 --tag OFF # PHYインターフェースモード設定 libfci_cli phyif-update --i emac0 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i emac1 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i emac2 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i hif0 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i hif1 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i hif2 -E --promisc ON --mode VLAN_BRIDGE libfci_cli bd-stent-add --vlan 10 --mac --i hif0 libfci_cli bd-stent-update --vlan 10 --mac --egress hif0 libfci_cli bd-stent-add --vlan 20 --mac --i hif1 libfci_cli bd-stent-update --vlan 20 --mac --egress hif1 libfci_cli bd-stent-add --vlan 30 --mac --i hif2 libfci_cli bd-stent-update --vlan 30 --mac --egress hif2 「`」 要約すると： - 各VLAN（10/20/30）には、emac/hifのペアが割り当てられます。 - すべてのトラフィックは外部からタグ付けされません - VLANは内部分離のみに使用されます   4. 問題 タグなしフレームが外部から到着した場合（例：PC → ping）、各ドメインのイングレスカウンタはゼロのままです。 「`」 ドメイン10イングレス: 0 ドメイン10イングレス: 0 ドメイン20 イングレス: 0 「`」 つまり、タグなしフレームは内部VLANにマッピングされないため、意図したポートベースの分離が機能しない。 # libfci_cli bd-print ドメイン01 [デフォルト] phyifs (タグ付き): --- phyifs (タグなし): --- ucast-hitアクション：3（破棄） ucast-miss アクション : 3 (破棄) mcast-hitアクション：3（破棄） mcast-miss アクション : 3 (破棄) 侵入者数：4173人 受信バイト数：560619 出口：958 送信バイト数：234538 ドメイン00 [フォールバック] phyifs (タグ付き): --- phyifs (タグなし): --- ucast-hitアクション：3（破棄） ucast-miss アクション : 3 (破棄) mcast-hitアクション：3（破棄） mcast-miss アクション : 3 (破棄) 侵入: 0 受信バイト数：0 出口: 0 送信バイト数：0 ドメイン10 phyifs (タグ付き): --- phyifs (タグなし): emac0、hif0 ucast-hit アクション: 0 (前方) ucast-miss action : 1 (FLOOD) mcast-hit アクション: 0 (前方) mcast-miss アクション : 1 (FLOOD) 侵入: 0 受信バイト数：0 出口: 0 送信バイト数：0 ドメイン20 phyifs (タグ付き): --- phyifs (タグなし): emac1、hif1 ucast-hit アクション: 0 (前方) ucast-miss action : 1 (FLOOD) mcast-hit アクション: 0 (前方) mcast-miss アクション : 1 (FLOOD) 侵入: 0 受信バイト数：0 出口: 0 送信バイト数：0 ドメイン30 phyifs (タグ付き): --- phyifs (タグなし): emac2、hif2 ucast-hit アクション: 0 (前方) ucast-miss action : 1 (FLOOD) mcast-hit アクション: 0 (前方) mcast-miss アクション : 1 (FLOOD) 侵入: 0 受信バイト数：0 出口: 0 送信バイト数：0 コマンドは正常に実行されました。 --- 5. 質問 外部トラフィックをタグ付けせずに、PFE内部でのみVLANベースのアイソレータを実現することは可能ですか？ * タグなし入力フレームをポートごとに特定の VLAN にマッピングします (PVID 機能) * VLANはPFE内部でのみ使用されます * 外部デバイスはVLANタグなしで動作します 言い換えると、 「`」 入力（タグなし）→ VLAN 10 → 出力（タグなし） 入力（タグなし）→ VLAN 20 → 出力（タグなし） 入力（タグなし）→ VLAN 30 → 出力（タグなし） 「`」 これは望ましい動作です。 1. PFEはポートベースのVLANをサポートしていますか？ 2. はいの場合、どのファームウェア機能または設定でそれが可能になりますか？ 3. これは、fwfeat-print に表示される vlan_conf または ingress_vlan 機能に関連していますか？ Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge こんにちは、 詳しい説明をありがとうございました。 「3. 現在の構成」 で説明したLinuxコマンドが、 根本的にサポートされていない構成を表しているのか、あるいは私の側に何らかの構成上の不足があるのかどうかを確認したいと思います。 私の現在のテスト環境は以下のとおりです。 • パソコン1台 • このPCには3つのNICが搭載されています ・各NICはボードのEMACポートのいずれかに直接コネクテッドされています。   PC側では、 VLANインターフェースの設定は一切行っていません。単に通常のpingを送信しているだけです。   私が期待する動作は以下のとおりです。 PCがpingを送信すると、ボードは宛先IPアドレスと対応するブリッジドメイン（BD）に基づいてパケットを転送し、そのVLANに属するポートに送信する必要があります。   私が実現したい構成は以下のとおりです。 VLAN10：HIF0、EMAC0 VLAN20：HIF1、EMAC1 VLAN30：HIF2、EMAC2 VLAN40：HIF3、EMAC0、EMAC1、EMAC2 言い換えると： • EMAC0/1/2 はそれぞれ専用の VLAN (10/20/30)にコネクテッドです。 • 同時に、 HIF3 と通信する 共有 VLAN40 にも参加します 。   現在のLinuxコマンドでは： • すべてのポートを VLAN1 に設定すると 、すべてが期待どおりに動作します。 • しかし、それらを VLAN10/20/30 に分割すると 、 入力/出力カウンターは VLAN1 でのみ増加し 、VLAN10/20/30 では増加しません。   そこで、私には2つの質問があります。 1. このタイプのVLAN構成はPFE VLAN_BRIDGEモデルでサポートされていますか？それとも、私が何か設定手順を見落としているのでしょうか？ 2. 現在、PC はタグなしパケット (通常の ping)を送信しています。 このCASE、PFEが受信トラフィックを特定のVLAN BDに分類することは不可能なのでしょうか？ つまり、この設定ではPCがVLANタグ付きパケットを送信する必要があるのでしょうか？ 例えば、タグ付きトラフィックを送信するには、PCをこのように設定すべきでしょうか？   ip link add link eth0 name eth0.40 type vlan id 40 ip link set eth0.40 up ping -I eth0.40 192.168.xx   この構成が実現可能かどうか、あるいはこのシナリオに適した推奨されるアプローチがあるかどうかについて、ご助言いただければ大変ありがたいです。   よろしくお願いします。 Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge こんにちは、 @minJ さん。 私の回答は以下のとおりです。 外部トラフィックをタグ付けせずに、PFE内部でのみVLANベースのアイソレータを実現することは可能ですか？ ドキュメントを見る限り、いいえ、タグなしの外部トラフィックはCAN使用できず、内部トラフィックではVLANタグのみを使用できます。ポートをBD（ブリッジドメイン）に設定すると、デフォルトBD、フォールバックBD、標準BDの3つの動作モードがあります。いずれの場合も、特定のルールに基づいてVLANがチェックされ、フレームを受け入れるか破棄するかが決定されます。PFE-SW_S32G_FCI_API_ReferenceManual_2.7.0の「L2 ブリッジ VLAN 認識とドメイン」のセクションを参照してください。これらの規則の詳細については、こちらをご覧ください。 PFEはポートベースのVLANをサポートしていますか？ 直接はできません。VLANごとに異なるBDを作成し、各ポートをそれぞれのドメインに設定する必要があります。要約すると、BDベースのVLANを設定でき、各BDは異なるポートを使用します。上記で言及した文書の該当箇所をご確認ください。 はいの場合、どのファームウェア機能または設定でそれが可能になりますか？ これは、他の2つの質問からの情報に基づいて回答されるべきです。 これは、fwfeat-printに表示されるvlan_confまたはingress_vlan機能に関連していますか？ vlan_conf_check のことであれば、どちらもこのトピックに関連していますが、これらのオプションを有効化/設定すると、VLAN を含まないフレームが破棄されるようにポートが設定されます。 マスタースレーブ構成でのフラッディングを回避するための解決策としては、そのモードの使用を避け、代わりにIPCFを使用してフレームを他のドメインに転送することが考えられます。たとえば、M7_0がPFEの所有者である場合、一部のフレームのみをA53/Linuxドメインに転送します。ご要望によっては、これは有効な選択肢となり得ます。このアイデアについてさらに詳しい説明が必要な場合はお知らせください。 他に質問があればお知らせください。 Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge こんにちは、 @minJ さん。 3. 現在の構成について言及している文書はどれですか？ PFE Linux ドキュメントのすべての文書を確認しましたが、そのセクションは見つかりませんでした。該当箇所のページ番号と文書の改訂版番号を明記してください。 VLANポートにおけるタグなしパッケージの分類に関して、以前のドキュメントを誤解していました。そのためには、BDをデフォルト設定で構成する必要があります。その説明は以下のとおりです。 デフォルトのBD: このブリッジドメインの工場出荷時のデフォルトVLAN IDは1です。このドメインは、デフォルトのBD VLAN IDと同じVLANタグを持つ入力フレーム、またはVLANタグがまったくない入力フレーム（タグなしイーサネットフレーム）を処理します。 これはタグなしフレームを処理できる唯一のBD構成です。したがって、この構成ではホストからタグ付きメッセージを送信する必要はありません。さらに、他のタイプのBDはVLANタグのないフレームを処理しません。 先ほどは混乱させてしまい、申し訳ありませんでした。他に質問があれば教えてください。 Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge こんにちは、 「3.私が言及した「現在の構成」とは、最初の質問で述べたLinuxコマンドのことです。 この点をもっと早く明確にしておかなかったことをお詫び申し上げます。 # ブリッジドメインとインターフェースの設定 libfci_cli bd-add --vlan 10 libfci_cli bd-add --vlan 20 libfci_cli bd-add --vlan 30 libfci_cli bd-update --vlan 10 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD libfci_cli bd-update --vlan 20 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD libfci_cli bd-update --vlan 30 --ucast-hit FORWARD --ucast-miss FLOOD --mcast-hit FORWARD --mcast-miss FLOOD libfci_cli bd-insif --vlan 10 --i hif0 --tag OFF libfci_cli bd-insif --vlan 10 --i emac0 --tag OFF libfci_cli bd-insif --vlan 20 --i hif1 --tag OFF libfci_cli bd-insif --vlan 20 --i emac1 --tag OFF libfci_cli bd-insif --vlan 30 --i hif2 --tag OFF libfci_cli bd-insif --vlan 30 --i emac2 --tag OFF # PHYインターフェースモード設定 libfci_cli phyif-update --i emac0 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i emac1 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i emac2 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i hif0 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i hif1 -E --promisc OFF --mode VLAN_BRIDGE libfci_cli phyif-update --i hif2 -E --promisc ON --mode VLAN_BRIDGE libfci_cli bd-stent-add --vlan 10 --mac --i hif0 libfci_cli bd-stent-update --vlan 10 --mac --egress hif0 libfci_cli bd-stent-add --vlan 20 --mac --i hif1 libfci_cli bd-stent-update --vlan 20 --mac --egress hif1 libfci_cli bd-stent-add --vlan 30 --mac --i hif2 libfci_cli bd-stent-update --vlan 30 --mac --egress hif2 私が書いた Linux コマンドは、次のドキュメントに基づいています: LNX PFE ドライバ ユーザー マニュアル (Rev.25.0) PFE FCI API リファレンス (Rev.2.7.0) p144。 あなたの回答によると、上記のLinuxコマンドのようにL2ブリッジとVLANを設定した場合、PCから送信されるタグなしパケットは処理できないということでしょうか？ 静的MACアドレスを指定した場合でも、タグなしパケットがVLANメンバー（HIF、EMAC）によって処理されないかどうかを知りたいです。 さらに、VLANタグなしで（つまり、タグなしパケットとして）パケットをPCに転送することが可能かどうかについても興味があります。 ありがとう。 Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge こんにちは、 @minJ さん。 返信が遅くなり申し訳ありません。現在、業務が多忙なため、問題の分析にもう少し時間が必要です。 ご辛抱いただきありがとうございます。 Re: Port-based VLAN (PVID) Mapping and Untagged External Traffic Support in PFE L2 Bridge こんにちは、 @minJ さん。 大変お待たせして申し訳ございませんでした。「上記のLinuxコマンドのようにL2ブリッジとVLANを設定した場合、PCから送信されるタグなしパケットは処理できないということでしょうか？ 」という質問にお答えします。直接的な回答を見つけることができませんでしたが、使用しているコマンドを比較すると、主な違いは、Linux PFE ドキュメントでは VLAN 1 が使用されていることです。これはデフォルトの BDであり (削除できないことに注意してください)、この VLAN は ID 1 または VLAN タグのないすべてのメッセージをキャッチします。明示的には、試みている構成がサポートされていないとは述べられていませんが、デフォルトのBDのみがタグなしフレームを処理でき、標準BDは一致するIDを持つタグ付きフレームのみを取得するため、そのように考えられます。 社内ドキュメントをいくつか調べてみたところ、デフォルトのBDは1つしかなく、別のBDを作成するオプションがないことがわかりました。このユースケースに対する推奨される回避策は、ポートごとに異なるマルチキャストアドレスを使用することです。これが現実的な解決策ではない可能性は承知していますが、言及する価値はあると思います。 重ねてお待たせして申し訳ありませんでした。 他に質問があれば教えてください。

U4N-如何设置 Aion 2 私人服务器进行测试 为什么要设置私人服务器？ 私人服务器可让您完全控制游戏环境。你可以 在没有时间压力的情况下，测试班级技能、轮换和连击。 尝试装备升级或强化。 反复运行 PvP 或 PvE 场景。 通过观察受控环境中的行为，更快地学习游戏机制。 对于许多玩家来说，这尤其有助于他们尝试在官方服务器上有风险或昂贵的策略。 开始前的准备工作 在建立私人服务器之前，您需要做好以下准备： 体面的电脑 私人服务器可以在本地运行，但性能取决于 CPU 和内存。配备至少 8GB 内存和现代 CPU 的中档机器足以进行小规模测试。 Aion 2 客户端副本 您需要游戏客户端来连接服务器。确保它与您计划运行的服务器版本一致。 服务器文件 Aion 2 的私人服务器文件经常在社区论坛中共享。查找明确标注用于测试或开发的版本。避免未知来源，降低恶意软件风险。 数据库软件 大多数私人服务器使用 MySQL 或 MariaDB 来存储游戏数据。您需要安装和配置其中一个数据库。 基本网络知识 你不需要成为一名网络工程师，但了解端口、IP 地址和防火墙的工作原理非常重要。客户端必须可以连接到服务器。 步骤 1：安装服务器软件 拿到服务器文件后，第一步就是安装： 提取文件将它们 放在计算机上的专用文件夹中。避免使用系统目录，以减少潜在冲突。 配置服务器设置 打开配置文件。最重要的设置包括 IP 地址：将其设置为本地计算机的 IP 或 127.0.0.1（仅用于本地测试）。 端口号：确保这些端口空闲。典型的 Aion 2 端口通常都包含在文档中。 数据库连接：输入数据库用户名、密码和数据库名称。 运行安装脚本 许多私有服务器包都附带用于初始化数据库的脚本。运行这些操作可创建必要的表格和默认数据。 启动服务器 执行服务器程序。监测控制台是否有任何错误消息。常见问题包括数据库凭证错误或端口已在使用中。 步骤 2：连接客户端 服务器运行后，您需要告诉您的 Aion 2 客户端与其连接。 修改客户端配置 查找配置文件，通常命名为 Aion2.ini 或类似文件。将服务器 IP 更改为您的私人服务器使用的 IP。 测试连接 启动游戏客户端并登录。如果遇到连接错误，请检查防火墙设置并确保服务器正在运行。 创建测试账户 在私人服务器上，您可以创建无限账户进行测试。使用这些账户来尝试不同的版本和装备设置。 步骤 3：使用服务器进行测试 连接后，您就可以开始使用服务器进行任何测试，而不会产生任何后果。一些实用的方法包括 技能轮换测试：运行假人或小怪来测量技能时机和伤害输出。 齿轮实验：测试不同的齿轮组合和升级。许多玩家还会模拟市场，查看物品对游戏进程的影响。 经济模拟：有些玩家喜欢模拟贸易、手工艺和基纳积累。如果您想测试 kinah 获取策略，私人服务器是最佳选择，因为您可以模拟大规模交易、物品种植，甚至使用 Aion 2 kinah 快速交付功能等快捷方式进行受控实验。 步骤 4：常见问题和解决方案 即使是经验丰富的玩家也会遇到常见问题。下面是几个问题及解决方法： 服务器崩溃：通常是由于服务器文件过时或不匹配造成的。确保服务器文件与客户端版本完全一致。 数据库错误：检查凭证和数据库名称。有时会丢失表结构；请重新运行初始化脚本。 延迟或性能缓慢：减少同时在线玩家或 NPC 的数量，并确保电脑符合推荐的规格。 连接问题：验证 IP 地址，在防火墙中打开端口，并确认客户端配置与服务器设置相匹配。 步骤 5：维护服务器 即使是测试，正确维护服务器也是非常有用的： 经常备份：定期备份数据库，避免丢失进度。 谨慎更新服务器文件：如果您下载了更新的版本，请在将其应用到主测试环境之前对其进行单独测试。 记录更改：记录对设置、技能或数据库所做的任何修改。这有助于排除意外行为的故障。 法律和道德方面的考虑 重要的是要记住，私人服务器存在于灰色地带。它们只能用于个人测试和学习，不得用于公开传播或商业目的。避免将私人服务器连接到官方账户，以保护您的数据并遵守游戏的服务条款。 建立一个私人 Aion 2 服务器是一种有效的学习和测试方法，而不会给您的主账户带来风险。按照这些步骤--准备正确的工具、安装服务器文件、配置客户端和维护服务器--您就可以安全地尝试使用技能、装备和游戏中的策略。对于对实际测试感兴趣的玩家来说，即使是像经济模拟这样复杂的过程，也可以在受控环境中进行处理，包括尝试有效管理游戏内货币的概念，如 Aion 2 kinah 快速交付。 私人服务器不仅有助于测试，还有助于更深入地了解游戏。只要有耐心、精心设置并注重细节，您就能在 Aion 2 中创造出改进游戏的宝贵工具。

UART プロトコル テスト MCXN546VKL で、while (0U == (base->STAT & LPUART_STAT_TDRE_MASK)) で停止しました。 こんにちは。私は NXP の初心者です。IoT モジュールへの UART PIO8 および PIO9 ピンを備えた MCXN546VKL PCB を使用して、MCUXpresso IDE で LPUART プロトコルをテストしようとしています。その前に、UART ポーリングと DMA の TX および RX 機能をテストしようとしています。ポーリングモードのシンプルなループバックUARTテストで、UART TX経由でサンプルデータを送信しようとすると、fsl_lpuart.cファイルの「while (0U == (base->STAT & LPUART_STAT_TDRE_MASK))」で停止してしまいます。FLEXCOMM4に12MHz、システムクロックに150MHzを指定しているのですが、なぜこのようなことが起こるのでしょうか。設定のスクリーンショットの.pngファイルをこの投稿に添付しましたので、ご確認の上、詳細をお知らせください。ありがとうございます。 clock_config.png クロック|タイマー 通信と制御（I3C | I2C | SPI | FlexCAN | イーサネット | FlexIO） 開発ボード MCX N 回复： In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Elakiya   MCXN デバイスでは、UART モジュールが実際にクロックされ、TX FIFO レベルが構成された TX ウォーターマーク以下の場合にのみ、TDRE ビットが 1 になります。 Snipaste_2026-03-06_15-54-56.png FlexComm クロックを有効にしていただいてもよろしいでしょうか? mcxn547 sdk lpuart デモを参照できると思います。 Snipaste_2026-03-06_15-57-57.png   BR ハリー 回复： In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Harry_Zhang 、私は MCXN546VKL PCB ボードを持っていますが、あなたの指示に従って、MCXN547V の SDK からの LPUART ポーリングのサンプル ファイルを使用して、uart ピンの同じピン PIO8 と PIO9 を使用し、clock_config.c 内でプロセッサのGlobalInfoと package_id を MCXN456VKL に手動で変更しました。そして pin_mux.c。 プロセッサ: MCXN546 パッケージID: MCXN546VKL プロジェクトをビルドすると、エラーは発生せず、UART ポーリング操作の送受信は正常に行われますが、それでもピン構成設定内でエラー通知が表示されます。問題ツール: MCUconfiguration に表示される通知とエラーの問題のスクリーンショットを共有しました。 構成ページからエラー通知を削除するには、構成でプロセッサ設定も MCXN547 から MCXN546 に変更して、エラーをすばやく修正するにはどうすればよいですか。スクリーンショットを確認し、解決策を更新してください。前もって感謝します。 processorNotification.png error_chip.png 回复： In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Elakiya あなたの以前の投稿を確認しました。 clock_config.c 内のプロセッサの GlobalInfo と package_id を MCXN456VKL に手動で変更しました。および pin_mux.c。 プロセッサ: MCXN546 パッケージID: MCXN546VKL" この方法は間違っているため、エラーが報告されます。現時点では、このエラーを防ぐ方法はありません。 まず、MCXN546とMCXN547は、GPIOの数とフラッシュRAMのサイズ以外はほとんど同じです。 上記のメッセージに基づきます。私には2つの提案があります。 1.MCXN546 SDKをベースにプロジェクトを作成する場合は、mcxn5xxevk_lpuart_pollingをベースにいくつかのファイルを変更するだけで、設定ツールを直接使用できます。 2. mcxn5xxevk_lpuart_polling をベースとして使用する場合は、config tool を直接使用することはできません。しかし、別のmcxn546プロジェクトを作成し、設定ツールを使用して必要なピンとクロックを設定し、生成されたコードをプロジェクトmcxn5xxevk_lpuart_pollingにコピーすることもできます。 BR ハリー 回复： In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは@Elakiya 返信が遅くなり申し訳ありません。mcxn946 SDKパッケージをベースにしたFreeRTOSプロジェクトを作成してみましたか？ Snipaste_2026-03-24_15-49-09.png   BR ハリー 回复： In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは、 @Harry_Zhang さん。上記の問題について、アップデートと解決策を教えていただけないでしょうか。startup_mcxn546_cm33_core0.c でプロジェクトを実行する必要があります。startup_mcxn547_cm33_core0.c で実行する代わりに。手動で作成すると、UARTとMCUでクロック設定の問題が発生します。プロセッサとクロックをmcxn547からmcxn546に手動で変更しましたが、起動ファイルに変更を加えることができず、チップ構成ページにもプロセッサのエラー警告が表示されました。もしくは、mcxn546構成でFreeRTOSを使用したUARTポーリングおよびDMA動作のテストコードを含む、私のシンプルなプロジェクトを提供してください。上記の件について、最新情報をお知らせください。ありがとう。 回复： In UART protocol test MCXN546VKL, it stuck at while (0U == (base->STAT & LPUART_STAT_TDRE こんにちは、 @Harry_Zhang さん。mcxn546 や mcxn946 では作成していませんが、最初に mcxn546 で基本的な UART 操作を実行しようとしましたが、動作せず、UART と MCU でクロックの問題が発生しました。そこで、SDKからmcxn547のUARTポーリングのサンプルプロジェクトを作成し、pin_mux.cでプロセッサとパッケージIDを手動で変更しました。および clock_config.cmcxn546 MCU向けに構築・製造する。私のmcxn546ボードでは、UARTデータの送受信が行われています。しかし、startup_mcxn547_cm33_core0.c で実行されており、.mex のピン構成ページに表示されます。下記にファイルを示します。 startup_mcxn546_cm33_core0.c で実行して、config のこのエラーを解消する必要があります。この投稿にプロジェクトを添付しましたので、ご確認ください。 問題: MCUXpresso_IDE プロジェクトで検出されたプロセッサ「MCXN547」が、現在選択されている「MCXN546」と一致しません。 レベル: エラー