MCXA185 Reading values of a potentiometer MCXA185 LPADC Potentiometer Reading – Looking for a More Stable ADC Value I am working with an NXP MCXA185 and using the LPADC to read a potentiometer connected to P2_0 / ADC0_A0. My current implementation uses: ADC0 / ADC0_A0 High-resolution conversion mode LPADC hardware averaging of 128 samples Long ADC sample time (kLPADC_SampleTimeADCK19) One ADC reading every 1 ms (1000 Hz) Software-triggered conversions A block average of 100 samples The resulting average is updated every 100 ms So effectively, each value used in the block average has already been averaged by the ADC hardware over 128 conversions. Current approach cmdConfig.conversionResolutionMode = kLPADC_ConversionResolutionHigh; cmdConfig.hardwareAverageMode = kLPADC_HardwareAverageCount128; cmdConfig.sampleChannelMode = kLPADC_SampleChannelSingleEndSideA; cmdConfig.sampleTimeMode = kLPADC_SampleTimeADCK19; Then every 1 ms: LPADC_DoSoftwareTrigger(POT_LPADC_BASE, (1U << POT_LPADC_TRIGGER_ID)); while (!LPADC_GetConvResult(POT_LPADC_BASE, &result)) { /* Wait for conversion */ } s_blockSum += result.convValue; s_sampleCount++; if (s_sampleCount >= 100U) { s_lastAverage = (uint16_t)(s_blockSum / 100U); s_blockSum = 0U; s_sampleCount = 0U; } My question Is this a good approach for getting a stable potentiometer value, or is there a better ADC filtering/averaging strategy? In particular, I am wondering about: Is using 128-count hardware averaging + 100-sample software averaging excessive for a potentiometer? Does this actually provide useful additional noise reduction, or am I just increasing the response latency? Would it be better to use a smaller hardware average, such as 16 or 32 samples, and then use a software filter? Would an IIR/exponential moving average be better than a 100-sample block average for a potentiometer because it provides a smoother value while responding faster to knob movement? Is kLPADC_SampleTimeADCK19 appropriate for a typical potentiometer, or should I use a different sample time? Are there any MCXA185-specific LPADC settings that I should enable for better stability? Is polling the ADC result inside a 1 ms function a reasonable implementation, or would a hardware timer trigger + ADC FIFO/interrupt approach be preferable? Pin configuration I am currently using: cfg.pullSelect = kPORT_PullDisable; cfg.driveStrength = kPORT_LowDriveStrength; cfg.passiveFilterEnable = true; cfg.inputBuffer = kPORT_InputBufferDisable; The potentiometer is connected as a voltage divider, with the wiper connected to P2_0 / ADC0_A0. I am mainly interested in getting a value that is: Stable when the potentiometer is not moving Responsive when the potentiometer is turned Not unnecessarily delayed by excessive averaging Resistant to small ADC/wiper noise I would appreciate feedback on whether my current 128 hardware average + 100-sample block average approach is appropriate, and what filtering strategy you would recommend for this application. Analog(ADC|CMP|DAC|OpAmps) MCXA

Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) We cannot rotate the Platform SCP03 keys on SE050C1 from the NXP factory (OEF) keys to our own device-derived keys. PUT KEY is rejected in every variation we have tried, on a factory-fresh part, with both Plug&Trust 3.0.6 and 4.7.1. A Platform SCP03 session with the factory keys works correctly — we can open it and run applet commands (GetVersion, GetRandom, ReadObject, WriteBinary) successfully. Only PUT KEY fails. We would like to know the correct APDU sequence to rotate Platform SCP03 keys on this part, and ideally a reference implementation. Setup: Secure element SE050C1 (SSS_PFSCP_ENABLE_SE050C1 = 1) ATR 00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08 01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41 54 50 4F ("JCOP4 ATPO") Host MCU ESP32-S3, ESP-IDF v5.3.4 Transport T=1 over I2C (T1oI2C) Middleware Plug&Trust — tested 3.0.6 and 4.7.1, identical behaviour both mini  Auth SE05X_Auth=PlatfSCP03, SSS_HAVE_SE05X_AUTH_PLATFSCP03 Host crypto mbedTLS The part is factory-fresh: it has never been successfully rotated , and it authenticates with the SE050C1 OEF keys from ex_sss_tp_scp03_keys.h. what are we trying to do: Rotate the Platform SCP03 key set (ENC / MAC / DEK) from the factory OEF keys to device-unique keys derived on the ESP32 (PBKDF2-HMAC-SHA256 over the ESP32's eFuse-resident HMAC key), so that only that specific host MCU can open a Platform SCP03 session with its SE050. what is working: Opening a Platform SCP03 session with the factory keys succeeds, and commands inside it work:scp :DEBUG:Authentication Successful!!! APDU :DEBUG:GetVersion [] -> 90 00 APDU :DEBUG:GetRandom [] -> 90 00 APDU :DEBUG:WriteBinary [] -> 90 00 So the channel, keys, and secure messaging are all functioning. waht fails: case A :  PUT KEY is rejected with 6A80(Wrong data). Command header and plaintext data field (before SCP03 wrapping): hdr : 80 D8 0B 81 Lc=70 data: 0B <- key version number 88 11 10 <16 bytes ENC enc. under DEK> 03 <3-byte KCV> 88 11 10 <16 bytes MAC enc. under DEK> 03 <3-byte KCV> 88 11 10 <16 bytes DEK enc. under DEK> 03 <3-byte KCV> Key values are encrypted with the current (factory) DEK using AES-CBC with a zero IV; KCV is the first 3 bytes of the AES encryption of a 16-byte block of 0x01 under the new key. Case B: ISD Selected If we first select the ISD: GP_Select(A0 00 00 01 51 00 00 00) -> 90 00 response: 6F 10 84 08 A0000001 51000000 A5 04 9F 65 01 FF then the same PUT KEY is rejected with 6982(security not satisfied)  instead of 6A80. This suggests the ISD does recognise the command but requires a secure channel — and that in Case A the command was going to the SE050 applet, which has no D8 instruction. However, GP_Select() in the middleware sends a plaintext APDU, which tears down the existing SCP03 channel. Our attempts to re-establish SCP03 after selecting the ISD (calling nxScp03_AuthenticateChannel() again, having reset fp_Transform / authType / pdynScp03Ctx on the session) fail: scp :WARN :nxEnsure:'status == kStatus_SSS_Success' failed. At Line:148 Function:nxScp03_AuthenticateChannel case C: Sending via DoAPDUTxRx_s_Case4_ext (with Le) returns 6700 (wrong length), consistent with the ISD's FCI advertising 9F 65 01 FF (max data field 255). waht already ruled out: Each of these was tested and made no difference to the result: Variable Values tried P1 0x00 (create new), 0x0B (replace current), 0x11 (target version) Leading KVN byte in data field present / absent APDU case Case4 (short) / Case4_ext (extended) Key block structure 88 11 10 03 Key wrapping AES-CBC zero IV under current DEK (equivalent to ECB for one block) KCV method AES of 16×0x01 under the new key, first 3 bytes Middleware version Plug&Trust 3.0.6 and 4.7.1 DEK source verified the KEK is the same key set that opens the session With the applet selected all variants give 6A80; with the ISD selected all short-form variants give 6982. Question: What is the correct APDU sequence to rotate the Platform SCP03 keys on SE050C1? Specifically: is PUT KEY expected to be sent to the Issuer Security Domain, or to the SE050 applet? If it must go to the ISD, how should the Platform SCP03 channel be established against the ISD using the Plug&Trust middleware? Is EX_SSS_BOOT_SKIP_SELECT_APPLET the intended mechanism, and if so what is the correct call sequence (SELECT ISD → INITIALIZE UPDATE → EXTERNAL AUTHENTICATE → PUT KEY)? Is the key data field format above correct for this part, in particular the key type coding, the length encoding, the DEK wrapping mode, and the KCV algorithm? Our Plug&Trust package defines INS_GP_PUT_KEY (0xD8) in nxScp03_Const.h and global_platf.h, but contains no implementation and no example that uses it. Could you provide the Platform SCP03 key rotation example / demo (the equivalent of what se05x_Delete_and_test_provision is for provisioning), or point us to it in the full SDK? Could you provide AN12436 (referenced in ex_sss_auth.h as the source of the OEF Platform SCP03 keys), or the application note that documents key rotation for this part? Background — why this went unnoticed For transparency, this is a problem we created for ourselves and only recently detected. Our provisioning code called PUT KEY and then discarded the return status: sw = gp_put_key_using_nxp_middleware(se, DERIVED_SCP03_KEYVER, ...); /* status never checked */ mark_rotated(se, DERIVED_SCP03_KEYVER); /* writes "rotated" marker */ ESP_LOGI(TAG, "SCP03 keys rotated successfully"); /* printed unconditionally */ Because the marker write (WriteBinary) does succeed, every device ends up with a "rotated" flag set while its Platform SCP03 keys are still the factory ones, and provisioning reported success. We have since added the status check, which is how we discovered PUT KEY has never actually succeeded on any unit. We are not asking for help with that part — it is fixed. We mention it only to explain why we are raising this now rather than at bring-up, and to make clear that the part is genuinely unrotated rather than in some partially-rotated state. SE050 Re: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) Hi @Rutwik0409 , Based on the information provided, the SE050C1 appears to be working correctly at the applet level:  SELECT  ,  GetVersion  ,  GetRandom  ,  ReadObject  , and  WriteBinary  all succeed over Platform SCP03. Therefore, this does not look like a basic transport, T=1, SCP03 key, or secure-messaging failure. Since you are using ESP32-S3 with a custom T=1 over I²C transport, this is likely a porting/integration issue around the GlobalPlatform Security Domain SCP03 session, not evidence that SE050C1 does not support Platform SCP03 key rotation. For Platform SCP03 key rotation , the  PUT KEY  command is a GlobalPlatform Security Domain operation , not an SE050 IoT applet command. The documented sequence is: Select the Security Domain / SSD. Open the Platform SCP03 secure channel using  INITIALIZE UPDATE  /  EXTERNAL AUTHENTICATE  . Send  PUT KEY  to update the Platform SCP03 key set. This also matches the behavior observed: When the SE050 applet is selected,  PUT KEY  returns  6A80  , which is consistent with sending a GlobalPlatform command to the wrong target. When the ISD is selected but no secure channel is established to that domain,  PUT KEY  returns  6982  , which is consistent with “security status not satisfied.” So the main point to check is not only whether Platform SCP03 works to the SE050 applet , but whether the middleware is opening Platform SCP03 against the correct Security Domain before issuing  PUT KEY  . NXP provides a reference demo for this exact operation: se05x_RotatePlatformSCP03Keys The demo is specifically described as demonstrating authentication with the default Platform SCP keys and rotation of those keys to user-defined keys.  Our recommendation is to avoid manually constructing the  PUT KEY  APDU at first, and instead compare against the NXP reference implementation. Here I would first suggest that you verify the implementation using NXP's official reference paths—such as the `se05x_RotatePlatformSCP03Keys` demo found in the Zephyr + nano package so that your ESP32 MCU is well supported without any porting work. This demo serves as NXP's reference implementation for platform SCP03 key rotation. The current issue suggests that the `PUT KEY` command is being sent to the wrong target, or that the corresponding platform SCP03 secure channel was not correctly established after selecting the ISD/SSD. The fact that SCP03 communication with the SE050 applet is functioning correctly does not guarantee that the `PUT KEY` process at the GlobalPlatform Security Domain level has been correctly set up. Please refer to https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rst for more details.   Hope that helps,   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

PN560 Hardware ID Hello NXP, I’m trying to identify which NXP chip corresponds to the Hardware ID ACPI\VEN_1FC9&DEV_3002. Could anyone also confirm which Hardware ID is expected for the PN560? Thank you in advance for any information or documentation references. Re: PN560 Hardware ID Hello Eduardo, Thank you for your reply and for your time. I would just like to note that this information appears to be publicly visible in Device Manager on laptops, tablets and any other devices equipped with these NFC readers. However, I understand your position and I will leave the matter here. Thank you again for your support. Best regards Re: PN560 Hardware ID Hello @johjoh Hope you are doing well. My apologies, information about these devices is not public and this is not the proper path to discuss any information about them. For further support, could you please contact your NXP Sales Representative or the person that provided you with information on these devices in a first place? Regards, Eduardo.

MRF300AN 27MHz Ref DesignTVS and Power Sequence Hi NXP Team, Two questions on MRF300AN-27MHz reference design: Q1: Can I put a 110V TVS across drain to ground for protection? Vds is 133V. Is this a good choice? Q2: What is the exact power-on sequence? Gate bias before drain or drain before gate? Also, should RF drive be ramped up slowly or can I apply full drive directly? Thanks. Re: MRF300AN 27MHz Ref DesignTVS and Power Sequence Hello, In general, the TVS reverse standoff voltage should be selected above the maximum normal operating drain voltage to prevent unintended conduction during normal operation, while still providing protection against abnormal transient events. Regarding the power-up sequence, the drain supply can be applied before the gate bias, or vice versa. Both approaches are acceptable in a stable and properly tuned circuit. Additionally, it is recommended to ramp up the RF drive gradually rather than applying full drive abruptly, as this helps ensure a smoother startup and reduces stress on the device under operating conditions. Hope this helps!

WS2812 interface With LPC5514JBD64E Hi NXP Community, I am working with an LPC5514JBD64E-based controller and I need to interface a WS2812/WS2812B LED ring with the MCU. I am studying the LPC5514JBD64E datasheet and my controller schematic, but I am new to the LPC55xx family and need some guidance. I would like to know: 1. Which GPIO pin of the LPC5514JBD64E should be used for the WS2812 data (DIN) signal? 2. Since the LPC5514JBD64E uses 3.3 V logic and the WS2812 will be powered from 5 V, what is the recommended hardware connection between the MCU and WS2812? 3. Is a 74AHCT125 recommended between the MCU GPIO and WS2812 DIN? 4. Which peripheral or method should be used to generate the precise timing required by the WS2812 protocol? 5. Is there an official NXP SDK example, driver, or sample code for controlling WS2812 or NeoPixel LEDs using the LPC5514JBD64E? 6. If there is no WS2812-specific example, could you provide or point me to a basic working example code that makes a WS2812 LED or LED ring blink or change color? 7. What is the recommended development environment and programming/debugging procedure for this MCU? My immediate goal is to make the WS2812 LED ring blink and display different colors using the LPC5514JBD64E. I would appreciate guidance on the correct GPIO, hardware connection, peripheral, and example code. Thank you! LPC55xx

Debug interface recommendations for Kinetis and LPC? I do most of my development on the Kinetis series, and potentially some LPC parts in the near future. I've got a drawer full of debug interfaces from P&E Micro, including a Cyclone ACP that I use most. I sometimes find myself switching from the $600 Cyclone to the $20 LPC-Link2 because the Cyclone has so many weird problems with MCUXpresso. Honestly the LPC-Link2 does most of what I need, it's just a bit slow. Should I be looking at Segger interfaces? Can someone recommend a reliable, reasonably fast interface that's well-supported in MCUXpresso (and hopefully CodeWarrior 11 as well) that doesn't cause crashes all of the time, or fail to halt a running target? Trace support would be nice. Thanks! Re: Debug interface recommendations for Kinetis and LPC? Hi @richard37  Thank you for your post! You may want to consider a SEGGER J-Link. It supports both Kinetis and LPC devices when used with MCUXpresso, and it is also natively supported by CodeWarrior 11. This makes it a good alternative if you need a debug probe that can be used across both development environments and device families.

S32 IDE开发环境RTD插件无法安装 需要S32 IDE开发环境安装S32ZE RTD插件开展S32Z280处理器软件开发工作，在环境中无法安装，提示如图1，在NXP官网无法下载，提示需要License，请提供License获取渠道，谢谢。 Re: S32 IDE开发环境RTD插件无法安装 不客气，有任何问题随时联系！ Re: S32 IDE开发环境RTD插件无法安装 第一个连接要求账号登录，登录后没有显示安装包下载路径。第二个连接进入“汽车软件包管理器”后成功下载到安装包，谢谢。 Re: S32 IDE开发环境RTD插件无法安装 Hi,Flynn_T 1.您看这个链接可以下载吗？最新的RTD版本应该是2.0.1 QLP01，版本列表中没有你提到的1.1.45。另外注意，2.0.1 QLP01的RTD，需要的S32DS IDE的版本是3.6.1。 Design : Product Information : Automotive SW - S32Z/E - Real Time Drivers (RTD) 2.这个链接您也可以看下，是否可以下载。 汽车软件包管理器 | NXP 半导体 BR Joey Re: S32 IDE开发环境RTD插件无法安装 Hi， BR Joey     我使用的S32 IDE的版本是3.6.10。需要安装的RTD版本是1.1.45，我NXP官方网站没有找到S32Z/E RTD插件的下载路径，请提供一个下载连接。 Best Regard Flynn_T Re: S32 IDE开发环境RTD插件无法安装 Hi，Flynn_T 您使用的S32 IDE的版本是多少呢？RTD版本是多少呢？ 在IDE中加载S32Z/E RTD插件一般不需要license。 BR Joey

i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled NXP 官方团队，您好： 我们在使用 i.MX 8M Plus 平台开发系统，运行 Linux A53 与 FreeRTOS M7。在尝试将 SAI3 音频接口分配给 Linux 使用的同时运行 M7 时，遇到了内核崩溃（SError / 页错误）。 1. 软件版本与环境： Kernel 版本：Linux 5.10.72 U-Boot 版本：U-Boot 2021.04 M7 SDK：MCUXpresso SDK for i.MX8MP (rpmsg_lite_str_echo_rtos) 参考官方文章：NXP Knowledge Base: Test SAI3 while running M7 firmware with remoteproc 2. 系统配置情况：   <1> M7 固件（m7.bin）存放在系统分区，并在 U-Boot 阶段通过 bootaux 0x007e0000 命令直接启动。 <2> 在 Cortex-A53 Linux 侧，我们使用挂载在 SAI3 + I2C3 + SDMA3 总线上的物理声卡芯片（SGTL5000）。 <3> Cortex-M7 负责 GPIO2_IO09 管脚上的 采集并触发高频采样中断，并通过 RPMsg 虚拟串口（/dev/ttyRPMSG30）与 A53 Linux 进行跨核数据交互。 3. 遇到的问题： 不调整声卡资源到A53的话，/dev/ttyRPMSG30设备操作是正常的； 目前需要应用A53的声卡设备，参考了官方帖子<Test SAI3 while running M7 firmware with remoteproc>后做出了以下调整，但内核启动会存在问题，改动部分如下： <1> 内核 dts配置已恢复声卡配置到A53，如附件 <2> u-boot dts： 分配了声卡资源到A53，如 <3> ATF，将 SAI3、sdma3 和 i2c3 分配给 A53，修改imx8mp_bl31_setup.c，如： <4> M7 SDK： 注释BOARD_BootClockRUN和BOARD_RdcInit函数涉及AUDIO的改动，如附件 和 4. 内核 dmesg 崩溃日志： 开机进入内核会卡主，log如下： [ 2.992289] i2c i2c-1: IMX I2C adapter registered [ 2.997631] SError Interrupt on CPU2, code 0xbf000002 -- SError [ 2.997634] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997636] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997638] Workqueue: events deferred_probe_work_func [ 2.997642] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 2.997644] pc : i2c_imx_probe+0x31c/0x8fc [ 2.997645] lr : i2c_imx_probe+0x2b0/0x8fc [ 2.997647] sp : ffff8000126a3af0 [ 2.997648] x29: ffff8000126a3af0 x28: ffff80001135c3f0 [ 2.997654] x27: ffff0000c50aa880 x26: 0000000000000023 [ 2.997660] x25: ffff0000c50aaca0 x24: ffff0000c50aa8f0 [ 2.997666] x23: ffff800011d7c090 x22: ffff0000c4410e40 [ 2.997672] x21: ffff80001135c428 x20: ffff0000c041d800 [ 2.997677] x19: ffff0000c041d810 x18: 0000000000000020 [ 2.997683] x17: 0000000000000000 x16: 0000000000000000 [ 2.997689] x15: ffff0000c44112b8 x14: 0000000000000000 [ 2.997695] x13: ffff0000c4410e40 x12: ffff8000126a3a70 [ 2.997700] x11: aaaaaaaaaaaaaaab x10: 0000000000000060 [ 2.997706] x9 : ffff800011b993b4 x8 : ffff800011b99000 [ 2.997712] x7 : 00007dfed2122a00 x6 : 000000000007a120 [ 2.997718] x5 : 0000000000b71aff x4 : 0000000000000002 [ 2.997723] x3 : 0000000000000002 x2 : 0000000000000000 [ 2.997729] x1 : ffff0000ff86ea08 x0 : ffff800013c8000c [ 2.997736] Kernel panic - not syncing: Asynchronous SError Interrupt [ 2.997741] CPU: 2 PID: 135 Comm: kworker/2:1 Not tainted 5.10.72-gf8ca51a867fa-dirty #56 [ 2.997742] Hardware name: EMB-3512-V11-M7 (DT) [ 2.997744] Workqueue: events deferred_probe_work_func [ 2.997747] Call trace: [ 2.997748] dump_backtrace+0x0/0x1a0 [ 2.997750] show_stack+0x18/0x70 [ 2.997751] dump_stack+0xd0/0x12c [ 2.997752] panic+0x16c/0x334 [ 2.997754] nmi_panic+0x8c/0x90 [ 2.997755] arm64_serror_panic+0x78/0x84 [ 2.997757] do_serror+0x64/0x6c [ 2.997758] el1_error+0x90/0x110 [ 2.997760] i2c_imx_probe+0x31c/0x8fc [ 2.997762] platform_drv_probe+0x54/0xb0 [ 2.997763] really_probe+0xec/0x4d0 [ 2.997765] driver_probe_device+0x58/0xc0 [ 2.997766] __device_attach_driver+0xa8/0x10c [ 2.997768] bus_for_each_drv+0x78/0xd0 [ 2.997769] __device_attach+0xd8/0x180 [ 2.997771] device_initial_probe+0x14/0x20 [ 2.997773] bus_probe_device+0x9c/0xa4 [ 2.997774] deferred_probe_work_func+0x80/0xc0 [ 2.997776] process_one_work+0x1cc/0x350 [ 2.997777] worker_thread+0x2bc/0x46c [ 2.997779] kthread+0x154/0x160 [ 2.997780] ret_from_fork+0x10/0x30 [ 2.998109] SMP: stopping secondary CPUs [ 2.998111] Kernel Offset: disabled [ 2.998113] CPU features: 0x0240002,2000200c [ 2.998114] Memory Limit: none 请帮忙看看问题点，是否有相关文档和改动可以解决，期待你们的建议和答复！感谢！ 回复： i.MX8MP: SError & Page Fault when running M7 with SAI3 audio enabled 已解决，需要完整关闭M7端的音频配置才可以

Could someone please help me find the Safety Manual for the S32K3? Hi everyone, I'm looking for the Safety Manual for the NXP S32K3 MCU family. Could someone help me find it or provide information on how to access it? Re: Could someone please help me find the Safety Manual for the S32K3? Hi Have you already signed an NDA with NXP? If you are unsure whether company has signed an NDA with NXP, please tell me company's full name or address. If you already have a valid NDA, please refer to this document to register a Secure File account. Once you have Secure File access, you can click on Secure in the documentation section of the S32K3 product page and download the Safety Manual. Best Regards, Robin

MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage Hi Team,   I am evaluating the latest version of the MCUXpresso SDK and working with an NXP MCU.       For saving small configuration parameters (device settings, calibration values, counters, etc.) into internal Flash memory, what is the currently recommended approach?     Specifically:   1. Is it better to use a dedicated Flash storage area or EEPROM emulation (where supported)?   2. Are there any performance or reliability considerations when performing frequent Flash write operations? 3. Does NXP provide any example projects demonstrating best practices for parameter storage and wear leveling? 4. Are there any SDK libraries recommended for managing persistent configuration data? I have reviewed the available SDK documentation, but I would appreciate guidance on the recommended implementation approach for new projects.   Re: MCUXpresso SDK Latest Version - Recommended Approach for Flash Data Storage Hello @Manjuanth, I see you've posted this on the S32K's product forum, however, S32K's MCUs are not compatible with MCUXpresso, and use S32 Design Studio instead. Could you share which NXP MCU you are using? Best regards, Julián 

How to enable and use GPIOs with Zephyr in the TrustZone Non-Secure environment with FRDM-MCXN947 This document describes the complete process required to enable and use GPIOs from a Zephyr Non-Secure application running on the FRDM-MCXN947. It covers the configuration of the AHB security attribution settings, the Zephyr and TF-M project configuration, and the use of the GPIO alias mirror registers to grant Non-Secure access to the desired GPIO ports. After completing these steps, GPIO peripherals can be controlled directly from the Zephyr application while maintaining the security isolation provided by TrustZone. MCXN Security(Edgelock | secure boot | OTP) FRDM-Training Package and IO|GPIO

MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Hi, I am working with the MR-CANHUBK344 and want to use its 100BASE-T1 Automotive Ethernet interface. My first goal is simply to get a working Automotive Ethernet example running on the board before modifying it for my application. I downloaded the official MR_CANHUBK3_IEEE1722 example. This looks suitable because it demonstrates MR-CANHUBK344, 100BASE-T1, TJA1103, GMAC, IEEE 1722 ACF-CAN, CAN/CAN-FD to Ethernet conversion, and FreeRTOS. However, I am facing a toolchain/version compatibility issue. My available environments are: S32 Design Studio 3.5 with S32K3 RTD 3.0.0 S32 Design Studio 3.6.7 with S32K3 RTD 7.0.1 When I import the original MR_CANHUBK3_IEEE1722 project, I can see the source files, but when I try to open the .mex configuration I receive this error: Processor S32K344, the PlatformSDK_S32K3_2022_03 version is not supported by the current version of the tool. For example, FreeRTOS_Toggle_Led_Example_S32K344.mex cannot be opened because it expects PlatformSDK_S32K3_2022_03. I understand that the original MR_CANHUBK3_IEEE1722 demo was developed using an older S32DS/RTD environment. I also tried installing S32 Design Studio 3.4 and downloaded SW32K3_S32DS_3.4.3_D2112.zip. However, I currently cannot activate S32DS 3.4 because my NXP account does not show a v3.4 license entitlement. Could you please help me with one of the following? Is there a working MR-CANHUBK344 IEEE1722 project for S32DS 3.5 and RTD 3.0.0? Is there an updated MR-CANHUBK344 Automotive Ethernet example for S32DS 3.6.x and a newer RTD version? For now, I only need a simple Automotive Ethernet demonstration where two MR-CANHUBK344 boards establish a 100BASE-T1 link and transmit/receive basic Ethernet frames using the S32K344 GMAC and TJA1103. I do not need SOME/IP, TSN, or a complex TCP/IP application at this stage. If there is a working S32DS 3.5 port of MR_CANHUBK3_IEEE1722, an updated project, or a migration guide, please share it. Or, If you could help me in activating the license. I clicked on the download and didn't receive any e-mail for the version 3.4. I got one e-mail for 3.6 though.  Thank you. Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Thank you. Re: MR-CANHUBK344 IEEE1722 Automotive Ethernet Example – Need Working Project for S32DS 3.5/3.6.7 Hello @Aaditya773 , The original MR_CANHUBK3_IEEE1722 demo was released for an older S32DS / RTD environment, so the .mex incompatibility with newer S32DS 3.5 / 3.6.x versions is expected. I cannot confirm that an officially released migrated version of this exact IEEE1722 ACF-CAN demo is available for S32DS 3.5 or S32DS 3.6.x / RTD 7.0.1. For your current goal, which is to bring up the 100BASE-T1 Ethernet interface first, I would recommend starting from a newer Ethernet example rather than directly migrating the old IEEE1722 project. There is an MR-CANHUBK344 lwIP example available on NXP Community: Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600. This example is based on lwip_FreeRTOS_s32K344, was adapted for the MR-CANHUBK344 board and demonstrates pinging the lwIP stack. However, this example was prepared for an RTD 6.0.0-based setup. Therefore, for RTD 7.0.1 I would use it mainly as a reference, not as a project to be imported directly. A cleaner approach is to start from the current lwip_FreeRTOS_s32k344 example delivered with your installed TCP/IP stack and then adapt the MR-CANHUBK344-specific parts from the community example, mainly the GMAC / MII port mapping, pin configuration, clocks, interrupts, and TJA1103-related setup. As another reference, you may also use the S32K344_gptp_ds example from package SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip I have made a quick check with the following software configuration: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_7.0.0_CD1_HF1_D2511_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_5.0.0_CD01_D2605_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip After a few small fixes in the S32 Configuration Tools configuration, the S32K344_gptp_ds example can be built in this environment. Please note that this is not a direct port of the original IEEE1722 ACF-CAN demo. It is rather a practical path for basic 100BASE-T1 Ethernet bring-up on MR-CANHUBK344 using a newer software environment. To make the discussion easier to follow and useful for other users as well, let us keep this thread focused on the MR-CANHUBK344 Ethernet / 100BASE-T1 bring-up topic. If you need support for any other issue, please kindly create a separate Community thread.   Best regards, Pavel

So little talk about NXP MCX family Mcus How comes? At the start of the year we have ported some products from obsolete microcontrollers to the NXP MCXA family of microcontrollers. Main motivation for this choice was the long time availability. So I had a few month working with that chip and it's infrastructure. And what can I say: They are pretty good. Price is okay. Dev-Board availability is good. The software stack works. Integration into their Eclipse based IDE is fine (and you are not forced to use it). Yes, there are some warts in the software here and there, but nothing out of the ordinary. Hardware features: Pretty cool. It does all the basics and more. I especially like that they have fifos worth speaking of for nearly all peripherials. Found no silicon bugs so far, even when I used the more obscure features of the chip. Performance is good as well. And yet - you find nearly to no posts about these chips. How comes? MCXC Re: So little talk about NXP MCX family Mcus Hi @naofomi  Thanks for your interest in the MCXA product family. Since MCXA is a relatively new MCU series, there is naturally less community content and fewer forum discussions available compared to mature product families such as LPC and Kinetis. Customers also receive support through other NXP channels, including DFAEs and private support cases. If you have any questions, please feel free to post them here. We will be glad to help and support your development. Thank you. BR Alice

Voltage injection tests for OV and UV scenarios and associated behavior Hello Community,  SBC FS4503 is used in one of our projects and configured as below for OV / UV conditions. VCCA, VCORE and VAUX are configured to have impact on FS0B only in an OV condition and an impact on RSTB and FS0B both in case of an UV condition. Voltage injection test was performed by injecting voltages at the VCORE, VAUX and VCCA pins by using a second power supply while the first power supply provided 12V input to the SBC.  Results of the test as below: 1. VAUX OV - Asserts FS0B, 2. VAUX UV- Triggers RESET 3. VCORE OV- Asserts FS0B but VCORE is cut off, as mentioned in the data sheet. 4. VCORE UV- Triggers RESET 5. VCCA OV- Asserts FS0B, but VCORE is pulled down for a short time, and hence reset 6. VCCA UV- Triggers RESET. VPRE- OV - Datasheet mentions regulator is switched off, and we observe a RESET. Below are the queries: 1. Is the Bench test procedure valid? Where, for OV conditions around 5.5V was injected on the respective pin and for UV conditions around 3.5V was injected on the pins. 2. Is the observation with VCCA OV condition acceptable? 3. When an OV condition occurs at VPRE, the datasheet mentions the regulator is switched off, does this cut-off the VCORE supply as well? Thank you, Aditya Re: Voltage injection tests for OV and UV scenarios and associated behavior 1. Is the Bench test procedure valid? Where, for OV conditions around 5.5V was injected on the respective pin and for UV conditions around 3.5V was injected on the pins. [gw]OV should use voltage above 5.5V, UV test should be lower than 3V. Also need meet the filter time and reaction time requirement. 2. Is the observation with VCCA OV condition acceptable? [gw]Does the second power supply(OV voltage) reverse-supply through the VCCA pin, causing disturbances in the VPRE/VCORE loop? Did you monitor the VPRE during this VCCA OV test？ 3. When an OV condition occurs at VPRE, the datasheet mentions the regulator is switched off, does this cut-off the VCORE supply as well? [gw]Yes, VCORE is provided by VPRE. Re: Voltage injection tests for OV and UV scenarios and associated behavior Hello @guoweisun ,  Thank you for the response. This is helpful.  Please find my queries below: [gw]Does the second power supply(OV voltage) reverse-supply through the VCCA pin, causing disturbances in the VPRE/VCORE loop? Did you monitor the VPRE during this VCCA OV test？ [ab]: VPRE was not monitored. I will monitor it with new tests. Could you please help me understand what is meant by reverse-supply through VCCA pin? [gw]OV should use voltage above 5.5V, UV test should be lower than 3V. "Also need meet the filter time and reaction time requirement." [ab]: As I am performing this activity manually, the filter time of 100-200us and reaction time of 314us are satisfied for the OV cases.  Below are some additional queries,  1. How is OV/ UV detected, what is the sampling rate used by the SBC? 2. What is the significance of the filter time and reaction time? 2. How many not ok samples are allowed before detecting an OV/ UV fault on any of the pins? Thank you, Aditya

S32K358 SEMA42 demo 你好！我要使用 SEMA42 模块中的 Gate 寄存器，去写其 GTFSM 字段。需要在 mcal 中去进行使能 SEMA42 操作，目的为在使用的过程中保证对 GTFSM 字段可以正常写入与读取。请帮忙提供一份使用SEMA42的核间通信的demo给我，谢谢！

Battery Management System - SW & HW Environment Battery Management System Software and Hardware Environment 0 Table of Contents •Introduction •Software •Hardware •References •Conclusion 1 Introduction This article presents a comprehensive overview of the hardware and software components required to design and implement a high-voltage Battery Management System (BMS). It focuses on solutions based on NXP hardware platforms, combined with the integrated development ecosystems provided by NXP and MathWorks. The objective is to highlight how these technologies work together to streamline system development, deployment, and validation. 2 Software The software environment provides the modeling, simulation, communication, code generation, and deployment capabilities required by the Battery Management System. 2.1 Deep Learning Toolbox Deep Learning Toolbox brings artificial intelligence into the model-based workflow. It provides MATLAB functions, apps, and Simulink blocks for designing, training, simulating, and analyzing deep neural networks. This makes AI-based behavior easier to develop, understand, and validate before deployment. In the Battery Management System, deep learning can support battery state estimation, fault detection, and operating-condition classification. The toolbox can create and evaluate neural networks, import pretrained models from PyTorch, TensorFlow, and ONNX, and integrate trained networks into Simulink for system-level simulation. Artificial intelligence is not treated as a separate development activity. Neural network behavior can be simulated and verified together with the battery control model. Networks can also be optimized through quantization, projection, or pruning, and prepared for embedded deployment through automatic code generation. This reduces integration risk and makes AI-based BMS functions easier to validate within the complete system. For more information, see the Deep Learning Toolbox documentation in the References chapter. 2.2 Vehicle Network Toolbox Vehicle Network Toolbox brings CAN communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding CAN messages, making network behavior visible and testable before deployment. In the Battery Management System, commands, feedback, and status information are exchanged over CAN, linking the ECU with the surrounding vehicle architecture. The toolbox helps define signal interfaces, pack and unpack CAN messages, simulate bus traffic, and validate communication before target execution. Communication is not treated as a late integration step. CAN interaction can be simulated and verified together with the control model. This reduces integration risk and makes ECU behavior easier to validate end to end. For more information, see the Vehicle Network Toolbox documentation in the References chapter. 2.3 NXP Model-Based Design Toolbox for BMS The NXP Model-Based Design Toolbox for BMS extends the NXP Model-Based Design Toolbox for S32K3 with BMS support. It enables configuration and integration of the MC33775A, MC33774A, MC33772C, MC33665A, and MC33664. The S32K3 toolbox includes peripheral blocks that provide access to key microcontroller resources such as ADC, PWM, CAN, SPI, UART, timers, and interrupts. These interfaces facilitate communication between the S32K3 microcontroller and the supported BMS integrated circuits. Together, the toolboxes support the development and deployment of BMS applications on the S32K3 platform, leveraging the underlying S32K3 and BMS software stack. The workflow also integrates with NXP configuration tools and supports real-time monitoring and visualization through FreeMASTER, simplifying application development, validation, and debugging. 3 Hardware The central hardware platform is the 800 V Battery Management System Reference Design using ETPL. The kit contains: RD-K358BMU - Battery Management Unit RD33774CNTEVB - Cell Monitoring Unit RD772BJBTPL8EVB - Battery Junction Box BATT-18EMULATOR - 18-cell battery pack emulator 3.1 RD-K358BMU The RD-K358BMU is an NXP reference Battery Management Unit (BMU) designed for evaluation, development, and rapid prototyping of 800 V high-voltage Battery Management System (HVBMS) hardware and software. It provides a representative automotive-grade BMU platform built around the S32K358 microcontroller, enabling developers to evaluate battery-management architectures, safety concepts, communication interfaces, diagnostics, and control strategies in a realistic system environment. The board integrates several NXP components, including the S32K358, FS26, MC33665A, HB2000, TJA1145A, PCA2131, NBP8 and MC12XS6. Together, these components provide the processing, power management, communication, sensing, actuation, diagnostics, and safety capabilities required in a high-voltage BMS application. 3.2 Cell Monitoring Unit: MC33774A The RD33774CNT3EVB is a centralized Cell Monitoring Unit (CMU) reference design intended for the development and evaluation of 800 V high-voltage Battery Management System (HVBMS) applications. It uses Electrical Transport Protocol Link (ETPL) communication to connect with the broader BMS architecture and support reliable data exchange within the battery system. The board includes three MC33774 Analog Front End (AFE) devices arranged in a daisy-chain configuration. These AFEs are responsible for measuring and monitoring battery cell parameters, helping developers evaluate cell supervision, diagnostics, and communication strategies in a centralized BMS topology.   3.3 Battery Junction Box: MC33772C The RD772BJBTPL8EVB is a Battery Junction Box (BJB) reference design developed for 800 V high-voltage Battery Management System (HVBMS) applications. It leverages Electrical Transport Protocol Link (ETPL) communication to ensure robust and isolated data exchange within the battery system. The board features two MC33772C battery sensor ICs configured to deliver redundant measurements of voltage and current, improving diagnostic coverage and supporting functional safety requirements. It also performs isolation measurements, which are essential for monitoring insulation integrity and detecting potential fault conditions in high-voltage environments. 3.4 18-Cell Battery Pack Emulator The BATT-18EMULATOR board is designed to emulate a multi-cell battery pack and is easily interfaced with MC33774 battery cell controller evaluation boards. It enables quick evaluation of NXP Battery Cell Controller (BCC) ICs and supports software development by providing a controlled and flexible test environment. The board allows users to intuitively adjust the voltage of each of the 18 emulated cells, as well as the voltage levels on selected analog inputs typically used for temperature sensing. This capability makes it particularly useful for validating measurement accuracy, system behavior, and control algorithms without requiring a physical battery pack. Additionally, the BATT-18EMULATOR provides three independent outputs, allowing up to three BCC ICs to be connected simultaneously to a single emulator board. 4 References Deep Learning Toolbox Documentation Vehicle Network Toolbox Documentation NXP Model-Based Design Toolbox 800 V Battery Management System Reference Designs Using ETPL 5 Conclusion This article described the software and hardware environment required for the Battery Management System. The software combines MathWorks model-based design capabilities with NXP BMS and S32K3 platform support. The hardware integrates the S32K3 with NXP battery-cell controllers, communication interfaces, and associated BMS devices. Together, these elements provide the foundation for battery monitoring, communication, algorithm development, code generation, deployment, and validation. Next article: BMS architecture and model description, including the main software components, communication interfaces, data flow, and overall application structure.

First Steps with the Automotive MCU S32K – Development Environment Setup Guide: How to Install S32DS and RTD (Japanese Blog) What is this article about? NXP provides the S32 Design Studio ( S32DS) software development IDE environment for S32 microcontrollers and processors , as well as the Real-time Driver (RTD) software required to operate the MCU, free of charge. This article explains how to install the S32DS development environment and the RTD. * What is a Real-Time Driver ? This is NXP's proprietary driver set that integrates an " AUTOSAR- compliant MCAL(Microcontroller Abstraction Layer)" and a " non-AUTOSAR-compliant conventional SDK(Software Development Kit)" into a single unit. This time, we'll use the S32K3 , an automotive MCU that is versatile and has a wide range of options, as an example. S32DS is an environment that can be used with other NXP automotive MCUs as well. Overview of the S32K3 microcontroller's software First, let's get a rough understanding of the S32K3's software configuration . You don't need to understand the details at this point. This article will only cover a portion of the following: S32 Design Studio (S32DS) Real-Time Driver (RTD) What should I install? (Checklist) S32 Design Studio (※A common development environment for the S32 series) S32K3 Real-Time Drivers (RTD for S32K3) 1. Install S32 Design Studio S32 Design Studio is a free integrated development environment (IDE) that supports Power Architecture ® ( e200 core) and Arm ® -based automotive high-reliability microcontrollers /processors. S32DS IDE is a simple development tool with no code size limitations, based on open-source software such as Eclipse IDE , the GNU Compiler Collection (GCC) , and the GNU Debugger (GDB), and can be used for editing, compiling, and debugging designs. Download and install Download the IDE installer from the download site for S32 Design Studio for S32 Platform: ide/s32-design-studio-for-s32-platform:S32DS-S32PLATFORM" target="_blank" rel="noopener"> nxp.com Go to the S32DS download site and click the " Download " button. The page will scroll down, so please click " Download " below. Click on S32 Design Studio IDE. Click on the latest version, and if there are no issues, agree to the terms of service. There are versions for Linux and Windows, so please click the one that matches your operating system. Once the download is complete, launch the installer and follow the on-screen instructions to complete the installation. The process isn't particularly difficult, but if you're unsure, the following video provides detailed instructions, so please watch it while you proceed with the installation. Recommended ▶ gallerypage/video-id/6366101833112" target="_blank" rel="noopener">Video S32DS3.6_install_activation_use.mp4 - NXP Community 2. Install the S32K3 Real-Time Driver. Real-Time Drivers (RTDs) are a set of software components developed by NXP to accelerate the development of embedded applications running on S32 automotive MCUs . They provide a standardized, high-performance interface to hardware peripherals, enabling developers to create reliable and scalable automotive software systems.   Download and install Go to the download site for RTD xp.jp/design/design-center/software/automotive-software-and-tools/real-time-drivers-rtd:AUTOMOTIVE-RTD" target="_blank" rel="noopener"> and click the " Download " button. The page will scroll down, so please click the " Download " button for the S32K3 Standard Software below. Please note that this Standard Software is free software and tools available for use. This time, we'll select an RTD for the S32K3. Click on the one that says“ Qualified as RFP Release” (RFP = Release For Production). I agree to the terms of service and will proceed. Next, click on the Updatesite for S32 Design Studio and download it . spoiler (Highlight for reading) * What is Updatesite? Simply downloading the RTD file doesn't mean you can use it with S32DS; you only have the "zip package" on hand. Only by installing the downloaded Update Site ( ..._DesignStudio_updatesite.zip ) into S32DS will the RTD be registered in the IDE. This allows you to select the RTD in the new project wizard and automatically generate the RTD code using "Update Code" based on the settings configured in the S32 Configuration Tool . *If you do not add this, RTD will not appear as an option when creating a new project. *Note that if the RTD is already bundled with the S32DS version, this procedure is unnecessary and you can use it as is. *What is Updatesite? Even after downloading RTD, you only have the "zip package" on hand and cannot use it with S32DS. Only by installing the downloaded Update Site (..._DesignStudio_updatesite.zip) into S32DS will RTD be registered in the IDE, allowing you to select RTD in the new project wizard and automatically generate RTD code using "Update Code" based on settings configured in the S32 Configuration Tool. *Without this, RTD will not appear as an option when creating a new project. *Note that this step is unnecessary for versions of S32DS that already bundle RTD and can be used immediately.   Open the Real-Time Driver on the S32DS and install RTD. Now let's actually open S32DS. Once you open S32DS, click on " S32DS Extension and Updates ". Verify that the S32K3 Development Package is installed. Click " Add Updates Site " in the bottom right corner and add the Real-time Driver you downloaded earlier. Once the addition is complete, the Real-Time Driver will appear on the left side. This time, click on "S32K3XX Real-Time Driver…" to start the installation. If you look at the bottom right, you can confirm that the installation has started. As the installation progresses, you will be prompted to restart the S32DS, so follow the instructions. After restarting, the RTD installation is complete! If you open " S32DS Project From Example " in the lower left, you can see the S32K3XX Real-Time Driver that you just installed . The following video also provides detailed instructions, so please try installing while watching the video. Recommended ▶ S32 Design Studio 3.6: How to Download RTD | NXP Semiconductors At this point, the installation of the S32 Design Studio IDE and the S32K3 Real-Time Driver is complete. Great job! In the next article, we will actually run the drivers and sample applications included in the RTD. =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but when making an inquiry, please refer to " 8 %E3% 81 %AE% E6 %8A% 80 %E8% A1 %93% E8 %B3% AA %E5% 95 %8F-% E5 %95% 8F %E3% 81 %84% E5 %90% 88 %E3% 82 %8F% E3 %81% 9B %E6% %B9% %B3% E6 %E6% 97 %A5% E6 %9C% AC %E8% AA %9E% E3 %83% 96 %E3% 83 %AD% E3 %82% B0/ba-p/2153299" target="_blank" rel="noopener" data-hyperlinktype="0" > How to ask technical questions to NXP ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may ask your representative directly. ) This article provides a detailed explanation of how to install the S32 Design Studio (S32DS) development environment and the Real-Time Driver for NXP automotive MCUs, in a level of detail that even those new to S32K can easily follow. This example uses the S32K3 automotive MCU, but the same procedure can be used to set up the environment for other automotive MCUs. (Working time: 20 minutes) General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads Japanese Blog

让我们使用 S32K – RTD（首款车规级 MCU）运行一个 LED 闪烁应用程序（日本博客） 这篇文章是关于什么的？ 在上一篇文章中，我们安装了S32 设计工作室（以下简称S32DS ）和实时驱动程序（以下简称RTD），以执行使用 S32 MCU 进行评估和开发所需的必要准备步骤。 汽车级MCU S32K入门指南——开发环境搭建指南：安装S32DS和RTD（日语博客） 这一次，我们将迈出下一步，实际打开一个 RTD 示例项目，并通过生成代码、构建和调试来体验 S32K3 开发的“第一步” 。 本文目标：调试 S32K3 FRDM 板上的 RTD 示例 ， 并使 LED 闪烁（预计时间：15 分钟） 准备 硬件： FRDM-A-S32K344 USB Type-C 数据线（※FRDM-A-S32K344 随附） 在本文中， 我们将使用 FRDM Automotive 的 新型 开发板 FRDM-A-S32K344 ，该开发板采用 S32K3 微控制器。S32K344 是 一款 1x LockStep Arm Cortex-M7 微控制器， 广泛应用于 电机控制 和车身控制 等领域。 软件： S32DS（IDE 开发环境） RTD（S32K3软件） 请事先确保已安装上一篇文章中介绍的 S32DS和RTD 。 步骤 1：打开 RTD 样品 启动 S32DS 并创建一个新项目。然后，按照以下步骤打开 RTD 示例。 打开左下角的“ S32DS 项目示例”，然后点击“ S32K3XX 实时驱动程序… ”查看ADC 、 CAN 、 GPT 、 I2C 、 PWM 等示例。 这次，我们以“ Dio 示例”为例。 点击“Dio 示例”，然后 选择“ Dio_Example_S32K344 ”。 示例的详细信息会显示在右侧，请检查内容并 点击“完成”。 在左侧的“项目资源管理器”中导航到 main.c ，然后单击打开源代码。 您会在右下角和代码中看到几个“警告”，但这些警告并不表示源代码本身存在错误，而是表示S32DS没有正确找到与 RTD 相关的头文件。 步骤 2：解决警告 要解决此警告，请先单击屏幕左侧项目资源管理器中的“example_Dio.mex” 。 “example_Dio.mex”是一个存储MCU设置（例如，DIO = 数字I/O）、引脚/时钟/外设设置和代码生成设置的文件。 配置工具界面将会出现。点击顶部中央的“更新代码”按钮，即可更新代码并解决错误。更新完成后，右下角“问题”部分中的警告信息将会消失。   步骤 3：构建 点击下方按钮返回上一屏幕。 在项目资源管理器的“生成”部分，您可以查看每个软件及其各自的标题。 最后，点击屏幕左上角的构建按钮。屏幕右下角应该会显示“构建完成”的消息，确认没有错误后，就表示之前提到的警告问题已经解决。 到目前为止，我们已经确认可以打开 RTD 示例项目，从 .mex 文件生成代码，并成功完成构建。 第四步：调试 使用随附的USB Type-C 数据线将 FRDM-A-S32K344 连接到您的电脑。连接成功后，板上的 LED 指示灯将亮起。   返回 S32DS 屏幕，点击屏幕顶部中央的调试图标（虫子图标）开始调试。点击后，屏幕上会显示一条消息，提示您启动 PE Micro 调试器，请允许其启动，并按照屏幕上的说明进行调试。 PE Micro是一款用于调试的调试驱动程序（工具）。S32DS使用名为 PE Micro的调试器将开发板连接到PC。 在当前环境下， S32DS （ IDE ）➡ PE Micro（调试工具） ➡ FRDM-A-S32K344 这是我们沟通的渠道。 调试后，如果控制台中出现“目标已复位”和“ DAP 已成功上电”等日志，并且调试视图中显示线程信息（线程 #1），则表示与目标板的连接和程序传输已成功完成。   步骤五：点亮LED灯 现在，让我们在 FRDM-A-S32K344 板上实际检查一下。 点击屏幕中央工具栏中的播放图标 ▶ “恢复/运行” 以开始执行程序。 请注意，每个示例程序都在 main() 函数的开头设置了一个断点，以便于调试。 如果您能确认 LED 灯 亮起 几秒钟 （下图黄色圆圈中的 LED 灯），则此调试成功。 在这个示例代码中， 我们被指示“ while (count++ < 10) ”。 初始计数为0 每次循环迭代，计数都会增加count++。 仅当计数小于 10 时才有效 换句话说，LED 最多亮 10次才能完成操作，所以LED 只亮几秒钟然后停止是正常的。 到目前为止，我们已经体验了从构建和调试 RTD 示例项目到验证其在实际电路板上的运行（打开和关闭 LED）的整个过程。 最后 这一系列步骤代表了使用 S32K3 的基本开发步骤。 代码生成 → 构建 → 调试 → 测试功能 通过在电路板上实际观察其运行情况，你就能更直观地了解软件如何控制硬件。 根据这些基本步骤，尝试开发你自己的应用程序。 =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。） 在本文中，我们将使用 S32K3 实时驱动程序中的一个 LED 闪烁示例项目，通过生成、构建和调试代码来体验 S32K3 开发的“第一步”。 本文目标：调试S32K3 FRDM 板上的RTD示例并使其 LED闪烁。 （预计时间：15分钟） 通用微控制器 S32设计工作室 S32K SW | 下载 日本博客

Let's run an LED blinking application using the S32K – RTD, the first automotive-grade MCU (Japanese blog) What is this article about? In the previous article, we installed S32 Design Studio (hereinafter S32DS ) and Real-Time Driver (hereinafter RTD) to perform the necessary preliminary steps for evaluating and developing with the S32 MCU. First Steps with the Automotive MCU S32K – Development Environment Setup Guide: Installing S32DS and RTD (Japanese Blog) This time, as the next step, we will actually open an RTD sample project and experience the " first step " of S32K3 development by generating code, building, and debugging . Goal of this article: Debug a sample from RTD on an S32K3 FRDM board and make an LED blink (estimated time: 15 minutes) Preparation Hardware: FRDM-A-S32K344 USB Type-C cable (※Included with FRDM-A-S32K344) In this article, we will be using the new FRDM Automotive board, the FRDM-A-S32K344 , which uses the S32K3. The S32K344 is a 1x LockStep Arm Cortex-M7 microcontroller and is used in a wide range of applications, including motor control and body control . software: S32DS (IDE development environment) RTD (Software for S32K3) Beforehand, please make sure that S32DS and RTD, which were introduced in the previous article , are installed. Step 1: Open the RTD sample Launch S32DS and create a new project. Then, follow these steps to open the RTD sample. Open " S32DS Project from Example " in the lower left corner, and click " S32K3XX Real-Time Drivers… " to see examples of ADC , CAN , GPT , I2C , PWM, etc. This time, let's use " Dio Example " as an example. Click on "Dio Example," and then select " Dio_Example_S32K344 " from there. The details of the example are displayed on the right, so check the contents and click "Finish." Navigate to main.c in the "Project Explorer" on the left and click to open the source code. You will see several "Warnings" in the bottom right and on the code, but these warnings do not indicate errors in the source code itself, but rather that S32DS is not correctly finding where to look for RTD-related header files. Step 2: Resolving the Warning To resolve the warning, first click on "example_Dio.mex" in the Project Explorer on the left side of the screen. "example_Dio.mex" is a file that stores MCU settings (e.g., DIO = Digital I/O), Pins/Clock/Peripheral settings, and code generation settings. The Configuration Tool screen will appear. Click "Update Code" at the top center to update the code and resolve the error. Once the update is complete, the warning message will disappear from the "Problem" section at the bottom right.   Step 3: Build Click the button below to return to the previous screen. In the " generate " section of Project Explorer, you can view each software and its respective headers. Finally, click the build button in the upper left corner of the screen. You should also see a "Build Finished" message in the lower right corner of the screen, and confirm that there are no errors, which means the warning mentioned earlier has been resolved. Up to this point, we have confirmed that we can open the RTD sample project, generate code from the .mex file, and complete the build successfully. Step 4: Debugging Connect the FRDM-A-S32K344 to your PC using the included USB Type-C cable . The LED on the board will light up when the connection is successful.   Return to the S32DS screen and click the debug icon (bug logo) at the top center of the screen to start debugging. After clicking, a message will appear asking you to launch the PE Micro debugger, so allow it to launch and follow the on-screen instructions to proceed with debugging. PE Micro is a debug driver (tool) used by the S32DS to connect the board to the PC. In the current environment, S32DS ( IDE ) ➡ PE Micro ( Debugging Tool ) ➡ FRDM-A-S32K344 This is the route through which we are communicating. After debugging, if logs such as " Target has been RESET " and " DAP successfully powered up " appear in the Console, and thread information ( Thread #1 ) is displayed in the Debug view, then the connection to the target board and program transfer have been completed successfully.   Step 5: Light up the LED Now, let's actually check it on the FRDM-A-S32K344 board. Click the play icon ▶ “Resume/Run” in the toolbar in the center of the screen to start the program execution. Please note that each sample program has a breakpoint placed at the beginning of the main() function to facilitate debugging. If you can confirm that the LED lights up for a few seconds (the LED circled in yellow in the diagram below), then this debugging was successful. In this example code, we are instructed to " while (count++ < 10) ". Start with count = 0 The count increases by count++ with each loop iteration. It only works while count < 10 In other words, the LED lights up a maximum of 10 times to complete the operation, so it's normal for the LED to light up for only a few seconds and then stop . Up to this point, we have been able to experience the entire process from building and debugging the RTD sample project to verifying its operation on the actual board ( turning the LEDs on and off). Finally This series of steps represents the basic development steps using the S32K3. Code generation → Build → Debug → Test functionality By actually seeing it in action on the board, you were able to gain a more intuitive understanding of how software controls hardware. Based on these basic steps, try developing your own application. =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) In this article, we will use a sample LED blinking project within the S32K3 Real-Time Driver to experience the " first steps " of S32K3 development by generating, building, and debugging code. Goal of this article: Debug a sample in RTD on an S32K3 FRDM board and blink an LED. (Estimated time: 15 minutes) General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads Japanese Blog

初めての車載向けMCU S32K – RTDを使用してLED点滅のアプリケーションを動かしてみよう (日本語ブログ) この記事は？ 前回の記事では、S32 Design Studio（以下S32DS）とReal-Time Driver（以下RTD）のインストールを行い、S32 MCUの評価、開発に必要な下準備を行いました。 初めての車載向けMCU S32K – 開発環境構築ガイド：S32DSとRTDのインストール（日本語ブログ） 今回はその次のステップとして、実際にRTDのサンプルプロジェクトを開き、コード生成、ビルド、デバッグを行うことで、S32K3開発の「最初の一歩」を体験してみます。 この記事のゴール：S32K3 FRDMボード上でRTD内のサンプルをデバッグし、LEDを点滅させる （所要時間：15分） 事前準備 ハードウェア： FRDM-A-S32K344 USB Type-Cケーブル (※FRDM-A-S32K344に付属しています。) 今回の記事では、S32K3の新しいFRDM Automotiveボード、FRDM-A-S32K344を使います。S32K344は、１ｘLockStep Arm Cortex-M7 マイクロコントローラで、モーター制御、ボディ制御等、幅広いアプリケーションで採用されています。 ソフトウェア： S32DS (IDE開発環境) RTD (S32K3用ソフトウェア) 事前に、前回の記事、で紹介したS32DSとRTDがインストールされていることを確認してください。 ステップ１：RTDサンプルを開く S32DSを起動し、新しいプロジェクトを作成しましょう。その後、以下の手順に沿って、RTDサンプルを開きます。 左下の「S32DS Project from Example」を開き、「S32K3XX Real-Time Drivers…」をクリックすると、ADC、CAN、GPT、I2C、PWM…etc.等のサンプルが確認できます。 今回は、例として「Dio Example」を使ってみましょう。「Dio Example」をクリックし、その中からさらに「Dio_Example_S32K344」を選択。右側に、Exampleの詳細が記載されているため、中身を確認し、「Finish」をクリック。 左の「Project Explorer」でmain.cへと移動し、クリックすると、ソースコードを開くことができる。 右下およびコード上にいくつかの「Warning」が表示されますが、この警告は、ソースコードそのもののミスではなく、S32DSがRTD関連のヘッダファイルを探す場所を正しく見つけられていない場合に表示されます。 ステップ２：Warningの解消 Warningを解消するために、まずは画面左のProject Explorerから、「example_Dio.mex」をクリックします。「example_Dio.mex」は、MCUの設定（例：DIO = Digital I/O）、Pins / Clock / Peripheral設定、コード生成設定情報を保存しているファイルです。 Configuration Toolの画面が表示されるので、中央上の「Update Code」をクリックし、エラーを解消するためにコードを更新します。アップデートが完了すると、右下の「Problem」セクションからWarningメッセージが消えます。   ステップ３：ビルド 以下のボタンをクリックし、元の画面に戻ります。 Project Explorerの「generate」のセクションで、各ソフトウェアとそれぞれのヘッダーを確認することができます。 最後に、画面左上のビルドボタンをクリックします。画面右下に「Build Finished」のコメントともにエラーが無いことも確認できるので、先ほどのWarningも解消されたことが確認できます。 ここまでで、RTDサンプルプロジェクトを開き、.mexファイルからコードを生成し、ビルドが正常に完了するところまで確認できました。 ステップ４：デバッグ FRDM-A-S32K344を付属のUSB Type-Cケーブルを使って、お使いのPCにつないでください。正常につながると、ボード上のLEDが光った状態になります。   S32DSの画面に戻り、画面中央上のデバッグアイコン（虫のロゴ）をクリックし、デバッグを開始しましょう。クリックすると、デバッガのPE Microを起動させるメッセージが出てくるので、起動を許可し、画面の指示に沿ってデバッグを進めてください。 PE Micro は、デバッグ用の接続ドライバ（ツール）で、S32DSがPCとボードをつなぐために、PE Microというデバッガを使っています。 現在の環境では、 S32DS（IDE）➡ PE Micro(デバッグツール) ➡ FRDM-A-S32K344 という経路で通信しています。 そして、デバッグ実行後、Consoleに「Target has been RESET」「DAP successfully powered up」などのログが表示され、さらにDebugビューにスレッド情報（Thread #1）が表示されていれば、ターゲットボードへの接続およびプログラム転送は正常に完了しています。   ステップ５：LEDを光らせる では、実際にFRDM-A-S32K344ボード上で確認しましょう。 画面中央のツールバーにある再生マーク ▶ “Resume/Run”をクリックすると、プログラム実行がスタートします。 尚、各サンプルプログラムはデバッグを行いやすいように、main()の先頭にブレイクポイントを貼っています。 「数秒だけLEDが光る」（下図の黄色で囲ったLED）動作が確認できれば、今回のデバッグは成功です。 今回のDim Exampleのコードでは、“while (count++ < 10)”と指示されており、 count = 0 でスタート ループ1回ごとに count++ で増える count < 10 の間だけ動く つまり、最大10回LEDが光って動作が完了する、という中身になっているため、LEDが数秒だけ動作して止まるのが正常な挙動です。 ここまでで、RTDサンプルプロジェクトのビルドからデバッグ、そして実機ボード上での動作確認（LEDの点灯・消灯）までを一通り体験することができました。 さいごに 今回の一連の流れは、S32K3を用いた開発の基本ステップとなります。 コード生成 → ビルド → デバッグ → 動作確認 実際にボード上で動作を確認することで、ソフトウェアがハードウェアを制御していることをより直感的に理解できたのではないでしょうか。 この基本ステップをベースに、ご自身のアプリケーション開発へと発展させてみてください。 =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 今回の記事では、S32K3 Real-Time Driver内のLED点滅のサンプルプロジェクトを用いて、コード生成、ビルド、デバッグを行うことで、S32K3開発の「最初の一歩」を体験します。 この記事のゴール：S32K3 FRDMボード上でRTD内のサンプルをデバッグし、LEDを点滅させる （所要時間：15分） General Purpose Microcontrollers S32 Design Studio S32K SW | Downloads 日本語ブログ