关于 S32K388 BIST 问题的更新：软复位导致应用程序外设初始化失败 您好，NXP支持团队， 针对之前 BIST 硬复位的问题：我们应用了您提出的更改，现在 BIST 可以成功执行软复位。 为了适应这种软复位并避免两次 MCU 时钟初始化，我们最初将 MCU 时钟初始化保留在应用程序中。然而，在 BIST 软复位并跳转到应用程序后，时钟重新初始化花费的时间异常长。我们怀疑出现这种延迟和死机的原因是启动管理器已经初始化了时钟，导致第二次尝试时发生冲突。 为了解决这个严重的延迟问题，我们完全从应用程序中移除了 MCU 时钟初始化，只将其保留在启动管理器中。不幸的是，这又引入了一个新问题：跳转到应用程序后，系统现在会在外围设备初始化期间（特别是 FlexCAN）挂起，这表明存在时钟可用性问题。 您能否就正确的时钟配置策略提供一些建议？具体来说，BIST 软复位是否会扰乱 BM 初始化的时钟，从而需要在应用程序中重新初始化？我们如何在 BM 和应用程序之间正确地交接时钟，而不会导致死机或极端延迟？ Re: Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App 嗨@HazemIhab ， 我没有在任何支持工单或社区帖子中找到您之前提到的 BIST 硬RESET问题。 我理解您看到的是 ST_DONE 功能复位。 RESET后，时钟配置会被重置，因此需要重新初始化。 如果您使用 RTD 驱动程序，Clock_Ip_InitClock() 函数会首先将所有时钟重置为安全状态——如果您在启动管理器和应用程序中都初始化时钟，这可能就是您看到的延迟。 它只能在启动管理器中进行配置，但您需要确保驱动程序启用应用程序所需的所有时钟——在本例中为 FlexCAN 时钟。 此外，所有系统时钟必须与 RM 中列出的时钟选项之一相匹配，例如表156。选项 A - 高性能模式 (CM7_CORE_CLK @ 160 MHz) (适用于 S32K388/S32K389)。 BR，丹尼尔 Re: Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App 你好@danielmartynek 谢谢你的解释。 为了澄清我们的设置：我们的启动管理器 (BM) 和应用程序 (App) 已经使用完全相同的时钟配置，包括 FlexCAN 时钟设置。 为了避免安全状态 RESET 带来的延迟，我们让 BM 初始化所有时钟，并从 App 中移除了 Clock_Ip_InitClock()。但是，当应用程序尝试在跳转后初始化 FlexCAN 时，系统仍然会因时钟相关错误而挂起。 Re: Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App 嗨@HazemIhab ， 我了解到存在故障例外情况，您能确认一下吗？ 如果是这样，你需要找到更多关于该异常的信息，以确认它是否真的与时钟有关。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 如果没有异常，但程序执行陷入了循环，那么究竟是哪个环节出了问题？ 另外，正如我提到的，所有系统时钟必须与 RM 中列出的时钟选项之一相匹配，例如：表156。选项 A - 高性能模式 (CM7_CORE_CLK @ 160 MHz) (适用于 S32K388/S32K389)，请确认？ 谢谢！ BR，丹尼尔

UM11490 and Bluetooth Classic Dear NXP support, one of our customer is running the following commands from pag 149 of UM11490, but cannot see any waveform. Please kindly check and verify if any additional command / condition is missing. Thanks Best Regards Pier ------------------------------------ # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 0C 00 # ENABLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 # ENABLE EVENT FILTER root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 05 0C 00 # ENTER IN TEST MODE root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 # START THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0x0e plen 4 01 19 FC 00 # STOP THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 39 00 00 00 -------------------- STOPPING THE SCAN FOR BLE AND CLASSIC BEFORE THE TX TRANSMISSION ---------------- # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 0C 00 # ENABLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 # ENABLE EVENT FILTER root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 05 0C 00 # ENTER IN TEST MODE root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 # DISABLE THE BLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 00 > HCI Event: 0x0e plen 4 01 1A 0C 00 # DISABLE THE CLASSIC SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI Command: ogf 0x08, ocf 0x000c, plen 2 00 00 > HCI Event: 0x0e plen 4 01 0C 20 00 # START THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0x0e plen 4 01 19 FC 00 # STOP THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 63 07 00 00 ** When disabling the scan before entering in the test mode, the stop for TX transmission give us: root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 ED 04 00 00 For Wifi 5 GHz -------------------------------------------------------------------------------- Paramters: Continuous transmit, BW = 40 MHz, 802.11ac, No DFS, CH = 40, MCS0 (13.5), Power = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 band=1 bw=1 channel=44 radio_mode[0]=3 radio_mode[1]= total rx pkt count=0 rx multicast/broadcast pkt count=0 rx fcs error pkt count=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic Hi @Christine_Li, sorry for missing the context: kernel version: lf-6.6.52-2.2.2 merged with 6.6.y community kernel FW version: IW612-18.99.3.p25.7, sepaated BT/WiFi FW, no combo product: IW612 UM11490 version: Rev. 1.8 — 2 June 2025 The following details will come ASAP dmesg logs or console logs when you load FW screenshot of the spectrum analyzer settings In the meanwhile, please let us know if you may need anything else. Thanks Best Regards Pier Re: UM11490 and Bluetooth Classic Hi, @pierluigi_p  Which Wi-Fi/Bluetooth product are you using? And what is your Linux kernel version? WiFi/Bluetooth driver and FW version? From the command logs, all HCI commands are completed successfully and the TX start command is accepted by the controller. In addition, the vendor-specific event returned by the TX stop command contains non-zero packet counters, which indicates that the controller believes packets have been transmitted during the test period. Therefore, the issue does not appear to be caused by a missing HCI command in the test sequence. I would recommend checking: The spectrum analyzer center frequency and span settings. The Bluetooth channel configured by the TX test command. The RF antenna configuration on the board. Whether the Bluetooth firmware are loaded correctly. Could you also share: The chip being used (IW416/IW612/etc.)? The exact UM11490 version? The dmesg logs or console logs when you load FW? Are you loading a combo FW or BT only FW? A screenshot of the spectrum analyzer settings? Best regards, Christine. Re: UM11490 and Bluetooth Classic Just adding, it was attempted with different settings for HackRF (gain and graphic adjustments), and we can see the 2.4 GHz (wifi) waveforms. Furthermore, we tested using different firmwares, for different versions in the imx-firmware repository, which includes one firmware for RF-test (sduart_nw61x_rftm_v1.bin.se in https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se) without success. Re: UM11490 and Bluetooth Classic Hello Pier and Christine I'm Helbert, the developer who started the thread in the Veriscite forum. Here are some attachments about the testing: Dmesg log (without the power configuration):  Dmesg log (with the power configuration):  Screenshot with the spectrum analyzer and the config file for 5 GHz (own implementation and NXP implementation) 5GHz-running-test.png after 5GHz-after-test.png Note: it was found that using -1 for power, we use the default value, however different values was experimented too. NXP script: NXP-5GHz-running-test.png Screenshot with the classic Bluetooth test: Bluetooth-2.4-Classic-RUNNING.png As you can see, there is no waveform generated Screenshot with the BLE test running: BLE-RUNNING-2.4-CH2.png Screenshot after the BLE testing (waveform interrupted):   BLE-FINISHED.png We can see in the graphic below that the waveform was interrupted when finishing the test Modinfo log: Tested HCI cmds:  Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Thanks for providing me the details. Let me check your info and screenshot, then reply to you. Please allow me some time. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hi， @HelbertPaulino  Thanks for providing us the details. Your screenshot only shows some Background noise, there is no any useful RF waveform information. May I ask: 1.You are using our IW612-EVK? or any module? If module, would you mind let me know your module part number? 2.How is your HW connections with the test equipment? 3.Your question is for BT or Wi-Fi? If for BT, I see your test commands, in our RF test guide, the stop command is: hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF but you are sending: root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 Please follow exactly our guide command to execute. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hello Christine, thanks for your checkings 1.You are using our IW612-EVK? or any module? If module, would you mind let me know your module part number? We have the module integrated into the SoM Variscite DART-IMX8M https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ It has the part number: LBES5PL2EL.4 2.How is your HW connections with the test equipment We have wireless access to the equipment's radio through the HackRF One equipment, which can capture the signals using its antenna (but it can capture other signals too; that's the reason for why you are seeing some noise) 3 - Your question is for BT or Wi-Fi? It's for both. For classical Bluetooth, we weren't able to see the generated waveforms (only for Bluetooth Low Energy), and for Wifi, we couldn't capture signals in 5 GHz About the hci command, I saw both, and we have both recommended in the NXP/Murata documents In AN14114, we have the short command on page 47 In UM11490 we have the long command on page 150 For the classic Bluetooth, I think I found the solution. When checking the UM11490, the explanation for the command is: hcitool -i hci0 cmd The examples in the document set tx_test_interval as 0x0D, in this scenario, the interval seems to be a little longer and, hence, it's a little hard to see the generated waveform. It appears like noise. When setting this parameter to 0x01, I could see a consistent waveform. Furthermore, I decreased the frequency range because it's a low-BW waveform. So, I think this solves the Bluetooth issue. However, I'm still not able to see the 5 GHz waveform. Do you have any tips for it? Thanks very much for your assistance Re: UM11490 and Bluetooth Classic Hey Christhine, It was raised the possibility of having another Murata Module in my used SoM. I disassembled the mine and I detected that its part number is: LBEE5PL2DL Hence, I have to review if the commands for 2EL are applicable to this model too Re: UM11490 and Bluetooth Classic Hello Christine, Thanks very much for your support. Debugging here a little more, I found a potential trouble here. When changing the region using the files provided here: https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL, I noticed a trouble with iw reg set Basically, following the idea posted here: https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working  I used the files directed for 2EL (and 2DL, they are the same), but when switching the regions, I could note that the iw reg get wasn't changing its location, by presenting the following message: HelbertPaulino_0-1784905230306.png Hence, when changing the regions to be used by the driver with the file *txpower*.bin, we weren't changing the system region. I saw that this has the potential to prevent the waveforms from being triggered, depending on the chosen region and settings applied to the radio. I removed the regulatory.db* files from Murata and used the original, and it seems to have better behavior. I was able to trigger some 5 GHz waveforms, and others I think are being masked by the noises May you confirm if the iw reg set / reg and the used regulatory files can affect the waveform generation? If yes, then I think we found the root cause of the problem. It's not Firmware / Script / Calibration files, but a region limitation. Do you think it makes sense or do you have another suspect for this? Thanks very much again Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Thanks for your info and glad to hear that Bluetooth is now working. So now let's focus on the Wi-Fi 5G RF test mode issue. LBEE5PL2DL module's Chipset is our NXP's WiFi/Bluetooth chipset: IW611. The difference between IW611 and IW612 is: IW612 supports 802.15.4, but IW611 does not support. But for WiFi and Bluetooth, IW611 and IW612 are same. So it means,  the commands for 2EL are applicable to this model(LBEE5PL2DL) too. Then now please help to follow AN14114's section: 2 Wi-Fi RF test mode to set your board and start the WiFi 5G RF test. Currently from your shared cat /proc/mwlan/adapter0/config results, I do not find any suspect points. The only thing is: please check your test equipment connections and also HW connections. At the same time, let me check internally to see whether it is supported to test RF on these 2 modules. What I confirmed is: we can test on our IW611 or IW612 EVK board, but for these 2 modules, I need to check whether need to do any HW reworks to allow to test RF performance. Once have any updates, will let you know. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hi Christine, I didn't see this message and replied to the other. Yes, I tried different BW settings, but I'm trending to think the problem can be attributed to the region limitation and noise in some regions. Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Can you please have a try with changing 40MHz to 20 MHz bandwidth for initial capture? echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config Your readback shows  bw=1  , which AN14114 defines as 40 MHz ;  bw=0  is 20 MHz . For HackRF observation, 20 MHz is the better first test because 40 MHz Wi-Fi is harder to capture/recognize cleanly on a narrow or marginal SDR setup. Please let me know whether it works fine for 20MHZ. Then we step by step to move to 40MHZ.   Best regards, Christine. Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Can you please have a try with below command: echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config instead of tx_frame command？ I found in your previous output of "cat /proc/mwlan/adapter0/config" tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff I worry it might not be recognized correctly. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hey Christine I was verifying the command, and you are right, but I don't know why that parameters (SHORT_PREAMBLE and ADVANCED_CODING) was appearing as -1 (represented as 4294967295) Maybe in the first implementation for the code, they was wrongly set as -1. However, replying your request, now we can generate the waveform for 5 GHz (tx_frame). For tx_continuous I could see the waveforme, but in a lower amplitude (almost not possible to see) You can look the frame generation in the picture below: 5GHz-CH100-BW40-FRAME-0x1100-14.png When trying to trigger the continuous, I could see the waveform, but very smoothly 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png I used the configuration above. I think the problem of not being able to see the waveforms for channels is due to the noise we have in the equipment are bigger than the waveform generated. I requested the Hardware team to verify using a more powerful spectrum analyzer. I'm waiting for its response to close the question for the non-generated waveforms. But about the regions, do you think it can explain why some waveforms are not being generated?   Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Yes, an incorrect Region/Regulatory Domain configuration can also explain why some 5 GHz Wi-Fi waveforms are not being generated, or why the device does not transmit at all on certain channels.    Does your Hardware team to verify using a more powerful spectrum analyzer? Anything else I can do for you on this case?   Best regards, Christine. Re: UM11490 and Bluetooth Classic Hello Christine, I think this confirmation and the tests that the guys did in another noiseless environment confirm that everything is now working properly. Thanks very much for your support. Nice to meet you Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Thanks for your reply and glad to hear that everything is now working properly. Then would you please help to mark my answer as a solution for this thread so that we can close this case? And also, please feel free to create new case to us if you have any other topic questions in the future. We are always glad to support you! Best regards, Christine. Re: UM11490 and Bluetooth Classic Thanks very much again, Christine. I'll do that 🙂

S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 Hi, I am using S32k312 controller mini EVBKIT, for checking the functionality of MCU sleep and wakeup. I am trying to make MCU-Wake up through ADC interrupt by giving low threshold and high threshold voltage value in ADC. Do this functionality work to make MCU wakeup. LavanyaPilli_1-1784889112438.png Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 Hello @LavanyaPilli Since ADC module is not available in Standby, you cannot use it to wakeup (unless the ADC pin is used as interrupt wakeup). However, LPCMP is available in Standby, and can be used instead: Julin_AragnM_2-1784927254532.png LPCMP reads the analog input pin voltage against a programmable DAC reference and generates a wakeup once the threshold is crossed. You can refer to the following examples: S32K312 : MCU wakeup using LPCMP trigger RTD3.0.0 S32DS3.5 [RTD600 IP] S32K3X4EVB-T172 LPCMP Wake-up S32K3 Low Power Management AN and demos Best regards, Julián Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 Hi, Thank you for the clarification. I will evaluate using the LPCMP for the Standby wakeup as you suggested. However, for our application requirements, we still need to implement the ADC interrupt wakeup functionality. Could you please assist me in verifying MEX file, if the ADC can be configured specifically as an external interrupt wakeup. Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 Hello @LavanyaPilli, Sure. If you are using PTA1 (ADC0_S9) as external interrupt wakeup, you can refer to the S32K312_IOMUX.xlsx file to find the assigned WKPU channel: Julin_AragnM_0-1785173159422.png PTA1 is WKPU[5], however, you must also add +4 as offset because of the 4 internal wake up sources. This makes PTA1 WKPU_CH_9. Julin_AragnM_1-1785173923562.png You must initialize the WKPU unit, and configure the respective channel: /* WKPU configuration */ Wkpu_Ip_Init(WKPU_INST, &Wkpu_Ip_Config_PB); Wkpu_Ip_EnableInterrupt(WKPU_INST, Wkpu_Ip_ChannelConfig_PB[0].hwChannel); You can use the following low power examples as reference: S32K3 Low Power Management AN and demos Example S32K312 STANDBY wake up using CAN-0-RX and GPIO Switch DS3.5 RTD300 [RTD600 IP] S32K312EVB-Q172 Standby RAM GPIO Wake-up Best regards, Julián Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 Hello @Julián_AragónM , Thank you for the reference; it is very helpful. We are currently utilizing the CAN-based wakeup configuration. We will evaluate the ADC-based wakeup setup at a later stage.

etpuc mpc5775 I would like to run one of function from cw function selector in eTPUC. I am aware of the starting/ending ram addresses of the etpuc (it is same as mpc5777c_vars_c.h). I modified my_system_etpu_init for the etpuc accordingly. I just copy the function files (like crank) and generate new files for etpuc.  While running all and suspend the program, the debugger's stuck PC: No source available for "0x800400"  What should be wrong? Re: etpuc mpc5775 There are several application notes as below, what have been changed about etpu initiailzation code? AN5374: eTPU library usage in an application – Application Note AN4907: Engine Control eTPU Library – Application Note AN2864: General C Functions for the eTPU – Application Note AN4908: Engine Control eTPU Demo Application – Application Note Re: etpuc mpc5775 How was the eTPU code generated? Did you use the Function Selector to generate a complete function set, or did you only copy the CRANK function files? Can you share your modified my_system_etpu_init() implementation? Is the generated eTPU code image successfully loaded into SCM during initialization? Can you provide the generated eTPU project files (e.g. etpu_set.c, etpu_set.h)? Is the PC always stopping at 0x800400, or does it vary?

RTC功率计算 您好，NXP， 我们正在计算RTC的电池寿命，RT1176中SNVS功率域需要活动电流和睡眠电流。 但是请参阅数据表 IMXRT1170BIEC - 表 13，第 35 页，其中只给出了睡眠电流。 请与我们联系影响 SNVS 功率域有功电流的因素以及与有功电流相关的各种计算方法。 Re: RTC Power Calculation 嗨@specneeraj ， 感谢您对 NXP MIMXRT 系列产品的关注！ VDD_SNVS_IN 为 SNVS/RTC 功能域供电。该域是一个始终开启的低功耗域，主要维护 32 kHz RTC、SNVS 逻辑以及相关的唤醒和功能安全。其当前功耗与 CM7/CM4 的活动/睡眠状态的相关性很弱；因此，表 13 中列出的 SNVS 模式的 VDD_SNVS_IN 值不是省略的“仅睡眠”数据，而是可以在 RTC 备份场景中使用的基准值。 如果纽扣电池仅在主电源故障时供电 → 直接使用 SNVS 模式电流估算； 如果纽扣电池在系统活动期间也向 VDD_SNVS_IN 供电，则根据活动/SNVS 占空比计算平均电流。 影响 SNVS 电流的主要因素包括温度、 VDD_SNVS_IN 电压、工艺偏差、32 kHz RTC 晶体/板的漏电流、SNVS 相关引脚的外部漏电流，以及设备是否实际进入 SNVS 模式。更多详情请参考AN13104 。 此致， 加文

FS6500 IO2_3/FCCU障害におけるデバッグモードと通常モード間の動作の不一致 こんにちは！   FS6500のIO2_3ピンはMCU FCCUに接続されています。   デバッグモードでは、FCCUの障害が1回発生すると、即座にリセットされます。   通常動作モードでは、FCCUの障害が1回発生すると、SBCはディープフェイルセーフ（DFS）モードに移行します。 この行動が予想されるものかどうか確認してもらえますか? 私の理解では、IO2_3の障害が発生すると、障害エラーカウンタが増加します。セーフティ応答(RSTBパルス、FS0Bアサーション、またはDFS遷移)は、フォールトエラーカウンターが設定済み閾値(3または6)を超えた場合にのみ行われます。 FS6500開発キット-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、ピーターさん。 ご説明いただき、ありがとうございました。   もう一つ質問があります。   FS6500のデータシートとRMを徹底的に検索しましたが、FCCUフォルトによって引き起こされるセーフティメカニズム戦略や対応するIMPACTレジスタ構成についてのドキュメントIO2_3ほとんど見当たりません。 以前は、故障IO2_3 Fault Error Counterが増加し、カウンターが閾値に達した後にセーフティ対策が適用されると思っていました。あなたの返信によると、IO2/IO3の故障がセーフティレスポンスを直接トリガーします。   マニュアルのどの章でIO2/IO3の直接セーフティ反作用の設定が説明されているか教えていただけますか? よろしくお願いいたします。 Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、 この挙動は、SBCが両方のテストで同じ動作状態でない場合に予想されます。 以下の点を区別してください。 MCUのデバッグモード、例えばMPCデバイスに接続されたデバッガー、 FS6500のデバッグモードは、FS6500のDEBUGピンを介して起動します。 FS6500がデバッグモードの場合、ウォッチドッグは内部的に動作しますが、リセットピンやフェイルセーフピンをアサートすることによってデバイスの動作に影響を与えることはありません。したがって、デバッグ中に観察される挙動は、単独または通常の動作とは異なる場合があります。このモードは、SBCがシステムを継続的にリセットすることなくソフトウェアデバッグを可能にすることを目的としています。 通常動作時、FS6500フェイルセーフ状態機械は設定されたセーフティ入力や反応を監視します。IO_2/IO_3がMCU FCCUエラー出力監視に使用される場合、SBCはFCCUフォルトを検出し、設定されたリアクションを実行することができます。例えば、構成に応じてFS0B/RSTBのアサーションなどです。 したがって、デバッグモードとスタンドアロンモードの違いは必ずしもMCUのFCCUの問題ではありません。これはおそらくFS6500がデバッグモードに入っているか、両CASE間のSBC初期化・構成の違いが原因です。 障害エラーカウンタは、通常、ウォッチドッグ監視やフェイルセーフ状態機械処理などのメカニズムに関連付けられています。FCCUが報告したセーフティクリティカルな故障は、カウンタが閾値に達するまで蓄積されるのではなく、直接設定された反応をトリガーすべきです。 したがって、即時のセーフティ応答の観察された挙動は意図されたセーフティ概念と整合しています。 よろしくお願いいたします。 ピーター Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、 重要な点は、FS6500はIO2/IO3 FCCUの監視を、他のほとんどの故障源とは異なる方法で処理するという点です。 この説明はFCCUの故障反応(IMPACT)表には記載されておらず、代わりにFS6500のフェイルセーフ故障マネジメントドキュメントに記載されています。 [[ ## completed ##]] FS6500のドキュメントによると、IO_23エラー検出(FCCU)は、常にフォールトエラーカウンターを増加させ、設定できないフォールトソースの一つとしてリストされています。ドキュメントでは、設定可能な故障源とは明確に区別されています。 したがって、IO2/IO3障害時に観測される動作は、設定可能なフェイルセーフ反応に使用されるIMPACTレジスタの設定のみによって制御されるわけではありません。IO2/IO3 FCCUモニターは、SBCの専用FCCU監視パスの一部であり、フェイルセーフ状態マシンによって処理されます。 確認すべき関連セクションはFS6500のドキュメント章 "故障エラーカウンター" で、以下のように記載されています。 [[ ## completed ##]] IO_23エラー検出（FCCU）は、障害エラーカウンタをインクリメントします。 この動作は設定変更できません。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html よろしくお願いいたします。 ピーター

UM11490とBluetooth Classic NXPサポートの皆様、 お客様の一人がUM11490の149ページから以下のコマンドを実行していますが、波形が見えません。 追加のコマンドや条件が不足していないか、ご確認ください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 ------------------------------------ # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 39 00 00 00 --------------------、TXトランスミッションの前にBLEとCLASSICのスキャンを止めること---------------- # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # BLEスキャンを無効に root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 00 > HCIイベント:0x0eプレン4 01 1A 0C 00 # クラシックスキャンを無効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCIコマンド:ogf 0x08、ocf 0x000c、プレン2 00 00 > HCIイベント:0x0eプレン4 01 0C 20 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 63 07 00 00 **テストモードに入る前にスキャンを無効にすると、TX送信の停止により次のようになります。 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント:0xffプレン6 19 01 ED 04 00 00 Wi-Fi 5GHz用 -------------------------------------------------------------------------------- パラメータ: 連続送信、帯域幅 = 40 MHz、802.11ac、DFSなし、CH = 40、MCS0 (13.5)、電力 = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 SDCMD52RW=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 バンド=1 BW=1 チャネル=44 radio_mode[0]=3 radio_mode[1]= 総処方PKT数=0 RXマルチキャスト/ブロードキャストのPKTカウント=0 rx FCSエラー PKTカウント=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 0 4294967295 0 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic こんにちは、 @Christine_Li さん。 文脈が抜けていて申し訳ありません。 カーネルバージョン：lf-6.6.52-2.2.2（6.6.yとマージ済み）コミュニティカーネル FWバージョン：IW612-18.99.3.p25.7、BT/WiFiファームウェアは別々、コンボは不可 製品:IW612 UM11490 バージョン: Rev.1.8 — 2025年6月2日 以下の詳細は近日中に公開されます ファームウェアをロードしたときのdmesgログまたはコンソールログ スペクトラムアナライザの設定画面のスクリーンショット その間、他に何か必要なことがございましたら、お知らせください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 Re: UM11490 and Bluetooth Classic こんにちは、 @pierluigi_p どのWi-Fi/Bluetooth製品を使っていますか? Linuxカーネルのバージョンは何ですか?WiFi/BluetoothドライバとFWバージョンは? コマンドログからは、すべてのHCIコマンドが正常に完了し、TXスタートコマンドがコントローラに受け入れられます。さらに、TX停止コマンドで返されるベンダー固有のイベント情報にはゼロでないパケットカウンタが含まれており、これはコントローラがテスト期間中にパケットが送信されたと判断していることを示します。 したがって、この問題はテストシーケンスにおけるHCIコマンドの欠落が原因ではないと考えられる。 確認することをお勧めします： スペクトラムアナライザの中心周波数とスパンの設定。 TXテストコマンドで設定したBluetoothチャネル。 基板上のRFアンテナ構成。 Bluetoothファームウェアが正しくロードされているかどうか。 また、以下のことも教えていただけますか: 使用されているチップはどれですか（IW416/IW612など）？ 正確なUM11490のバージョンは？ ファームウェアをロードしたときのdmesgログまたはコンソールログは？ コンボファームウェアをインストールしていますか、それともBluetooth専用ファームウェアをインストールしていますか？ スペクトラムアナライザの設定画面のスクリーンショットはありますか？ よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、ピアとクリスティーン 私はHelbert、Verisciteフォーラムでスレッドを始めた開発者です。 テストに関する添付ファイルは以下のとおりです。 dmesgログ（電源設定なし）： dmesgログ（電源設定を含む）： スペクトラムアナライザと5GHz帯の設定ファイル（自社実装およびNXP実装）のスクリーンショット 5GHz-running-test.png 実行後 5GHz-after-test.png 注：電力に-1を使用するとデフォルト値が使用されることがわかりましたが、異なる値も実験しました。 NXPスクリプト: NXP-5GHz-running-test.png 定番のBluetoothテストのスクリーンショット： Bluetooth-2.4-Classic-RUNNING.png ご覧の通り、波形は生成されません BLEテスト実行時のスクリーンショット： BLE-RUNNING-2.4-CH2.png BLEテスト後のスクリーンショット（波形が途切れています）： BLE-FINISHED.png 下の図で、テスト終了時に波形が中断されたことがわかります Modinfoのログ: テストされたHCI CMD: Re: UM11490 and Bluetooth Classic 補足ですが、HackRFの異なる設定(ゲインやグラフィック調整)で試したところ、2.4GHz(Wi-Fi)波形が見えます。さらに、imx-firmwareリポジトリ内の異なるバージョンの異なるファームウェアをテストし、RF-test用のファームウェアも含まれています(sduart_nw61x_rftm_v1.bin.se)は https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se)で成功しませんでした。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 詳細を教えていただきありがとうございます。 あなたの情報とスクリーンショットを確認してから、返信します。 少々お時間をください。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 詳細情報をご提供いただきありがとうございます。 あなたのスクリーンショットには背景ノイズが少ししか映っておらず、有用なRF波形情報はありません。 お尋ねしてもよろしいでしょうか？ 1.弊社のIW612-EVKをご利用ですか？または、どのモジュールでも構いませんか？モジュールに関するものであれば、モジュールの部品番号を教えていただけますか？ 2. ハードウェアと試験装置との接続状況はどうですか？ 3.ご質問はBluetoothに関するものですか、それともWi-Fiに関するものですか？ BTの場合、RFテストガイドでテストコマンドが見られますが、停止コマンドは以下の通りです: hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF しかし、あなたは以下を送信しています: root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 実行する際は、ガイドに記載されているコマンドに正確に従ってください。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。確認していただきありがとうございます。 1.弊社のIW612-EVKをご使用ですか？それとも他のモジュールをご使用ですか？モジュールをご使用の場合は、モジュールの部品番号をお知らせいただけますでしょうか？ 当社では、このモジュールをSoM Variscite DART-IMX8Mに統合しています。https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ 部品番号はLBES5PL2EL.4です。 2. テスト機器とのハードウェア接続はどうですか? HackRF One機器を通じて無線で機器の無線にアクセスでき、アンテナで信号をキャプチャできます(他の信号も受信できます。これがノイズが見られる理由です) 3 - 質問はBTですか、それともWi-Fiですか? どちらの場合にも当てはまります。クラシックなBluetoothでは生成された波形が見えず(Bluetooth Low Energyのみ)、Wi-Fiでは5GHz帯の信号をキャプチャできませんでした HCIコマンドについては両方見ましたし、NXP/Murataの文書でも推奨されています AN14114では、47ページに短いコマンドがあります UM11490では150ページに長いコマンドがあります クラシックなBluetoothについては、解決策を見つけたと思います。UM11490を確認すると、コマンドの説明は次のようになります。 hcitool -i hci0 cmd ドキュメントの例では、tx_test_intervalを0x0Dに設定していますが、このシナリオでは間隔が少し長くなるため、生成された波形が見づらくなります。それはノイズのように見える。このパラメータを0x01に設定すると、波形が一貫しているのが見えました。さらに、低帯域幅の波形であるため、周波数範囲を狭めました。これでBluetoothの問題は解決したと思います。 しかし、5GHzの波形はまだ確認できません。何かコツはありますか？ ご協力ありがとうございました。 Re: UM11490 and Bluetooth Classic クリスティーンさん、私の使用済みSoMに別の村田モジュールが搭載されている可能性が指摘されました。地雷を分解してみると、部品番号が「LBEE5PL2DL」であることが分かりました。 したがって、2ELのコマンドがこのモデルにも適用されるかどうかを確認しなければなりません Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 初期キャプチャの帯域幅を40MHzから20MHzに変更してみていただけますか? echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config 読み上げ結果によると  bw=1  AN14114では次のように定義されています。 40MHz ;  bw=0  は 20MHz 。 HackRFによる観測においては、20MHzの方が最初のテストとして適しています。なぜなら、40MHzのWi-Fiは、狭帯域または限界に近いSDR設定では、きれいに捕捉/認識するのが難しいためです。 20MHz帯で正常に動作するかどうか教えてください。次に、段階的に40MHzへと移行します。   よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 情報ありがとうございます。Bluetoothが正常に動作するようになったとのこと、良かったです。 では、Wi-Fi 5GのRFテストモードの問題に焦点を当てましょう。 LBEE5PL2DLモジュールのチップセットは、NXP製のWiFi/BluetoothチップセットであるIW611です。 IW611とIW612の違いは以下の通りです:IW612は802.15.4をサポートしています。しかしIW611はサポートしていません。 しかし、Wi-FiとBluetoothに関しては、IW611とIW612は同じです。 つまり、 2ELのコマンドはこのモデル(LBEE5PL2DL)にも適用できるということです。 では、AN14114のセクション「2 Wi-Fi RFテストモード」に従ってボードを設定し、WiFi 5G RFテストを開始するのを手伝ってください。 現在、あなたが共有してくれた cat /proc/mwlan/adapter0/config の結果からは、疑わしい点は見つかりません。唯一の注意点は、テスト機器の接続とハードウェアの接続を確認することです。 同時に、これら2つのモジュールでRFテストがサポートされているかどうか内部で確認させてください。確認したのは、IW611またはIW612のEVKボードでテストは可能ですが、これら2つのモジュールについては、RF性能をテストするためにハードウェアの再作業が必要かどうかを確認する必要があるということです。 何か進展があればお知らせします。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティーンさん。 サポートありがとうございます。 もう少しデバッグしてみたところ、潜在的な問題点が見つかりました。ここで提供されているファイルを使用してリージョンを変更する場合: https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL、IWのレギュレーションセットに問題があることに気づきました 基本的には、ここに投稿されているアイデアに従ってください:https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working  2EL(および2DL、同じです)用のファイルを使いましたが、リージョンを切り替えた際にiwレジスターの位置が変わっていないことが確認でき、以下のメッセージが表示されました: HelbertPaulino_0-1784905230306.png したがって、ファイル *txpower*.bin でドライバーが使用する領域を変更する際、システムリージョンを変更していたわけではありません。選択した地域や無線機に適用した設定によっては、波形の発生を阻止できる可能性があることが分かりました。 regulatory.db* を削除しました村田製作所から提供されたファイルを使用し、オリジナル版を使用しましたが、動作が改善されたようです。5GHzの波形をいくつか検出できた一方で、ノイズで隠れていると思うものもあります iw reg set/reg と使用されたレギュレーションファイルが波形生成に影響を与えるか確認してもらえますか? もしそうなら、問題の根本原因を見つけたと言えるでしょう。ファームウェアやスクリプト、キャリブレーションファイルの問題ではなく、地域制限の問題です。これは理にかなっていると思いますか？それとも他に容疑者をご存知ですか？ 改めてありがとうございました。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。このメッセージに気づかず、別のメッセージに返信してしまいました。 はい、色々なBW設定を試しましたが、問題はリージョンの制限や一部のリージョンでのノイズに起因するのではないかと考えています。 Re: UM11490 and Bluetooth Classic やあ、クリスティーン コマンドを確認していたのですが、あなたの言う通りですが、なぜそのパラメータ(SHORT_PREAMBLEとADVANCED_CODING)が-1(次のように表される)として表示されているのか分かりません4294967295) おそらく最初の実装で誤って-1に設定されていたのかもしれません。しかし、ご要望に返答すると、5GHz(tx_frame)の波形を生成できるようになりました。tx_continuousでは波形は見えましたが、振幅が小さい(ほとんど見えないほどです) 下の写真でフレーム生成の様子を見ることができます: 5GHz-CH100-BW40-FRAME-0x1100-14.png 連続音をトリガーしようとしたとき、波形は見えましたが、とても滑らかでした 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png 上記の設定を使用しました。 チャネルの波形が見えない問題は、機器内のノイズが波形自体よりも大きいからだと思います。私はハードウェアチームに、より高性能なスペクトラムアナライザを使用して検証するよう依頼しました。生成されていない波形に関する質問を閉じるために、その回答を待っています。 では、領域についてですが、なぜ一部の波形が生成されないのか説明できると思いますか?   Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 以下のコマンドで試してみてください。 echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config tx_frameコマンドの代わりに？ 以前の「cat /proc/mwlan/adapter0/config」の出力で、 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff 正しく認識されないのではないかと心配です。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino はい、誤ったリージョン/レギュレーションドメインの設定も、一部の5 GHz Wi-Fi波形が生成されない理由や、特定のチャネルで全く送信できない理由を説明できます。   貴社のハードウェアチームは、より高性能なスペクトラムアナライザを使用して検証を行う予定ですか？ このCASEで他に何かCANことはありますか?   よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。 今回の確認と、彼らが別の無音環境で行ったテストの結果から、すべてが正常に機能していることが確認されたと思います。 サポートありがとうございます。 はじめまして Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino ご返信ありがとうございます。すべてが正常に動作するようになったとのこと、安心しました。 では、このThreadの解決策として私の回答をマークしてくれませんか?SOすればこのCASEを終結CANできます。 また、FUTUREも他のトピックに関する質問があれば、どうぞ新しいCASEを作成してください。 いつでもあなたをサポートできることを嬉しく思います! よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic クリスティン、改めて本当にありがとう。 そうします 🙂

LS1046A DDR4 32GB DDR4 容量支持 你好， 我想知道LS1046A是否支持32GB DDR4内存。它是否兼容DDR3L？ Re: LS1046A DDR4 32GB DDR4 Size Support 感谢yipingwang的及时回复，请问LS1034A支持的最大DDR内存容量是多少？ Re: LS1046A DDR4 32GB DDR4 Size Support 1. LS1046A 是否支持 32 GB DDR4？ 是的。 2. LS1046A 可以与 DDR3L 兼容吗？ 不。 LS1043A 支持 32 位 DDR3L/DDR4 控制器，而 LS1046A/LS1088A 支持 64 位 DDR4 控制器。 Re: LS1046A DDR4 32GB DDR4 Size Support 根据 LS1043A 参考手册/产品简介，LS1043A 支持高达 32 GB 的 DDR/主内存。

PMIC Safety Configuration by MCU Hello NXP, From the FS26 Safety Manual, we understand that the fault reactions for the output regulators can be configured by the MCU during initialization. Could you please clarify whether this configuration requirement applies only to the output regulator fault reactions, (RSTB , FS0B & 01) of  PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 or whether the fault reactions for the internal voltage monitoring functions (e.g., VANA, VDIG, and other internally monitored supply rails) also need to be configured by the MCU during initialization? If the internal voltage monitoring fault reactions are not configurable by the MCU, can we assume that these reactions are fully managed internally by the FS26 PMIC? can you list which fault reaction does not required to be configured by the MCU and which requires  FSBC+PMIC Functional Safety Re: PMIC Safety Configuration by MCU You can refer to below picture showed: guoweisun_0-1785720521280.png ABIST can check VANA VDIG automatically not need configure. guoweisun_1-1785720570149.png

imx93 AHAB SGK サポート セキュア ブート署名用の SGK は imx93 でサポートされるようになりましたか、それとも SRK のみですか? アプリケーションノート12312「AHAB対応デバイスでのセキュアブート」の第3章には次のように書かれています。 注意: i.MX8ULP および i.MX93 の場合、現在リリースされているファームウェアでは SRK のみがサポートされています。 これはまだ当てはまりますか、それとも SGK は現在サポートされていますか?もしSOなら、どのファームウェアリリースからですか? Re: imx93 AHAB SGK support これは今でも真実です。SGK は i.MX93 ではサポートされていません。 よろしくお願いします。 Harvey Re: imx93 AHAB SGK support こんにちは、IMX91はどうですか?SGKをサポートしていますか?(リファレンス・マニュアルはそう示唆しています) [[ ## completed ##]]

通过MCU进行PMIC功能安全配置 您好，NXP， 根据 FS26 功能安全手册，我们了解到，输出调节器的故障反应可以在初始化期间由 MCU 配置。 请问此配置要求是否仅适用于输出调节器故障响应（RSTB、FS0B 和 01）？ PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 或者， MCU在初始化期间是否也需要配置内部电压监测功能（例如VANA、VDIG和其他内部监控的电源轨）的故障响应？ 如果 MCU 无法配置内部电压监控故障反应，我们是否可以假设这些反应完全由 FS26 PMIC 在内部管理？ 能否列出哪些故障响应不需要由MCU配置，哪些需要配置？ FSBC+PMIC 功能安全 Re: PMIC Safety Configuration by MCU 您可以参考下图： guoweisun_0-1785720521280.png ABIST 可以自动检查 VANA VDIG，无需配置。 guoweisun_1-1785720570149.png

SGTL5000XNLA3/R2 部分处于激活状态 大家好， SGTL5000XNLA3/R2 这个部件是否处于激活状态？我们可以把它用于新设计吗？ 数据手册中提及的EOL Re: SGTL5000XNLA3/R2 is part is active 好的，谢谢你的回复。 Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 产品信息 | 恩智浦半导体 guoweisun_0-1785821314080.png 数据表显示： guoweisun_1-1785824177846.png

SGTL5000XNLA3/R2 is part is active Hi Team, is this part is active SGTL5000XNLA3/R2? Can we use it for new design Datasheet mentioned asEOL Re: SGTL5000XNLA3/R2 is part is active Ok. Thanks for the response Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 Product Information | NXP Semiconductors guoweisun_0-1785821314080.png datasheet shows : guoweisun_1-1785824177846.png

FS6500 IO2_3/FCCU故障在调试模式和正常模式下的行为差异 你好！   FS6500 的 IO2_3 引脚连接到 MCU FCCU。   在调试模式下，单个 FCCU 故障触发会导致立即复位。   在正常运行模式下，单个 FCCU 故障触发信号会导致 SBC 进入深度故障保护 (DFS) 模式。 请问这种现象是否属于预期行为？ 我的理解是：IO2_3故障将增加故障错误计数器。只有当故障错误计数器超过配置的阈值（3 或 6）时，才应执行功能安全响应（RSTB 脉冲、FS0B 断言或 DFS 转换）。 FS6500 DEVKIT-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 嗨，彼得， 非常感谢您的解释。   我还有一个问题。   我仔细查阅了 FS6500 数据手册和 RM，但几乎没有文档介绍由 IO2_3 FCCU 故障触发信号所触发的功能安全机制策略以及相应的 IMPACT 寄存器配置。 之前我以为 IO2_3 故障会使故障错误计数器递增，功能安全措施会在计数器达到阈值后生效。根据您的回复，IO2/IO3故障会直接触发信号安全响应。   请问手册的哪一章介绍了IO2/IO3直接功能安全反应的配置？ 顺祝商祺！ Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好， 如果两次测试中 SBC 的运行条件不同，则可能会出现这种现象。 请区分以下各项： 例如，MCU调试模式，即调试器连接到MPC设备，以及 FS6500 调试模式，通过 FS6500 DEBUG 引脚进入。 当 FS6500 处于调试模式时，看门狗仍在内部运行，但它不会通过置位 RESET 或故障保护引脚来影响设备操作。因此，调试期间观察到的行为可能与独立组网 \(SA\)/正常运行时的行为有所不同。此模式旨在允许进行软件调试，而无需 SBC 不断重置系统。 在正常运行中，FS6500 故障保护状态机监测已配置的功能安全输入/反应。如果 IO_2/IO_3 用于 MCU FCCU 错误输出监控，则 SBC 可以检测到 FCCU 故障，并执行配置的反应，例如根据配置断言 FS0B/RSTB。 因此，调试模式和独立组网 \(SA\)模式之间的不同行为不一定是MCU FCCU的问题。这很可能是由于 FS6500 处于调试模式，或者两种情况下 SBC 初始化/配置存在差异造成的。 故障错误计数器通常与看门狗监控和故障保护状态机处理等机制相关联。FCCU 报告的功能安全关键故障应直接发出触发信号，以触发其配置的反应，而不是累积到计数器达到阈值。 因此，观察到的即时功能安全响应行为与预期的功能安全理念是一致的。 顺祝商祺！ Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好， 关键在于，FS6500 对 IO2/IO3 FCCU 监控的处理方式与其他大多数故障源不同。 该描述不在 FCCU 故障反应 (IMPACT) 表中，而是在 FS6500 故障保护故障管理文档中。 根据 FS6500 文档，IO_23 错误检测 (FCCU) 被列为始终递增故障错误计数器的故障源之一，并且无法配置为关闭。文档明确将其与可配置故障源区分开来。 因此，观察到的 IO2/IO3 故障行为并非完全由用于可配置故障保护反应的 IMPACT 寄存器设置所控制。IO2/IO3 FCCU 监测器是 SBC 专用的 FCCU 监视路径的一部分，由故障保护状态机处理。 需要查阅的相关章节是 FS6500 文档中的“故障计数器”章节，其中指出： IO_23 错误检测 (FCCU) 会增加故障错误计数器。 此行为不可配置。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html 顺祝商祺！ Peter

MCUによるPMICセーフティ構成 こんにちは、NXPさん。 FS26セーフティマニュアルから、出力レギュレータの故障反応は初期化時にMCUによって設定できることが理解されています。 この構成要件が出力レギュレーターの故障反応にのみ適用されるのか、明確にしていただけますか(RSTB, FS0B & 01) PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 また、 内部電圧監視機能 (例: VANA、VDIG、その他の内部監視供給レール)の故障反応も初期化時にMCUによって設定される必要があるのか? 内部電圧監視の故障反応がMCUで設定できない場合、これらの反応はFS26 PMICが内部で完全に管理していると考えてよいでしょうか? どの故障反応がMCUで設定不要で、どの回路が設定が必要かをリストアップできますか? FSBC+PMIC 機能安全 Re: PMIC Safety Configuration by MCU 以下の写真を参照してください: guoweisun_0-1785720521280.png ABISTはVANAのVDIGを自動的にCANチェックできます。設定は不要です。 guoweisun_1-1785720570149.png

RTC Power Calculation Hello NXP, We are calculating battery life for RTC for which active & sleep current are required for SNVS power domain in RT1176. However refer to datsheet IMXRT1170BIEC - Table13, page 35, only sleep current is given. Please let us know the factors affecting the active current and various calculations related to active current for the SNVS power domain. Re: RTC Power Calculation Hi @specneeraj , Thanks for your interest in NXP MIMXRT series! VDD_SNVS_IN supplies power to the SNVS/RTC domain. This domain is an always-on, low-power domain that primarily maintains the 32 kHz RTC, SNVS logic, and related wake-up and safety functions. Its current consumption is only weakly correlated with the active/sleep states of CM7/CM4; therefore, the VDD_SNVS_IN values for the SNVS mode listed in Table 13 are not omitted “sleep-only” data, but rather baseline values that can be used in RTC backup scenarios. If the coin cell only provides power when the main power source fails → Use the SNVS mode current estimate directly; If the coin cell also supplies power to VDD_SNVS_IN while the system is active, calculate the average current based on the active/SNVS duty cycle. The main factors affecting the SNVS current include temperature,  VDD_SNVS_IN  voltage, process variations, leakage from the 32 kHz RTC crystal/board, external leakage from SNVS-related pins, and whether the device has actually entered SNVS mode. Please refer to AN13104 for more details. Best regards, Gavin

Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi!   The IO2_3 pin of FS6500 is connected to the MCU FCCU.   In DEBUG mode, one single FCCU fault trigger leads to an immediate reset.   In Normal operating mode, one single FCCU fault trigger causes the SBC to enter Deep Fail-Safe (DFS) mode. Could you help confirm whether this behavior is expected? My understanding: The IO2_3 fault will increment the Fault Error Counter. The safety responses (RSTB pulse, FS0B assertion or DFS transition) should only take place once the Fault Error Counter exceeds the configured threshold (3 or 6). FS6500 DEVKIT-MPC5744P  Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi Peter, Thanks a lot for your clarification.   I have a further question.   I searched the FS6500 datasheet and RM thoroughly, yet there is little documentation introducing the safety mechanism strategy triggered by IO2_3 FCCU fault, as well as the corresponding IMPACT register configuration. Previously I thought IO2_3 fault will increment the Fault Error Counter, and safety actions take effect after the counter hits the threshold. According to your reply, IO2/IO3 fault triggers safety response directly.   Could you tell me which chapter of the manual covers the configuration of direct safety reaction for IO2/IO3? Best regards Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, This behavior can be expected if the SBC is not in the same operating condition in both tests. Please distinguish between: MCU debug mode, for example debugger attached to the MPC device, and FS6500 debug mode, which is entered through the FS6500 DEBUG pin. When the FS6500 is in debug mode, the watchdog still runs internally, but it does not affect device operation by asserting reset or fail-safe pins. Therefore, the behavior observed during debug can differ from standalone/normal operation. This mode is intended to allow software debugging without the SBC continuously resetting the system. In normal operation, the FS6500 fail-safe state machine monitors the configured safety inputs/reactions. If IO_2/IO_3 are used for the MCU FCCU error output monitoring, then an FCCU fault can be detected by the SBC and the configured reaction can be executed, for example assertion of FS0B/RSTB depending on the configuration. So the different behavior between debug and standalone mode is not necessarily an MCU FCCU issue. It is most likely caused by the FS6500 being in debug mode, or by a difference in the SBC initialization/configuration between the two cases. The Fault Error Counter is typically associated with mechanisms such as watchdog supervision and fail-safe state machine handling. A safety-critical fault reported by the FCCU should trigger its configured reaction directly rather than being accumulated until the counter reaches its threshold. Therefore, the observed behavior of an immediate safety response is consistent with the intended safety concept. Best regards, Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, The key point is that the FS6500 treats IO2/IO3 FCCU monitoring differently from most other fault sources. The description is not located in the FCCU fault-reaction (IMPACT) tables, but rather in the FS6500 fail-safe fault management documentation. According to the FS6500 documentation, IO_23 error detection (FCCU) is listed among the fault sources that always increment the Fault Error Counter and cannot be configured out. The documentation explicitly separates it from the configurable fault sources. Therefore, the behavior observed with an IO2/IO3 fault is not governed solely by the IMPACT register settings that are used for configurable fail-safe reactions. The IO2/IO3 FCCU monitor is part of the dedicated FCCU supervision path of the SBC and is handled by the fail-safe state machine. The relevant section to review is the FS6500 documentation chapter "Fault error counter", which states: IO_23 error detection (FCCU) increments the Fault Error Counter. This behavior is not configurable. https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html Best regards, Peter

Automotive Steering Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a steering control system using Pulse Width Modulation (PWM) on NXP S32K3 microcontrollers. The application reads an analog input from a potentiometer (simulating a steering wheel) and converts it into a servo motor position. As the input changes, the servo motor reacts in real time, mimicking how steering systems work in modern vehicles. This example is based on Application Code Hub demonstrations for: PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 In this workshop, a POT Click simulates the steering wheel position. When the student rotates it, an analog voltage proportional to the angle is read by the MCU through the ADC, scaled in software, and converted into a PWM duty cycle. The PWM is generated by the Servo Click (configured by the MCU over I²C) and drives a Micro Servo motor SG 180°, whose angle tracks the potentiometer in real time. Beyond the technical implementation, 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. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic steering control system and the ideas behind EPS and steer-by-wire. Use the POT Click as a simulated steering-wheel input. Acquire analog values (0–3.3 V) using the ADC and understand analog-to-digital conversion. Perform signal scaling from the ADC range to a servo angle / PWM duty cycle. Generate PWM signals to drive a servo motor. Configure the Servo Click over I²C using the OE (Output Enable) pin. Recognize the actuation data flow: sensor input → MCU processing → PWM actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why steering functions are relevant for functional safety. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Potentiometer (POT Click simulates the steering-wheel position) Processing: S32K3 MCU (reads the ADC, scales the value, commands the actuator) Output: Servo motor controlled via PWM (Micro Servo SG 180°) This matches the classic flow of an embedded actuation system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The potentiometer generates an analog voltage based on its position The ADC converts this voltage into a digital value The application scales this value into a steering angle The system generates a PWM signal based on the angle The servo motor moves accordingly This loop runs continuously to ensure real-time control. Designer.png Steering Monitoring Application Architecture 4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The POT Click outputs 0–3.3 V depending on the wiper position. The ADC samples this voltage at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). The further the potentiometer is turned, the higher (or lower) the digital sample. ADC acquisition is the foundation of automotive sensing — used for torque, throttle, battery voltage, and many others. 4.2 Signal Scaling — From ADC to Servo Angle The ADC range (for example 0–4095) and the servo range (0°–180°, expressed as a PWM duty cycle) are different. The application performs a linear mapping so that one end of the potentiometer corresponds to one steering extreme and the other end to the opposite. This is the same scaling used in real EPS systems, where a hardware reading is converted into a normalized control command. 4.3 PWM — Pulse-Width Modulation and Servo Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A hobby servo such as the SG 180° interprets this duty cycle as a position command. In this demo, the PWM is not generated by the MCU itself but by the Servo Click's dedicated PWM controller, which the MCU configures over I²C — a typical embedded pattern that offloads time-critical signal generation and keeps the CPU free for application logic. 4.4 I²C — Configuring the Servo Click I²C — Inter-Integrated Circuit is a two-wire serial bus made of SDA (data) and SCL (clock). The S32K3 uses LPI2C1 on PTC6 (SDA) and PTC7 (SCL) to configure the Servo Click — PWM frequency, channel, and duty cycle. The OE — Output Enable pin on PTB17 is an additional control line that enables or disables the PWM outputs without reconfiguring the chip, which is also useful for a quick "safe stop" behavior. 4.5 POT Click as Steering Wheel The POT Click is a simplified, safe stand-in for a real steering sensor. The student rotates it by hand, the voltage changes, the MCU reads it through the ADC, scales it, and the servo reacts. 4.6 Data Flow at a Glance Physical rotation → analog voltage → ADC sample → scaled command (angle / duty cycle) → I²C configuration of the Servo Click → PWM signal → servo angle. This direct chain from the student's hand to the servo shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the steering application and process steering inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the steering application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Servo Click servo-click.jpg PWM driver board used to control the servo motor position. POT Click pot-click.jpg  Potentiometer module used to simulate steering wheel input. Micro Servo SG 180°                     micro-servo-motor-sg-180-degree.jpg Actuator used to convert control signals into steering movement. USB-C / 12 V supply — Provides power and enables programming and debugging of the system. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate steering wheel input and actuator control. Steering Control Monitoring on FRDM-A-S32K312 Steering Control Monitoring on FRDM-A-S32K344 S32K312_Steering.png  S32K344_Steering.png     Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the steering demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable (and 12V supply for S32K312) Attach click boards Verify wiring Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Rotate the potentiometer Observe servo movement Servo follows potentiometer position in real time 7. Signal Behavior and Control Logic Steering_Control_Signal.png Figure: Steering control signal mapping. The 12-bit ADC value (0–4095) is linearly mapped to a servo angle (0°–180°) and a matching PWM duty cycle (1.0–2.0 ms), with reference points at Left, Center and Right. At startup the servo moves to the neutral position; during operation, any input change produces an immediate, proportional reaction — implementing a basic steer-by-wire behavior. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE No Servo Movement Verify PWM configuration Check servo wiring Ensure correct power supply Incorrect Behavior Check ADC configuration Validate scaling function Ensure PWM duty cycle mapping is correct Unstable Movement Add signal filtering Check power stability 9. Extending the Application The basic implementation can be extended in several ways: Steering Range Control Restrict or extend the actuator's range of motion Define software-based limits to protect the mechanics Input Direction Inversion Reverse how the actuator responds to the input Useful for left-hand vs. right-hand drive calibration Noise Filtering Apply software filtering to stabilize readings Avoid jitter near the center position Scaling Logic Exploration Identify and analyze how the input is mapped to the output Connect software math with hardware behavior Fault-Handling Behavior Add a mechanism that reacts to a detected fault Transition the system into a safer state State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator control In real systems: Redundancy is required Fault detection mechanisms are implemented Systems must comply with ISO 26262 (functional safety standard) Steer-by-wire systems require high reliability since there is no direct mechanical link. 11. Conclusion This module demonstrates how a simple embedded system can implement steering control using ADC input and PWM output. It shows how: Analog input is acquired Data is processed in real time Actuators are controlled using PWM Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 S32K312_Steering_Demo.gif S32K344_Steering_Demo.gif The course provides a strong foundation for more advanced systems, including filtering, state machines, and safety-oriented designs.

Automotive Transmission Control Using FRDM-A-S32K344 Microcontrollers 1. Overview The application demonstrates actuator control concepts commonly encountered in automotive transmission systems using the FRDM-A-S32K344 development platform. The application showcases how analog input acquisition, signal processing, and actuator control can be combined to emulate the behavior of an automotive transmission control module. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Transmission Control Module On FRDM-A-S32K344  The demonstration uses a potentiometer as the primary input device, representing the driver's throttle command. The analog signal is sampled using the ADC peripheral and fed into a transmission model that simulates vehicle speed, automatically selects one of six forward gears or neutral, and estimates engine RPM. The current gear is physically indicated by a servo motor, while a DC motor reflects the throttle input through a variable PWM duty cycle, emulating the drivetrain response of a real vehicle.   The example highlights the interaction between analog sensing, ADC conversion, transmission control algorithms, I²C communication, PWM generation, and actuator control commonly found in automotive embedded systems.   More than a technical course, this program embodies the Eat-Sleep-Code-Repeat approach to learning, where students learn by doing. By repeatedly designing, coding, testing, and refining automotive embedded applications on real hardware platforms, participants build both practical skills and the confidence needed to tackle real-world engineering challenges. 2. Learning Scope This article focuses on both practical implementation and core embedded system concepts: Analog signal acquisition using ADC Potentiometer-based continuous control inputs PWM generation using the eMIOS peripheral I²C communication with an external PWM controller Servo motor position control through an external PWM driver DC motor speed control with a dead-band region Automatic gear selection with shift hysteresis Engine RPM estimation and smoothing Real-time embedded control loops running at a fixed update rate Signal mapping and actuator response The example provides a practical introduction to automotive control systems where continuous sensor values drive actuator behavior through a simulated transmission model. 3. System Architecture The system follows a typical embedded control structure organised around a periodic control loop: Input: Analog throttle signal from the potentiometer Processing: S32K3 microcontroller running the transmission model (vehicle speed, gear selection, RPM) Output: Servo motor position (via I²C to an external PWM controller) and DC motor speed (via eMIOS PWM) Functional Flow The potentiometer voltage is sampled by the ADC and converted into a throttle command The MCU updates the transmission model, computing the simulated vehicle speed and selecting the appropriate gear The current gear is sent to the external PWM controller through I²C, which positions the servo motor accordingly The DC motor speed is updated through an eMIOS PWM channel proportional to the throttle command The entire cycle repeats at a fixed update rate to keep the actuators synchronised Transmission_Control_Architecture.png Transmission Control Application Architecture 4. Key Concepts 4.1 Control Principle Unlike systems based on push buttons or digital switches, this implementation uses a continuous analog input signal. The potentiometer provides a variable voltage level that represents the driver's throttle command. This value is continuously monitored and converted into a digital representation using the ADC peripheral. The processed value feeds a transmission model that simulates vehicle speed, selects a gear, and estimates engine RPM, which are then translated into commands for the servo (gear display) and the DC motor (speed). This approach allows smooth transitions instead of abrupt state changes and better reflects real-world automotive control systems. 4.2 Analog Input Acquisition The potentiometer acts as a variable voltage divider. As the potentiometer position changes, the output voltage changes continuously, the ADC acquires the voltage, and the MCU converts it into a throttle percentage. This value becomes the primary input variable for the transmission model. This process mirrors how many automotive sensors operate, where physical movement or operating conditions are converted into an analog voltage signal that must be processed by the control unit. 4.3 Servo Motor Control via I²C and External PWM Controller Unlike the DC motor, the servo motor is not driven directly by an MCU PWM channel. Instead, the MCU sends I²C commands to an external PWM controller located on the Servo Click board, which in turn generates the PWM pulses required to position the servo shaft. The transmission model computes the current gear and provides it as an input; the MCU translates the gear number into a pulse-width value and sends it to the external controller. Each discrete gear position corresponds to a specific servo angle, so the servo acts as a physical gear indicator on a graduated scale. 4.4 PWM-Based DC Motor Control The DC motor is driven directly by the MCU through the eMIOS peripheral, which generates the PWM signal required by the DC Motor 2 Click H-bridge driver. As the potentiometer value increases, the PWM duty cycle also increases, resulting in higher motor speed. When the throttle is at zero, the motor is stopped; above zero, the duty cycle is clamped to a minimum dead-band value (approximately 20 % of the full range) to guarantee reliable motor start-up, and then scales linearly up to full speed. This mirrors the response of a real drivetrain to a throttle input. 4.5 Automatic Gear Selection with Hysteresis The transmission model implements six forward gears plus neutral. Rather than mapping the throttle directly to a gear, the model maintains an internal simulated vehicle speed, which increases when the throttle is applied and decreases when it is released. Gear selection is performed by comparing the vehicle speed against a set of predefined thresholds: An upshift occurs when the simulated speed rises above the upper threshold of the current gear. A downshift occurs when the speed drops below the lower threshold of the current gear. The distance between the up and down thresholds forms a hysteresis band, preventing rapid oscillation between two gears when the speed hovers near a shift point. When the throttle is held at zero for a sustained period, the model detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 4.6 Engine RPM Estimation In parallel with gear selection, the model estimates an engine RPM value based on the throttle input and the currently engaged gear. On each gear change, the RPM is smoothly adjusted — decreasing on upshifts and increasing on downshifts — to reproduce the characteristic behaviour of an automatic transmission. This smoothing avoids abrupt jumps and gives a more realistic feel to the simulation. 4.7 Signal Mapping The application transforms the continuous throttle input into two coordinated actuator commands: a discrete gear position displayed by the servo, and a continuous PWM level applied to the DC motor. The conceptual mapping is shown below. Throttle Input Transmission State Servo Position (Gear Indicator) DC Motor Speed 0 % (idle) Neutral Rest position Stopped Low 1st – 2nd gear Low-gear positions Dead-band minimum → low speed Medium 3rd – 4th gear Mid-range positions Medium speed High 5th – 6th gear High-gear positions Maximum speed This mapping demonstrates how a continuous sensor input can be transformed into both a discrete state (gear) and a continuous actuator command (motor speed). 4.8 Data Flow at a Glance Physical rotation of the potentiometer → analog voltage → ADC sample → throttle percentage → transmission model (vehicle speed, gear, RPM) → I²C command to the external PWM controller (servo position) and eMIOS PWM signal (DC motor speed). All stages are re-evaluated at a fixed update rate to keep the actuators synchronised. This direct chain from the student's hand to the actuators is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the transmission control application, execute the transmission model, and drive the connected peripherals through ADC, eMIOS PWM, and I²C. FRDM K64 click shield                  frdm-k64-click mikroBUS expansion adapter that connects Click modules to the FRDM board. Servo Click                          servo-click Expansion board carrying an external PWM controller. It receives I²C commands from the MCU and generates the PWM pulses that drive the servo motor. Micro Servo Motor SG 180°                         micro-servo-motor-sg-180-degree Actuator used to physically indicate the currently selected gear on a graduated scale. DC Motor 2 Click   dc-motor2-click Compact add-on board with a PWM-controlled, full-bridge brushed DC motor driver. It receives the eMIOS PWM signal directly from the MCU. DC Motor                       DC MotorDC Motor Simulates the vehicle drivetrain speed, reflecting the throttle input applied by the user. USB-C cable — Provides power and enables programming and debugging. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate a complete transmission control chain, from throttle input to gear indication and drivetrain speed. Transmission Control Full Setup on FRDM-A-S32K344 Transmission Full SetupTransmission Full Setup The hardware configuration allows simultaneous control of a position actuator (servo motor driven through I²C) and a speed-controlled actuator (DC motor driven through eMIOS PWM). Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) Application Code Hub project import Transmission Control Module On FRDM-A-S32K344  6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for transmission control example Use the GitHub link for automatic configuration Select main branch Import project Project appears in workspace 2 Build the Application Compile the project Check for errors Confirm SDK component management Successful build with no errors 3 Connect Hardware Connect the board via USB-C Attach FRDM K64 Click Shield, Servo Click and DC Motor 2 Click Wire the servo motor, DC motor and potentiometer Verify wiring before powering the system Board powers up and is detected by IDE 4 Flash and Run Program the MCU Start execution Application runs continuously 5 Functional Validation Rotate the potentiometer Observe the servo pointer moving between the gear positions Observe the DC motor speed changing proportionally to the throttle Release the potentiometer and observe the transmission gradually downshifting back to neutral Gear indicator and motor speed respond consistently to throttle changes 7. Signal Behavior and Control Logic The following diagram illustrates how the transmission model selects the current gear based on the simulated vehicle speed, applying a hysteresis band to prevent frequent shifting around each threshold.   Transmission_Gear_Selection.png The transmission continuously compares the simulated vehicle speed against a set of predefined speed thresholds, one per gear. An upshift occurs when the vehicle speed rises above the upper threshold of the current gear (blue lines), while a downshift occurs only when the speed drops below the lower threshold of that gear (red dashed lines). The distance between the two thresholds forms a hysteresis band that prevents rapid oscillation between adjacent gears when the vehicle speed hovers near a shift point. When the throttle is held at zero for a sustained period, the transmission detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 8. Troubleshooting Issue Possible Actions Board Not Detected Verify USB connection Check drivers Restart IDE DC Motor Not Responding Check eMIOS PWM configuration Verify motor driver wiring and external power supply Confirm code execution Servo Not Moving Check I²C wiring (SDA / SCL) and pull-up resistors Verify that the external PWM controller is powered Confirm the servo is connected to the correct channel and powered by 5 V Incorrect Behavior Validate the ADC input range Inspect GPIO configuration for motor direction pins Verify transmission control logic implementation Unstable / Jittery Output Add software filtering on ADC readings Check power supply stability Verify grounding between motor drivers and MCU 9. Extending the Application The application can be enhanced by adding: Closed-Loop Control Integrate feedback sensors to dynamically adjust actuator outputs Compare commanded vs. actual position/speed for corrective action Additional Transmission Modes Extend the current six-gear + neutral model with Park and Reverse modes for a full PRND emulation Map potentiometer regions or dedicated inputs to specific transmission states Safety Functions Implement input plausibility checks on the throttle signal Add fault monitoring and safe-state transitions in case of sensor or actuator failure CAN Communication Transmit gear, RPM, and speed information over CAN or CAN FD networks Integrate with larger automotive powertrain systems Continuous Versus Discrete Control Compare button-based (discrete) and potentiometer-based (continuous) input styles Emulate electronic throttle control, position sensing, or actuator positioning applications 10. Safety Context Transmission control is part of vehicle motion systems, requiring: Reliable signal processing Deterministic control behavior Safety-aware design In production systems: Redundant checks are implemented Fault detection is mandatory Standards such as ISO 26262 apply Automotive transmission control units also implement input plausibility checks and safe-state fallback strategies to prevent unintended gear engagement or actuator runaway. 11. Conclusion This transmission control demonstration illustrates how the S32K344 platform can combine analog sensing, ADC conversion, I²C communication, PWM generation, and actuator control to implement a complete embedded control application. Using a potentiometer as a continuous input source, the system processes the throttle signal through a transmission model with six forward gears plus neutral, hysteresis-based gear selection, and RPM estimation, and translates the result into real-time commands for both a servo motor (gear indicator) and a DC motor (drivetrain speed). The project provides practical insight into the operation of automotive control systems and serves as a foundation for more advanced transmission, actuator, and motion-control applications. Result on FRDM-A-S32K344 Transmission resultTransmission result The course provides a strong foundation for more advanced systems, including closed-loop feedback control, additional transmission modes, CAN communication, and safety-oriented designs typical of automotive transmission control modules. 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.

LPC55S69 SPI - DMA - リンク転送またはピンポン転送でうまくいかない もう長すぎるよ…。 単一のSPI/DMA転送の例を試してみましたが、これらは正常に動作します。 DMA/リンクメモリ転送のサンプルコードを確認しましたが、これらは正常に動作します。 しかし、どれも私の要件を満たしておらず、試してみても合うものが見つかりません。 最初は、リンク構成または単なるピンポン方式で、DMAを使用したフリーランニングSPI TX/RXが必要です。 きっとここには既にこれを実現した人がいて、その知識を共有してくれる人がいるはずですよね？ これまでのところ、私ができた最良の方法は、SPI_DMA用のリンクされた設定のセットを作成することです。これは（最後の設定が最初の設定にリンクしているにもかかわらず）一度だけ実行され、その後停止します。 最悪のケースは、連結された16ビット転送に対して、単一の8ビット転送しか行わない場合だ。 アイデアが尽きてきて、おそらく既に失敗したことを試しているだけだと思う。 誰かいますか…？ 全般 LPC55xx ペリフェラル Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers これは古い投稿だと分かっていますが、とにかく...問題は、送信転送の幅に関係しています。FIFOを設定するには、32ビット（16ビットのデータ + 16ビットの設定）である必要があります。そうでない場合、SPIのすべての設定ビットがゼロになり、発生している問題が発生します。 --gra Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers こんにちは、 @IanMcCarthy さん。 遅れてしまい申し訳ありません。最近、異常なほど多くの質問を受けています。辛抱強く待ってくださり、本当にありがとうございます。 ご質問に関してですが、一度手動で起動（デバッグセッションで実行）すると、すべてのコードが無限に実行され、SPIからのSCK信号は2パルス以上（停止ボタンを押すまで連続して）生成されなければなりません。LPC55S69で使用しているSDKのサンプルコードはどれでしょうか？コードにどのような変更を加えましたか？そうすることで、あなたのコードを私のボード上で再現し、何が起こっているのかを確認できます。 ご協力いただき、本当にありがとうございました。他に質問があれば、遠慮なくお尋ねください。 よろしくお願いします。 パブロ・アバロス。 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 更新情報の投稿、3回目の試みです… スレーブSPIデバイスから一定のレートで継続的にデータを受信する必要があります（手動でトリガーする方法では要件を満たせません）。 以下のコードは現在の私の状態を示していますが、これはSPIクロックのプラス信号を2つ生成するだけで、それ以上何も起こりません。 SPIの設定が完了すれば、リンクされたDMA記述子のセットを設定でき、一度手動で起動すれば、その後は無期限に動作する、という理解で合っていますか？それとも間違っているでしょうか？ どなたかお手伝いいただける方がいらっしゃいましたら、大変ありがたいです。 srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers あなたの答えを完全には理解できていませんが、もう少し詳しく説明してもらえますか?転送時のuint8_t型の幅を維持しないのはなぜですか？ また、関数 DMA_SetupDescriptor() の 3 番目と 4 番目の入力パラメータの位置が間違っていることにも気づきました。 さらに、各ディスクリプタ宛先アドレスはデータを別のメモリ位置にリダイレクトすべきではないでしょうか?すべてが &masterTxData を指すのではなく。