Fallback mechanism for failed AB_SWAP update Hello, We are developing an application that uses the AB_SWAP mechanism of the HSE firmware on the S32K342 to perform OTA updates. We are currently activating the passive block once the passive region of the flash is entirely written to. We were wondering whether there is a fallback mechanism that we can use to verify/check whether the image we are booting from is corrupted, and if we can fallback to the 'known good' active region that has become the passive region after resetting. This arises from the fact that on some occasions, we overwrite the passive region without issuing a reset and midway through we reset the processor, resulting in a corrupted image in the flash.  Re: Fallback mechanism for failed AB_SWAP update Hey @lukaszadrapa , Thanks for the clarification. We are still trying to understand which type of secure boot strategy to use in our application. Advance Secure boot seems a bit complicated with having to install the SMR and CR. On the other hand, Basic Secure boot seems slightly easier to install but the exact implementation and installation details seem unclear. I was wondering if you could provide some insight into these options. I am referring to the HSE B Reference Manual and was also wondering if there is any additional documentation I should be referring to for this. Regards, Shiv Re: Fallback mechanism for failed AB_SWAP update Hi @Shiv_peak  I answered very similar question a couple of days ago, please take a look at: https://community.nxp.com/t5/S32K/S32K-OTA-Rollback/m-p/2400332/highlight/true#M60125 If you need more details, just let me know. Regards, Lukas

S32K314 CAN issue I am using S32K314  , and recently I got a issue about CAN when I doing  the test by short-circuiting of the oscillator ; after recovery  ,I monitored  SPI ,ADC ,these modules works OK, but CAN module can not work normally, the debuger show these information,  in this status, CAN can not receive or send any fram, how could this happened, and how to recover this fault by sw?   Re: S32K314 CAN issue Hi,  Thanks for your  reply . I try to add some test code in "Mcu_ClockSourceFailure_Notification" , but this notification do not be trigged; so from software side , how can we notice this issue happened then reset CAN Module? thanks Below is the value of the registers you mentioned: MCR CTRL1 CBT: FDCBT: ECR ESR1 Re: S32K314 CAN issue Hi, From the provided screenshot, the receive error counter (RXERRCNT) is increasing while TXERRCNT remains 0, which does not fully match a typical transmit-related issue even though ESR1 indicates a transmission attempt is ongoing. The oscillator short-circuit could potentially have affected the clocking, resulting e.g. in incorrect CAN bit timing after recovery. However, the current information is not sufficient to confirm this. Could you please provide: a wider view of the FlexCAN registers (including MCR/CTRL1/CBT/FDCBT, ECR and ESR1), the module and CAN protocol clock configuration after recovery, TX, RX and CAN bus measurements captured during the failure? If the FlexCAN module clock and the CAN protocol clock are running and have the expected frequency, you can also try performing a FlexCAN module software reset followed by a complete module reinitialization and check whether communication is restored. BR, Petr

PNEV5190B does not work After loading Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin from the "Load Secondary Firmware" option on the Extra tab of NFC Cockpit, my PNEV5190B no longer responds and cannot be operated from NFC Cockpit. According to the update log, the firmware download completed successfully without any reported errors. The board became unresponsive only after the update was finished. I found a similar issue in this thread, but I would like to understand the root cause. What could cause the board to become unresponsive even though the firmware update completed successfully? Is it possible that I used an incorrect secondary firmware image for my board or firmware version? Why does loading the secondary firmware result in a state where NFC Cockpit can no longer communicate with the board? Thank you for your support. Re: PNEV5190B does not work Hello @Miyazaki001 Hope you are doing well. Could you please provide more details on your setup? What is the procedure you are following? I tried the following setup: - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - "Extra" tab > "Secondary FW" tab > Load Secondary Firmware - Select NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin NFC Cockpit should indicate to close the COM port and open it again: After reopening the COM port, you should be able to start the Secondary Firmware in "Extra" tab. Regards, Eduardo.

MINISASTOCSI Latest Schematics Hi Team, Could you please help to share MINISASTOCSI latest schematics?

S32K144: Selecting SPLL Clock Source between SOSC and FIRC in clock configuration tool Hello community,  I´m currently working with the s32k144 microcontroller using the clock configuration tool in s32 Design Studio. I would like to clarify if it is possible to select the reference clock source for the SPLL, between the SOSC and the FIRC, and if so, what is the proper procedure or configuration steps to achieve this in the tool. thank you. Re: S32K144: Selecting SPLL Clock Source between SOSC and FIRC in clock configuration tool Hi@ernesto97xn Can I understand your question as asking if the external input frequency can be between 8 and 48 MHz? This is possible. You can use a separate clock chip as the clock source for the S32K1, with a frequency range between 4 MHz and 40 MHz. As shown in the diagram below, you can try directly modifying the SOSC frequency. Re: S32K144: Selecting SPLL Clock Source between SOSC and FIRC in clock configuration tool Thank you for you respons. My question was specifically about the clock source accepted by the SPLL. I was reading the manual, and what I found is that, for the S32K144 family, this particular clock configuration is only supported on the S32K144W variants, as shown in the image on the left. Re: S32K144: Selecting SPLL Clock Source between SOSC and FIRC in clock configuration tool Hi@ernesto97xn These info can be found in S32K1xx-RM， chapter ：27.2 High level clocking diagram

MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification Hello Team, We have selected the MIMXRT1176 for our application and are currently using the MIMXRT1170-EVKB for evaluation and software development. Our custom board design is currently in progress, and we would like to clarify a few points before finalizing the hardware design. Q1: Using the EVKB Onboard Debugger with a Custom Board Is it possible to use the onboard debugger on the MIMXRT1170-EVKB to program and debug a custom RT1176-based board, or would a separate debugger be required? We expect this to be possible, but would appreciate confirmation from the NXP team. Additionally, could you please provide: The jumper settings that need to be modified on the EVKB. Any hardware changes required to disconnect the onboard debugger from the EVKB target MCU and route it to an external target. Details of the SWD/JTAG signals that should be connected to the custom board. As a practical test before our custom hardware arrives, we currently have two MIMXRT1170-EVKB boards (Board-A and Board-B). We would like to perform the following experiment: Use the onboard debugger of Board-A to program and debug the RT1170 MCU on Board-B. Similarly, use the onboard debugger of Board-B to program and debug Board-A. Could you please confirm whether this setup is supported and provide the required jumper settings and hardware modifications to achieve it? Q2: Verification of the Serial Downloader Path We would also like to verify our understanding of the Serial Downloader (SDP) mode implementation on the RT1170. From the EVKB schematic, it appears that jumpers J114 and J115 connect to LPUART1_RX and LPUART1_TX, respectively. If we remove these jumpers and connect an external USB-to-UART TTL adapter to the MCU side signals, and while Keeping the MCU in SDP mode can we: Use MCUXpresso Secure Provisioning Tool (SPT) or Boot Utilities to download and program images through the UART interface? We would appreciate confirmation that this is a valid flashing and recovery method for both the EVKB and our upcoming custom hardware. Thank you for your support and guidance. Best regards, Ruthvik R Re: MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification Hi @mayliu1 , Thank you for reply. Regarding Q1 : We will Be getting an external Debugger/Flasher. we wanted to know the if using the onboard debugger was possible in case we wanted to use it Regarding Q2 : We will Proceed ahead with testing the recovery SDP path. Thanks and Regards, Ruthvik Re: MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification Hi @Littell , Thank you for your reply and honest opinion.  Thanks and regards, Ruthvik Re: MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification Hi @ruthvik_1 ， Thank you so much for your interest in our products and for using our community. A1: In principle, it is possible. However, this approach may require additional jumper configuration and hardware connection changes on the EVKB, which should be verified against the EVKB schematic. Therefore, we would generally recommend reserving a standard SWD/JTAG header on the custom board and using a dedicated external debugger, such as a J-Link or P&E Multilink, for development and debugging. A2: Based on the EVKB schematic, your understanding of the Serial Downloader path appears to be correct. RT1170 SDP mode supports image download through the ROM bootloader interfaces, including UART and USB. Based on the EVKB schematic, J114 and J115 are associated with the LPUART1 connection path. For UART SDP, the signals are: LPUART1_TX: GPIO_AD_24 LPUART1_RX: GPIO_AD_25 Therefore, after disconnecting J114/J115 on the EVKB, it should be possible.  Please ensure voltage-level compatibility, crossed TX/RX connections, and a common GND connection. Best Regards May Re: MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification Regarding "Q1: Using the EVKB Onboard Debugger with a Custom Board", that approach is just silly given the trivial cost of an MCU-Link.  You're compromising your base development boards and will regret it. Re: MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification Hi @mayliu1 , Thanks for the reply. We will be going with an external NXP MCU-Link Debug Probe. Thank you for the clarification. Thanks and Regards, Ruthvik  Re: MIMXRT1170-EVKB Debugger Usage with Custom Board & Serial Downloader Verification While it may be possible in principle, using the onboard debugger on one EVKB to debug another target board is not a recommended use case by NXP. We recommend reserving standard SWD/JTAG interfaces on the custom board and using a dedicated external debugger, such as J-Link, P&E Multilink, or MCU-Link, for development and debugging.

K312 RTD3.0.0到RTD6.0.0 IIC部分驱动更换 Hi  当前我在RTD3.0.0中遇到了一个IIC  从机时钟挂起的问题，发现与IIC 的时钟延展功能相关，经过FAE的推荐，说6.0.0驱动中没有这个问题，因为项目周期原因，基于最小更改原则，我将 IIC的相关驱动文件从6.0.00中摘出，放到的我3.00 RTD 中，但是我发现无法正常运行。更改完成后，IIC一旦接收到数据，就无法退出中断。 我想请问： 1 、是否有人曾经尝试过这样的操作（3.00RTD 更换部分驱动为6.00），你们是否支持这样的更改，我还有别的关联驱动未移植吗？ 2、我发现 在6.0.00中有一个IIC的更改项目， 它在4.00中被修复了 5.00继承了这个修复，但是6.00又恢复到了3.00的逻辑，但是我在6.00的release note中并没有发现它的相关描述，请问6.00是做了其他更改修复了这个bug吗？ static void Lpi2c_Ip_SlaveIRQHandlerInternal(uint8 Instance) { LPI2C_Type *BaseAddr; Lpi2c_Ip_SlaveStateType * Slave; boolean StopDetect = FALSE; boolean RepeatStartDetect = FALSE; BaseAddr = Lpi2c_Ip_pxBase[Instance]; Slave = Lpi2c_Ip_pxSlaveState[Instance]; StopDetect = LPI2C_Get_SlaveSTOPDetectEvent(BaseAddr); RepeatStartDetect = LPI2C_Get_SlaveRepeatedStartEvent(BaseAddr); /* Check address valid and tx/rx event */ Lpi2c_Ip_SlaveCheckDataEvent(Instance, BaseAddr, Slave); if (RepeatStartDetect) { Slave->RepeatedStarts++; if ((1U == Slave->RepeatedStarts) && (Slave->Is10bitAddress))  //  此处  在4.00中已修改 { RepeatStartDetect = FALSE; LPI2C_Clear_SlaveRepeatedStartEvent(BaseAddr); } } if ((TRUE == StopDetect) || (TRUE == RepeatStartDetect)) { /* Stop/repeated start detected */ Lpi2c_Ip_SlaveStopDetectHandler(BaseAddr, Slave); if (TRUE == StopDetect) { /* reset repetead starts for a new transfer */ Slave->RepeatedStarts = 0U; } } /* Check for slave errors */ Lpi2c_Ip_SlaveCheckErrorEvent(BaseAddr, Slave); } 关联bug ：ARTD-6112

IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hello,     we are bringing up Bluetooth on a Verdin i.MX95 WB running the NXP Android 15 BSP (Linux 6.6.58). The onboard wireless module is a u-blox MAYA-W260 based on NXP IW612. Wi-Fi works correctly over SDIO, and the combo firmware is successfully loaded: Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active ,Bluetooth instead does not appear to work. Whenever we enable it on Android settings, the UI switch is frozen and no BT device is found. Bluetooth is connected to LPUART6 (/dev/ttyLP5). The NXP vendor HAL opens the UART successfully. We initially found that hardware flow control blocked transmission; after temporarily disabling CRTSCTS, the HAL sends the four-byte HCI Reset command: 01 03 0c 00 The UART counters then show: tx:4 rx:0 No response is received from the IW612. The same result occurs with a direct manual UART test at 115200 baud, 8N1, without hardware flow control. Our current configuration is: mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 enable_download_fw is left disabled because the combo firmware is already downloaded by the Wi-Fi driver. Could you please clarify: After loading sduart_nw61x_v1.bin.se through SDIO, should the IW612 Bluetooth UART respond directly to an HCI Reset at 115200 baud? Is a boot-sleep trigger, wake command, vendor command, or another initialization sequence required first? Is hardware flow control mandatory for IW612, and what should the expected CTS state be after firmware initialization? Should we use the UART firmware-download path with uartspi_n61x_v1.bin.se instead of relying on the combo firmware loaded by Wi-Fi? Is there a recommended bt_vendor.conf for IW612 on i.MX95? Any reference configuration or expected UART trace would be very helpful. Best regards. Android Linux Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  1. After loading sduart_nw61x_v1.bin.se through SDIO, should IW612 Bluetooth UART respond directly to HCI Reset at 115200? In principle, yes — once the combo firmware is active and the BT UART block is awake/ready, the controller should respond to HCI Reset with a Command Complete event. 2. Is a boot-sleep trigger, wake command, vendor command, or other initialization sequence required first? For normal Android bring-up, do not rely only on manually sending HCI Reset. Let the NXP vendor HAL or NXP UART driver perform the initialization sequence. 3. Is hardware flow control mandatory for IW612? What should CTS state be? For a production IW612 BT UART design, hardware flow control should be enabled and correctly wired. Disabling CRTSCTS is useful only as a diagnostic step; it should not be considered the final fix. 4. Should we use uartspi_n61x_v1.bin.se instead of combo firmware loaded by Wi-Fi? You  can have a try with the seperate FW to debug the issue, but it should not the root cause. With combo FW, should also work as expected. 5.Let me have a try on my local side then share to you a worked on my side conf file to you. Please allow me some time. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  How is your side? I took some time to prepare the environment to build Android 16 source code. Now I can build it, it will need some time to finish building, please allow me some more time. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi， @vins-idg  Sorry for my late reply and thanks for your patience. I already finished the local test on my side, and now IW612 can work fine on my I.MX95-19*19-EVK. Because there is no Verdin board，I use I.MX95-19*19-EVK to finish the test. Below is the bt_vendor.conf screenshot and also you can see BT can work fine on the right side. In fact, I just use the default bt_vendor.conf and do not modify anything in it. Hope it can help you somehow. If it still could not work on your side, please help to provide me your dts and also dmesg logs for further checking. Because here, the community is a public place, to save your security info, you can send your dts file to my private working email: [email protected].  Best regards, Christine.

ddr_stress_tester cannot work on some DDRs I have been using  ddr_stress_tester tools for many years, this year, I found the tool cannot work well on some newer manufacturing process DDRs, (20nm or 25nm DDRs),  we found that the binary will hang when I select cpu frequency. For example, winbond  w631gu6rb and ISSI IS43TR166640C-125JBLI-TR. by the way  CPU model is mx6solo/dl i.MX6DL

Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Dear Everyone, I would like to ask for any possible reason why does our flash driver fail in one specific situation. We use custom board with IMXRT1176, our board is based on Embedded Artists carrier board for that MCU. In our project there are two partitions in flash, 0x30100000 and 0x30200000. We use MCU-Link and Linkserver to flash binaries. Binaries are signed with --confirmed in this case. We have a FLASH remap functionality enabled so no swap is performed. We observe two situations: 1. If there is a bootloader in flash and an image in partition 1, everything works as expected. 2. Once we complete the OTA upgrade and MCUboot boots new image from a second partition, we can no longer write to FLASH partiton 1 as we get an error from linkserver: ================================================= Nc: Opening flash driver MIMXRT1170_SFDP_QSPI.cfx (already resident) Nc: Sending VECTRESET to run flash driver Nc: Flash variant 'iMXRT1170_SFDP_FlexSPI1_A_QSPI May 15 2026 18:32:39' detected (16MB = 256*64K at 0x30000000) Pb: 1 of 1 ( 0) Writing sectors 16-31 at 0x30100000 with 1048576 bytes Ps: ( 0) at 30100000: 0 bytes - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc 1 - Operation failed Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc 1 - Operation failed Note that I have erased the first partition with erase-range. I also can confirm that when our firmware does it with flash driver it works as expected. It fails only when i try to do it with the linkserver manually =================================================== Q1. Is there any obvious reason for it? Should we always erase partition 2 or both paritions? Q2. If we have binary built for slot1, does this binary work when we attach to the core which runs with image in partition 2? Does Flash remap make it work? Thanks in advance for any help, Best Regards! Jakub Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hello Gavin, thank you very much for your response! You really helped me to understand these concepts. If it's possible, could you please help me figure out one more thing? This is partition info i get after OTA: =========== Image 0; name APP; state Permanent: Slot 0 APP_PRIMARY; offset 0x100000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: C825709456C098E38090... log_addr 0x30100000 remaps to 0x30200000 Slot 1 APP_SECONDARY; offset 0x200000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: EBFCCC0D3E970230E404... log_addr 0x30200000 remaps to 0x30200000 *ACTIVE* =============== Then I run this script to clear slot0 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 According to what you said, i expected to erase slot1 because remap overlay is active. However that's not the case. What i got after power reset is: ========= Flash REMAP_OVERLAY active. Image 0; name APP; state None: Slot 0 APP_PRIMARY; offset 0x100000; size 0x100000 (1048576): Slot 1 APP_SECONDARY; offset 0x200000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: EBFCCC0D3E970230E404... log_addr 0x30200000 remaps to 0x30200000 *ACTIVE*========= I still can't write anything to slot0 which is unexpected. Is it possible that erase bypasses the logical mapping of remap but load doesn't? Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hi @jslota13245 , Thanks for your interest in NXP MIMXRT series! Based on the information you provided, I believe the following reasons should be considered. The failure is caused by the FlexSPI remap still being enabled after OTA. When MCUboot boots slot1 (partition2) via remap, it leaves remap on into the application. LinkServer's  .cfx  flash driver programs through the AHB logical address, so the remap silently redirects your write to  0x30100000  (partition1) to physical  0x30200000  (partition2) — which already holds the confirmed image and is not blank. NOR flash cannot overwrite it. Your earlier  erase-range 0x30100000  actually erased partition2 for the same reason. Your own firmware works because it programs via FlexSPI IP command mode with explicit physical offsets, bypassing the remap. Note: VECTRESET / debugger attach do not clear the remap — only a POR or an explicit register write does. Q1: Which partition to erase? The key is to disable remap first, not just erasing partitions. Recommended: Before programming with LinkServer, clear the remap registers; Then erase both partitions (slot0 and slot1). Because direct-XIP selects the highest version, a stale image left in slot1 will make MCUboot pick it again and re-enable remap, so the problem returns; Q2: Will a slot1 binary work when attached to a core running the partition2 image? The image should be linked once for the primary slot ( 0x30100000 ); the same binary runs from either slot via remap — no separate slot1 build is needed. When you attach for debug, remap keeps logical addresses consistent, so code reads/breakpoints work fine. However, the same remap changes the physical target when writing flash, so you must disable remap before programming slot0 with LinkServer. Best regards, Gavin Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled @Gavin_Jia  Dear Gavin, could you please have a look at my comment to your response and let me if we missed something? Thanks a lot for your help! Best Regards, Jakub Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hi @jslota13245 , Apologies for missing your previous message. Unfortunately, once an answer is marked as accepted, the system automatically considers the issue resolved, and I no longer receive updates on the case. Please accept my sincere apologies for the oversight. I will try to reproduce the issue on my side. Please allow me some time to investigate, and I will keep you informed of any findings or progress. Thank you in advance for your patience and understanding. Best regards, Gavin Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hi @jslota13245 , Hope you are doing well! I continued to look into the matter further, and this post offers some preliminary conclusions: https://www.cnblogs.com/henjay724/p/13538105.html Erase and program are not affected by the remap. Both go through FlexSPI IP commands on physical addresses, so your erase-range 0x30100000 really did erase the physical slot0 — that is why slot0 shows No Image Found and slot1 is intact. My earlier wording about erase hitting slot1 was not accurate, sorry for that. The reason the write still fails is the read-back verify, not the write itself. I believe the simplest solution is still to disable the remap function before flashing the image. Alternatively, after flashing, use an IP command to read back the data from memory; if it matches the data that was written, this proves that the failure was merely due to the AHB checksum being cheated. In addition, the official statement supports the earlier speculation: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/examples/ota_examples/_doc/flash_remap_readme.html#mcuboot-and-flash-remapping-feature

Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Subject: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi, I am trying to configure and program the OTP on the FS2400 using the KITFS24SKTFDMEVM evaluation board. Evaluation board: https://www.nxp.com/design/design-center/development-boards-and-designs/KITFS24SKTFDMEVM However, when I connect the board to the NXP GUI, I am unable to establish communication with the device. The GUI reports the error shown below, and no communication takes place. I have previously used the same NXP GUI with the FS26 evaluation board without any issues, so I believe my PC setup and GUI installation are working correctly. The evaluation board is in its default configuration, and I have not intentionally changed any jumper or switch settings. To verify, the current configuration is as follows: S12 (OTP): OFF J30: Pins 1-2 connected SW4 (WAKE2): ON S19 (WAKE3): ON J33: Open J37: Pins 2-3 connected J36: Pins 2-3 connected J10: Pins 2-3 connected SW9: All switches ON J45: Pins 2-3 connected J26: Pins 5-6 and 9-10 connected SW20: All switches OFF S2: ON (I could not locate this switch in the schematic ) SW18: All switches ON SW1 (Main Power Switch): Position 3 (2-3) I have not programmed the S32K144 MCU on the evaluation board. My understanding is that the board is shipped with the required firmware already programmed. Could someone confirm whether this is correct, or whether the MCU needs to be flashed before the GUI can communicate with the FS2400? Below is the error message displayed by the GUI: Any help would be greatly appreciated. Thank you. FS85&FS84 FSBC+PMIC Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hello, Thank you for contacting us. Could you please update the firmware according to Section 5, "Installing and Configuring Software and Tools," of the UM12015 KITFS24SKTFDMEVM User Manual? This procedure should resolve the error you are experiencing. If the issue persists after completing the update, could you please provide a picture of your hardware setup? This will help us review the configuration and investigate the problem further. Thanks!

Software bring-up on custom hardware implementing RT-1170 Hi! I'm trying to get started with software development on the RT-1170 platform, but have run into problems when trying to configure booting from external flash on my custom board. To divide the problem I went back to the EVKB-board and tried getting a small (and verified on EVKB) program working using a barebones project (i.e. without the default files). It seems that I can program the flash by simply adding the region under "Edit project settings > MCU settings > memory details", but when I cycle power to the board it locks up and I have to switch to a different boot mode (serial downloader) to recover the MCU with an EVKB-example project. Could I please get some help with figuring out what is going wrong? Is there a software development guide for the imxrt MCUs similar to the hardware development guide (MIMXRT1170HDUG)? I of course know about the refernce manual but a checklist would have been nice for someone who has not gone through the "metal to hello world"-process onb this platform before. I have attached an export of the project. Thank you in advance! Re: Software bring-up on custom hardware implementing RT-1170 Hello @Henrik12345, In order to support you better, could you please provide me the following information? -Are you able to debug your project? -Which SDK version are you currently using? -Which flash device are you using? Is it the same one used on our EVK? If not, have you made any modifications to support your flash device? -I understand that you are using MCUXpresso IDE. Is my understanding correct? If so, could you please let me know which version you are currently using? Regarding your question about software development, there is no document equivalent to the Hardware Development Guide. However, you can take the SDK examples as a reference, as they provide demonstrations of the peripherals available on the RT1170. You can download the SDK through the SDK Builder. Instructions on how to obtain it are available in Part 2 "Get Software" of the Getting Started with the i.MX RT1170 Evaluation Kit. Although this guide is designed for the RT1170-EVK, it can also be used as a reference for the RT1170-EVKB. The SDK includes a project template that can be used as a starting point for your development. As shown the following image:   BR Habib Re: Software bring-up on custom hardware implementing RT-1170 Hello @Henrik12345, Additional changes are required if you want to boot from a different external flash device. I would recommend reviewing the following app notes to better understand the boot process and the image structure required for external flash devices. Although these app notes are designed for the RT1050, you can use them by reference for the RT1170: How to Enable Debugging for FLEXSPI NOR Flash AN12108: How to Enable Boot from QSPI Flash – Application Note The RT1170-EVKB only has incorporated the following memories:   As you may know each memory has specific commands to performing read, write or erase operations. For this reason, the LUT and drivers related to the RT1170-EVKB may not be compatible with your flash device. To properly evaluate your flash, you will need to perform the tests on your custom board.  I can suggest you use the Boot Memory Configuration feature in the MCUXpresso Secure Provisioning Tool v26.06. This feature allows you to test different flash configurations and generate the boot memory settings required by your device. Once you have completed the tests, please let me know the results. As a first step, I recommend verifying the communication with your MCU by following the instructions in the "Connection" section of the tool documentation. Please note that Secure Provisioning Tool supports communication through USB and UART, as it works through blhost commands for device access. Are you able to connect your custom board through either USB or UART? BR Habib Re: Software bring-up on custom hardware implementing RT-1170 Hi Habib! To clarify some things, I work with two different boards: The custom board which I have designed myself MIMXRT1175AVM8A DDR QSPI NOR flash, specifically the FS-S (1.8 V) series from Infineon Boot pins are strapped to BOOT_MODE = Internal Boot FLEXSPI_INSTANCE = FLEXSPI1 xSPI_FLASH_TYPE = Boot with default 0x03 Read Enabled FLASH_PROBE_TYPE = QuadSPI NOR ENCRYPT_XIP_EN = 0 FLASH_AUTO_PROBE_EN = 0 The official RT1170-EVKB kit Same boot pin settings I was not able to write to the flash memory on my custom board immediately so I tried to bring up the EVKB kit from scratch instead, which has not worked out. Are you able to debug your project? I'm able to debug the program on immediately after writing to flash on the EVKB-board and the program works as intended, but when I cycle power the core locks itself which leads me to believe that the boot rom program gets stuck. Probably by a bad header/data in the flash memory. I know that I'm able to write to the flash memeory as I can extract the data from the flash memeory and see that it changes between a working demo from the SDK and my "from scratch" program (which was the one I attached before). Which SDK version are you currently using? Which flash device are you using? Is it the same one used on our EVK? If not, have you made any modifications to support your flash device? No, it is not the same. See hardware specifics in answer for question 1. The only thing I modified was that I added the flash region in "Memory Details" under "MCU Settings" in the Project settings. I used the same driver script as the EVKB kit (MIMXRT1170_SFDP_QSPI.cfx) I understand that you are using MCUXpresso IDE. Is my understanding correct? If so, could you please let me know which version you are currently using? Yes, I'm using MCUXpresso v25.6.136 I'll try to use the demo project template and see if that solves the issue. How would I need to change this template to adapt it to my flash memory and MCU part number? BR Henrik

UWB Single beacon + AoA for doorway inside/outside detection advice I'm building a wall-mounted single-anchor UWB system (doorway exit-detection use case) that needs to determine whether a tag is inside or outside a doorway using AoA — including doors that are already open, so I can't gate on a door contact sensor. Background: I was running Qorvo QM33120W/DW3000 (2-antenna PDoA) and hit a hard architectural wall; with the anchor mounted ~7ft up facing straight down, walking/circling under it produces false "outside" angle commits even on clean, strong signal. My plan was to have the UWB antennas face directly down toward the ground so that I can capture both positive and negative angles (inside and outside) signals to determine when a tag moves from inside to outside (exit detection). Currently with the Qorvo devices, if I hold the tag in the optimal straight forward/antenna on top, everything is fine but when moving/rotating the tag (DW3000), I start seeing different AoA values even when standing in the same place. Sign convention issue: My expectation is a consistent convention — positive angle while inside, negative once the tag crosses to outside. In practice, while unambiguously still inside, I'm seeing both positive and negative angles, correlated with the tag being rotated and moved in random directions/speeds — not with actual crossing of the doorway. This is the specific symptom I'm trying to design around before committing to new hardware. I'm now evaluating a move to NXP silicon and would appreciate community input: Qorvo 2D AoA boards use an RF switch to capture the UWB PDoA between the two antennas. Will switching to the NXP SR150 dual rx chain solve my AoA jumping issues? For a single overhead-mounted anchor with a tag moving through a doorway below it, is SR150's 2D/software-assisted-3-antenna-3D AoA mode sufficient to resolve front/back ambiguity, or does this really need SR250's 3 simultaneous RX chains for a true second baseline? Any recommended antenna geometry/mounting orientation for this specific top-down overhead use case? Any real-world experience with SR150's antenna-switched 3rd-antenna mode vs. SR250 in ambiguity-prone geometries like this? Thanks. Re: UWB Single beacon + AoA for doorway inside/outside detection advice Hello, Hope you are doing well. For a single overhead-mounted anchor doing inside/outside doorway detection with a freely rotating tag, the Trimension SR250 is the right platform and is our recommended UWB product for IoT and Industrial anchor designs. The core reason for this recommendation is hardware architecture. The SR250 integrates 3 simultaneous RX paths for one-shot 3D AoA with no external RF switches required, delivering both azimuth and elevation from a single ranging frame. The SR250 also brings additional capabilities that are valuable for this use case: 360° AoA support with antenna diversity up to 9 antennas On-chip UWB radar (OCPD) for presence detection, a useful complementary layer alongside ranging-based crossing detection FiRa 4.0 and Aliro 1.0 ready, ensuring interoperability with the broader UWB ecosystem Where to Start Dev kit: SR250 Development Board, Arduino-compatible, integrated PCB antennas, plug-and-play demos for ranging, AoA, and radar out of the box Software: SR250 UWBIOT for Zephyr OS Partner modules & kits: TrueSense (ETNA TS 250 DevKit), MobileKnowledge (MK UWB Kit Mobile edition 2.0), Amotech (SR250 Integrated 3D Antenna Module), all available via the NXP Partner Marketplace Hope this helps. Best Regards, Ricardo Re: UWB Single beacon + AoA for doorway inside/outside detection advice Thanks Ricardo, appreciate the detailed response. Update: I've ordered both the Murata Type2BP (SR150) dev board and the NXP SR250UWBSHIELD dev board. Unfortunately, the SR250UWBSHIELD is showing a 14-week backorder on my end, so I'll be starting bench work on SR150 in the meantime and moving to SR250 once it arrives. A few follow-ups while I wait: 1. SR150 vs. SR250 for my specific application: given that I only need azimuth (inside/outside), not elevation, what benefit would I actually see moving from SR150 to SR250 beyond the architecture difference (true 3 simultaneous RX chains vs. SR150's 2 native chains + switched 3rd antenna)? Is the accuracy/stability improvement meaningful enough for a single-axis use case to justify the wait, or would SR150 likely get me there on its own once I have my mounting/multipath mitigations in place? 2. RF switching and tag rotation: one specific symptom I'm trying to root-cause, on the Qorvo hardware, if I stand in exactly the same spot and just rotate the tag on the X plane (no position change at all), the AoA value jumps around noticeably even appearing to flip polarity. Qorvo's 2D AoA uses an RF switch to time-multiplex the two antennas rather than sampling them simultaneously. Do you think that switching architecture is a likely contributor to this rotation-correlated instability, or is this more consistent with something else (tag radiation pattern/polarization sensitivity as it rotates, multipath, etc.)? Trying to understand whether SR150/SR250's simultaneous RX sampling would be expected to resolve this specific symptom or if it's a separate issue I'd need to address regardless of chip. 3. 2D vs. 3D AoA for my use case: since I only need to know inside vs. outside (azimuth), and elevation isn't meaningful for my application, is there any accuracy or reliability benefit to running full 3D AoA anyway, or would I be better off configuring azimuth-only and ignoring elevation? Specifically wondering if the elevation measurement helps discriminate reflected/NLoS signals from valid ones even if I don't use elevation for the actual inside/outside decision. 4. Power draw, 2D vs. 3D: this will be a battery-powered install. Is there a meaningful current draw difference between running 2D-only vs. full 3D AoA on SR250, given it's 3 simultaneous RX chains either way? Or is the power cost basically fixed once all 3 chains are active regardless of which axes I use in software? 5. Multipath mitigation for my specific install: the beacon will be wall-mounted above a doorway with a nearby glass door and a ceiling roughly 5ft above the unit. I've been seeing what looks like reflection-driven angle instability on my current Qorvo hardware (correlates with tag rotation, worse in higher-ceiling rooms, worse with the glass door closed). Any recommended mounting practices, antenna beamwidth/pattern choices, or firmware-side filtering (FOM/NLoS thresholds) specifically for suppressing near-field reflections off glass and adjacent walls? Or are there any features on either the NXP SR150 or SR250 that would suppress this issue? 6. Radar-based motion gating for battery savings: I'd like to use SR250's on-chip radar (OCPD) purely as a low-power wake trigger: stay in radar mode, only spin up full ranging/AoA once motion is detected. With the anchor mounted above a ~2m-high doorway, antennas facing straight down, roughly what motion detection range/coverage should I expect directly below the unit? Trying to size the radar's effective "wake zone" against the doorway footprint. I would want to detect movement as the person is walking toward and away from the doorway. Thanks again for the help.

S32K396 and FS26 REG_CORRUPT Dear All, I'm trying to get rid of the REG_CORRUPT' flag on the FS26 - the two snip pictures attached show a read of all the relevant registers. Immediately prior to the first 'AE' read command, I have just done a successful first kick of the watchdog to take the FS state machine out of INIT_FS such that the fail-safe register state is assessed for correctness, and you can see from the 0x28 answer that we are in debug mode with the REG_CORRUPT bit set. I am certain the watchdog kick was successful because I read FS_DIAG_SAFETY1 straight after the kick - returned value is 0x0103 - no error flags, just ABIST1_OK and LBIST_STATUS = OK. After the 0xAE command, I issue an 0xAF attempting to write 0x1800 to the register to clear the OTP_CORRUPT and REG_CORRUPT bits, and then I do a read of all 12 FS registers in order starting at register 0x41 (obviously the command is 0x82 when shifted). I have looked at the values returned from these registers and I can't see a consistency problem with the returned values (obviously taking into account the bits that we're not supposed to write to and bits that are held/reserved/0/1). You can see from a final read of FS_STATES at the end that REG_CORRUPT is still set. Sorry to ask such a direct question, but what am I missing? Kind Regards, Andrew    Re: S32K396 and FS26 REG_CORRUPT Dear Erika, Thanks for responding - I have checked that many times already, which is why I posted the complete state of the registers in the images of my original posting. Please let me know if you think there's an issue with how these are configured. As far as I can tell, the registers are correct (taking into account only the bits that are writable according to the datasheet). I assume the chip itself takes care that the read-only bits are in a valid state, and I assume the bits that are specified as '0' or 'reserved' are not writable. Is it possible that a write to one of those bits can cause the REG_CORRUPT bit to remain asserted? Kind Regards, Andrew Re: S32K396 and FS26 REG_CORRUPT Hello! For REG_CORRPUT bit, it will be asserted shown as below, meaning when FS registers are configured, a NOT register is must to be configured together With XOR rules. Please check if there are some register configuration did not follow the rules that cause this bit asserted ?

Errata ERR053404: Use Cases for Different Message Buffer Configurations This article discusses the different use cases and configuration of the errata "ERR053404: FlexCAN: Message Buffer (MB) and Enhanced RX FIFO Filter Element (ERFFEL) Memory Corruption". The errata is impacting Messabe Buffers (MB) and Enhanced RX FIFO Filter Elements (ERFFEL), the impact of each MB or ERFFEL depends on the configuration of the payload buffer, MB and/or ERFFEL. In this post, we plan to provide some examples of such configuration and impact on the FlexCAN IP.  Taking a 64-byte payload as an example, the following configurations illustrate the trade-off between the number of Message Buffers (MBs) and acceptance filters: /* ERR053404: This errata explains affected words depends on MB payload size, this example applies for MB configured for 64-byte payload */ #define BYTES_IN_MB kFLEXCAN_64BperMB FLEXCAN_FDInit(EXAMPLE_CAN, &flexcanConfig, EXAMPLE_CAN_CLK_FREQ, BYTES_IN_MB, true); 1. MB0 is not used, MB1 is used. In this configuration, ERFFEL[0–29] can be fully utilized as acceptance filters, while MB1–MB6 are available as Message Buffers, maximum ERFCR[NFE] is 14. The following code can be used as reference for the driver configuration for this case.  /* Config fifo filters to make it accept STD frame with ID 0x123 ~ 0x140. Used ERFFEL[0–29], ERFCR[NFE]=14 */ uint32_t rxEnFifoFilter[] = {FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x123, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x124, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x125, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x126, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x127, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x128, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x129, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12A, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12B, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12C, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12D, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12E, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12F, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x130, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x131, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x132, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x133, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x134, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x135, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x136, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x137, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x138, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x139, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13A, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13B, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13C, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13D, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13E, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13F, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x140, 0, 0x3F, 0)}; flexcan_enhanced_rx_fifo_config_t rxEhFifoConfig; flexcan_rx_mb_config_t mbConfig; /* Setup Enhanced Rx FIFO. */ rxEhFifoConfig.idFilterTable = rxEnFifoFilter; rxEhFifoConfig.idFilterPairNum = sizeof(rxEnFifoFilter) / sizeof(rxEnFifoFilter[0]) / 2U; rxEhFifoConfig.extendIdFilterNum = 0; rxEhFifoConfig.fifoWatermark = RX_MESSAGE_COUNT - 1U; /* Reduce the frequency to enter IRQ. */ rxEhFifoConfig.dmaPerReadLength = kFLEXCAN_19WordPerRead; rxEhFifoConfig.priority = kFLEXCAN_RxFifoPrioHigh; FLEXCAN_SetEnhancedRxFifoConfig(EXAMPLE_CAN, &rxEhFifoConfig, true); rxFifoXfer.framefd = &rxFrame[0]; rxFifoXfer.frameNum = RX_MESSAGE_COUNT; /* Set Rx Masking mechanism for MB. Only accept data frame with desired ID. */ FLEXCAN_SetRxMbGlobalMask(EXAMPLE_CAN, FLEXCAN_RX_MB_STD_MASK(0x7FFU, 0, 0)); #define RX_MESSAGE_BUFFER_1 (1U) /* Setup Rx Message Buffer 1. */ mbConfig.format = kFLEXCAN_FrameFormatStandard; mbConfig.type = kFLEXCAN_FrameTypeData; mbConfig.id = FLEXCAN_ID_STD(0x121U); FLEXCAN_SetFDRxMbConfig(EXAMPLE_CAN, RX_MESSAGE_BUFFER_1, &mbConfig, true); 2. MB0 and MB1 are not used. In this case, ERFFEL[0–31] are available for acceptance filtering, and MB2–MB6 are reserved as Message Buffers, maximum ERFCR[NFE] is 15. The following code can be used as reference for the driver configuration for this case.  /* Config fifo filters to make it accept STD frame with ID 0x123 ~ 0x142. Used ERFFEL[0–31], ERFCR[NFE]=15 */ uint32_t rxEnFifoFilter[] = {FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x123, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x124, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x125, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x126, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x127, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x128, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x129, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12A, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12B, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12C, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12D, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12E, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12F, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x130, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x131, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x132, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x133, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x134, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x135, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x136, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x137, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x138, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x139, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13A, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13B, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13C, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13D, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13E, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x13F, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x140, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x141, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x142, 0, 0x3F, 0)}; flexcan_enhanced_rx_fifo_config_t rxEhFifoConfig; /* Setup Enhanced Rx FIFO. */ rxEhFifoConfig.idFilterTable = rxEnFifoFilter; rxEhFifoConfig.idFilterPairNum = sizeof(rxEnFifoFilter) / sizeof(rxEnFifoFilter[0]) / 2U; rxEhFifoConfig.extendIdFilterNum = 0; rxEhFifoConfig.fifoWatermark = RX_MESSAGE_COUNT - 1U; /* Reduce the frequency to enter IRQ. */ rxEhFifoConfig.dmaPerReadLength = kFLEXCAN_19WordPerRead; rxEhFifoConfig.priority = kFLEXCAN_RxFifoPrioHigh; FLEXCAN_SetEnhancedRxFifoConfig(EXAMPLE_CAN, &rxEhFifoConfig, true); rxFifoXfer.framefd = &rxFrame[0]; rxFifoXfer.frameNum = RX_MESSAGE_COUNT; 3. MB0 and MB1 are both used. Under this configuration, only ERFFEL[0–11] can be used as acceptance filters. ERFFEL[12–31] are not available, while MB0–MB6 can be used as Message Buffers, maximum ERFCR[NFE] is 5. The following code can be used as reference for the driver configuration for this case.  /* Config fifo filters to make it accept STD frame with ID 0x123 ~ 0x12E. Used ERFFEL[0–11], ERFCR[NFE]=5 */ uint32_t rxEnFifoFilter[] = {FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x123, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x124, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x125, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x126, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x127, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x128, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x129, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12A, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12B, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12C, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12D, 0, 0x3F, 0), FLEXCAN_ENHANCED_RX_FIFO_STD_MASK_AND_FILTER(0x12E, 0, 0x3F, 0)}; flexcan_enhanced_rx_fifo_config_t rxEhFifoConfig; flexcan_rx_mb_config_t mbConfig; /* Setup Enhanced Rx FIFO. */ rxEhFifoConfig.idFilterTable = rxEnFifoFilter; rxEhFifoConfig.idFilterPairNum = sizeof(rxEnFifoFilter) / sizeof(rxEnFifoFilter[0]) / 2U; rxEhFifoConfig.extendIdFilterNum = 0; rxEhFifoConfig.fifoWatermark = RX_MESSAGE_COUNT - 1U; /* Reduce the frequency to enter IRQ. */ rxEhFifoConfig.dmaPerReadLength = kFLEXCAN_19WordPerRead; rxEhFifoConfig.priority = kFLEXCAN_RxFifoPrioHigh; FLEXCAN_SetEnhancedRxFifoConfig(EXAMPLE_CAN, &rxEhFifoConfig, true); rxFifoXfer.framefd = &rxFrame[0]; rxFifoXfer.frameNum = RX_MESSAGE_COUNT; /* Set Rx Masking mechanism for MB. Only accept data frame with desired ID. */ FLEXCAN_SetRxMbGlobalMask(EXAMPLE_CAN, FLEXCAN_RX_MB_STD_MASK(0x7FFU, 0, 0)); #define RX_MESSAGE_BUFFER_0 (0U) /* Setup Rx Message Buffer 0. */ mbConfig.format = kFLEXCAN_FrameFormatStandard; mbConfig.type = kFLEXCAN_FrameTypeData; mbConfig.id = FLEXCAN_ID_STD(0x120U); FLEXCAN_SetFDRxMbConfig(EXAMPLE_CAN, RX_MESSAGE_BUFFER_0, &mbConfig, true); #define RX_MESSAGE_BUFFER_1 (1U) /* Setup Rx Message Buffer 1. */ mbConfig.format = kFLEXCAN_FrameFormatStandard; mbConfig.type = kFLEXCAN_FrameTypeData; mbConfig.id = FLEXCAN_ID_STD(0x121U); FLEXCAN_SetFDRxMbConfig(EXAMPLE_CAN, RX_MESSAGE_BUFFER_1, &mbConfig, true); Recommendation: To achieve a balanced trade-off between the number of Message Buffers and acceptance filters, Option 1 is recommended.

Using FreeMASTER block in Simulink 1 Table of Contents • Overview • Context • FreeMASTER Blocks • Generated ELF File • Application Example • References • Conclusion 2 Overview This article introduces the FreeMASTER blocks available in NXP Model-Based Design Toolbox (MBDT) and explains how they are used within a Simulink model to prepare an application for FreeMASTER integration. The primary focus is the FreeMASTER Config block, which enables the FreeMASTER Driver in the generated application and allows users to configure the communication interface and runtime parameters required by FreeMASTER. The article also introduces the FreeMASTER Recorder block, which can be used to add data-recording capabilities to the application. Why is this Important? Before FreeMASTER can communicate with an embedded application, the FreeMASTER Driver should be enabled and configured in the embedded application. The FreeMASTER blocks provided by MBDT simplify this integration process by allowing all required settings to be configured directly within the Simulink environment. This article is intended for: Simulink users working with NXP Model-Based Design Toolbox Developers integrating FreeMASTER into embedded applications Engineers interested in runtime monitoring and debugging Users preparing an application for future interaction with FreeMASTER By reading this article, you will understand how FreeMASTER support is enabled within a Simulink model and how the generated application is prepared for runtime communication and data access. You will also learn how the code-generation process produces an ELF file containing symbolic information corresponding to application variables, which is later used by FreeMASTER to access, monitor, and visualize application data. 3 Context Dedicated Simulink blocks integrate FreeMASTER into a Model-Based Design Toolbox project by automatically generating the software infrastructure required by the application. The overall workflow is illustrated below: Figure 1. FreeMASTER workflow In this workflow, the FreeMASTER blocks serve as the interface between the Simulink model and the FreeMASTER Driver that will be included in the generated application. 4 FreeMASTER Blocks FreeMASTER blocks can be found in the MBDT library under: S32K3xx Core, System, Peripherals and Utilities → Utility Blocks Figure 2. FreeMASTER Simulink Library Three blocks are available for FreeMASTER integration: FreeMASTER Config block FreeMASTER Poll block FreeMASTER Recorder block 4.1 FreeMASTER Config Block The FreeMASTER Config block is responsible for enabling and configuring the FreeMASTER Driver within the generated application. It inserts the software infrastructure required for communication between the embedded target and the FreeMASTER desktop tool and serves as the foundation for integrating FreeMASTER functionality into a Simulink model. Figure 3. FreeMASTER Config block This block provides a configuration interface divided into two sections: communication settings and runtime settings. 4.1.1 General Tab The General tab contains communication-related parameters: Connection Type – selects the communication interface used by FreeMASTER. Instance – specifies the peripheral instance assigned to FreeMASTER communication. Baudrate – defines the communication speed. ISR Priority – sets the interrupt priority associated with FreeMASTER communication. Figure 4. FreeMASTER General tab During configuration, a dedicated communication peripheral is assigned to the FreeMASTER Driver. In the example shown, communication is performed through LPUART6 operating at 115200 bps. Note: The peripheral assigned to FreeMASTER should not be reused simultaneously for other communication purposes. During initialization, the FreeMASTER Driver assumes control of the communication resources associated with the selected peripheral. 4.1.2 FreeMASTER Configuration Tab The FreeMASTER Configuration tab contains runtime-related settings: Mode – defines the FreeMASTER operating mode. Number of Scopes – specifies the number of available scope instances. Max Variables – defines the maximum number of variables handled by a scope. Automatic Buffer Size – automatically calculates communication buffer size. FIFO Receiver Queue Size – configures the receive queue used by the communication driver. Figure 5. FreeMASTER Configuration tab Together, these settings determine how the FreeMASTER Driver operates within the generated application. 4.2 FreeMASTER Recorder Block In addition to the configuration block, MBDT provides a FreeMASTER Recorder block that enables support for FreeMASTER recording functionality. Figure 6. FreeMASTER Recorder block Unlike the Config block, which is primarily focused on communication setup and driver integration, the Recorder block is designed for high-speed monitoring and visualization of application variables. It configures data acquisition resources that can be accessed later through the FreeMASTER desktop application, enabling detailed analysis of system behavior. The Recorder block is typically placed in application execution paths where rapidly changing signals need to be captured periodically. To support this, it uses an on-board memory buffer to store acquired samples, allowing high-frequency data to be recorded without requiring immediate transfer to the host PC. The buffered data can then be retrieved and displayed in FreeMASTER for waveform visualization, performance evaluation, and post-run analysis. The block provides the following configuration parameters: Id – unique identifier of the recorder instance. Name – user-defined recorder name. Buffer Size – amount of memory allocated for storing captured samples. Timebase – time reference used during recording operations. Figure 7. FreeMASTER Recorder block parameters The Recorder block is optional and can be used whenever runtime data recording capabilities are required. 4.3 FreeMASTER Poll Block MBDT also provides a FreeMASTER Poll block, which allows the application to explicitly call the FreeMASTER polling function within the Simulink model. Figure 8. FreeMASTER Poll block The Poll block does not require any configuration parameters. Its purpose is to provide a configurable location within the application where FreeMASTER communication handling and command processing can be executed. Figure 9. FreeMASTER Poll block mask The role of the Poll block depends on the operating mode selected in the FreeMASTER Config block. When the FreeMASTER Driver is configured in Poll Mode, the Poll block is responsible for both communication handling and command processing. When the Driver operates in Short Interrupt Mode, communication is handled by interrupts, while command processing is performed through the Poll block. Note: For both Poll Mode and Short Interrupt Mode, the Poll block is required and should be placed in an execution path that runs periodically, such as the application's main step function, to ensure timely processing of FreeMASTER requests. When the FreeMASTER Driver is configured in Long Interrupt Mode, communication handling and command processing are performed entirely by the driver interrupt routines. In this configuration, the Poll block is not required, and its execution has no effect on FreeMASTER operation. The Poll block complements the FreeMASTER Config and FreeMASTER Recorder blocks by providing a configurable mechanism for communication processing when required by the selected FreeMASTER operating mode. 5 Generated ELF File Once the FreeMASTER blocks have been added and configured, the model can be built using the standard code-generation workflow provided by Embedded Coder and MBDT. In addition to the application code generated from the Simulink model, the build process also produces an ELF (Executable and Linkable Format) file. When debug information is enabled during the build process, the ELF file contains symbolic information about application variables, functions, and memory locations stored in the DWARF debug sections. Otherwise, this information may be removed, preventing the FreeMASTER desktop tool from extracting the symbols required for variable access and monitoring. The ELF file is later loaded by the FreeMASTER desktop tool, allowing variables to be identified automatically without requiring manual memory address entry. This enables features such as variable monitoring, runtime configuration, data visualization, and recording. Note: Generating a valid ELF file with debug information is an important preparation step before attempting to establish communication with the target application. 6 Application Example To showcase the concepts described above, we can create a simple Simulink model example that uses the FreeMASTER Config block together with two application variables: counter and increment . In this example, the counter variable is periodically incremented by the value of the increment variable. The increment variable can be modified at runtime by the user directly from the FreeMASTER desktop application, allowing the rate at which counter grows to be adjusted on the fly. Figure 10. Application example Simulink model This simple model demonstrates the two fundamental capabilities enabled by FreeMASTER integration: Variable monitoring – observing the value of counter as it changes over time. Runtime variable modification – updating the value of increment from FreeMASTER and immediately observing its effect on counter . Figure 11. FreeMASTER application of the counter example   Once the model is built and the resulting application is running on the target, both variables become accessible through FreeMASTER using the symbolic information contained in the generated ELF file. The user can watch counter update in real time and interactively change increment to influence the application's behavior without recompiling or reflashing the target. 7 References Introduction to FreeMASTER FreeMASTER Driver and Documentation Package – The FreeMASTER Driver and its accompanying documentation are delivered as part of the MBDT installation. After installing the toolbox, they can be found in the root installation directory: NXP_MBDToolbox_S32K3\FreeMASTER\ 8 Conclusion This article introduced the FreeMASTER Configuration blocks provided by NXP Model-Based Design Toolbox and explained their role in preparing a Simulink model for FreeMASTER integration. By configuring the block appropriately, developers can include the required FreeMASTER support in the generated application and produce an ELF file suitable for runtime access to application data. The next article in this series will demonstrate how to use the generated application and ELF file to establish a connection between the target device and the FreeMASTER desktop application.

LPC55s28 PN5190 NFC Read Library porting Hello Community, hello NXP-Team I'm looking for LPC55S28 ↔ PN5190 connection details (Host SW + DAL / BAL layer) I already have the PN5190 NFC Reader Library and would like to connect the LPC55S28 MCU to the PN5190 NFC frontend. I have reviewed the article “Using NFC Reader Library with LPC55S69”, but I am looking specifically for an LPC55S28‑compatible setup. Questions Is there an existing DAL/BAL (Driver Abstraction Layer) implementation for connecting the LPC55S28 to the PN5190? Has anyone successfully connected LPC55xx (LPC55S16 / LPC55S28 / LPC55S69) to a PN5190 using the NFC Reader Library? Is there a ready solution, reference project, or recommended starting point for the LPC55S28 + PN5190 combination? If not, is the LPC55S69 guide the correct and closest reference to follow for porting? Thank you! Re: LPC55s28 PN5190 NFC Read Library porting Hello @EduardoZamora, Thank you for your response. The guides you referenced are already much more helpful than what I initially found on the NXP website, so thank you for pointing them out. While reviewing these guides, I noticed that many of them include preconfigured folders or ready-to-use packages for specific processors or boards. These packages typically integrate the NFC Reader Library together with the control processor setup and, in some cases, DiscoveryLoop examples, which makes it much easier to get started. Would it be possible to provide a similar reference package or project (for example, importable into MCUXpresso) for the LPC55S28 + PN5190 combination, or at least for the closest supported LPC55xx configuration? Having such a project as a starting point would be extremely helpful for porting and validation. Thank you in advance for your support. Best regards, Radoslaw Tomasik Re: LPC55s28 PN5190 NFC Read Library porting Hello @RadoslawTomasik My apologies, there is no specific documentation or guide for PN5190 + LPC55S28. However, as you mention, you can refer to the following guides: - Using NFC Reader Library with LPC55S69 - NFC Reader Library Porting FRDM_K64F - NFC Reader Library Porting to i.MX RT1050 - NXP Community Those guides can be a good starting point. Regards, Eduardo. Re: LPC55s28 PN5190 NFC Read Library porting Hi, Unfortunately, there is no reference project for this specific setup. The NFC Reader Library for PN5190 includes support for LPC1769 and Kinetis K82; support for any other Host MCU must be implemented by the user. When you mention that linking the NFC Reader Libraries is no longer possible, does it mean that you are getting an error message when trying to link the folders? What is the procedure you are following? You should be able to link the folder by following the steps listed in NFC Reader Library Porting FRDM_K64F, "Link the NFC Reader Library" section. Also, linked resources should appear in Project Properties > Resource > Linked Resources. Regards, Eduardo. Re: LPC55s28 PN5190 NFC Read Library porting @EduardoZamora  When following the guide below: https://community.nxp.com/t5/NFC-Knowledge-Base/NFC-Reader-Library-Porting-FRDM-K64F/ta-p/1117798 I am able to successfully perform the described steps: Add the NFC Reader Libraries Create a project for LPC55Sxx Copy the DiscoveryLoop files into the LPC project However, when performing the same steps for PN5190 (using NxpNfcRdLib_PN5190_v07.14.00_Pub), I am able to: Add the libraries Create the LPC55Sxx project but when attempting to copy the DiscoveryLoop files, I encounter the following error: Problem occurred while copying resources. Cannot create linked resource. Could you please check this on your side and let me know whether this is a known limitation, or if there is a recommended workaround for PN5190 with LPC55Sxx? Thank you for your support. Best regards, Radoslaw Tomasik Re: LPC55s28 PN5190 NFC Read Library porting Hello @EduardoZamora , As a follow-up, I found that the original “Cannot create linked resource” error was caused by an excessively long file path. After shortening the path, this specific issue was resolved. However, a related problem still persists when adding the NFC Reader Libraries to the workspace with the “Copy projects into workspace” option enabled (see attached screenshot). Several documents (e.g. AN13425) explicitly recommend not selecting this option. When I follow this recommendation, copying the DiscoveryLoop files into the LPC55Sxx project works correctly. The downside is that, in this case, linking the NFC Reader Libraries is no longer possible, because the workspace does not contain any NFC example projects. As a result, it is not possible to link the following folders from NfcrdlibEx1_BasicDiscoveryLoop into the lpc55sxx_basic_discovery_loop project: DAL NxpNfcRdLib phOsal intfs Could you please advise whether this is a known limitation for PN5190 with LPC55Sxx, or if there is a recommended workaround? Also, is a preconfigured LPC55Sxx + PN5190 project available, similar to those referenced in other NFC Reader Library guides? Best regards, Radoslaw Re: LPC55s28 PN5190 NFC Read Library porting Hi, Could you please kindly clarify what you mean with "the DAL and intfs folders are part of the DiscoveryLoop example and cannot be linked independently"? You should not face any restriction when trying to link these folders to your project. You can either copy the folders to the workspace and link them or link the folders directly from the path where the Library was extracted; how they are shown in the project structure may depend on the method used. Relevant paths that need to be included are shown in "Add include paths" section from NFC Reader Library Porting FRDM_K64F after linking the folders. Regards, Eduardo. Re: LPC55s28 PN5190 NFC Read Library porting Hello @EduardoZamora , thank you for your reply and for the clarification. I understand that there is no reference project for the LPC55S28 + PN5190 combination, and I am prepared to implement the SPI DAL myself. My intention is to follow the NFC Reader Library Porting FRDM_K64F procedure as closely as possible, but I am encountering some differences when working with the PN5190 package. Here is the current status and the open questions: Importing an LPC55S28 SDK example (e.g. hello_world) works without any issues. Link the NFC Reader Library: The NxpNfcRdLib and phOsal folders can be linked to the LPC55S28 project and are visible under Project Properties → Resource → Linked Resources. However, these linked folders do not appear in the project structure as shown in the porting guide. The DAL and intfs folders are part of the DiscoveryLoop example and cannot be linked independently. Should these folders be copied from the DiscoveryLoop project into the LPC55S28 project instead of being linked? If so, which parts are considered platform-specific and expected to be modified by the user? Include paths can be configured manually, but it is unclear: Which include directories should be taken from the NxpNfcRdLib / phOsal libraries Which ones should come from the DiscoveryLoop example Since the libraries differ depending on the host MCU, and the integration procedure seems to vary from project to project, I would appreciate your guidance on the recommended setup for this configuration. This is fully within NXP platforms; I already have both evaluation boards connected and would like to proceed with basic driver and connection tests. Best regards, Radoslaw Re: LPC55s28 PN5190 NFC Read Library porting Hi Eduardo, thank you for your reply. To clarify what I meant: the issue is how the DiscoveryLoop example project is structured and imported. When importing the DiscoveryLoop project into MCUXpresso, it cannot be added to the workspace using the “Copy files into workspace” option. As a result, the project remains outside the MCU workspace directory and the DAL and intfs folders are therefore not visible within the workspace file system. Because of this, they cannot be linked independently in a practical way, as described in the FRDM_K64F porting guide. Due to this, I proceeded with a manual port: Copied the required DAL, intfs, NxpNfcRdLib, and phOsal folders directly into the LPC55S28 project so that they are fully visible in the project structure. Manually added all required include paths, preprocessor symbols, and source locations. Modified the DAL implementation to match the LPC55S16/LPC55S28 platform (SPI, GPIO, IRQ handling, timing, etc.). With this approach, the project builds and the structure is now consistent and transparent inside the MCU workspace. Regards, Radoslaw Re: LPC55s28 PN5190 NFC Read Library porting Hello, Thank you for your reply! It's greatly appreciated. I'm using the LPC55S69-EVK  + PNEV5190BP. I have downloaded the latest NxpNfcRdLib (NxpNfcRdLib_PN5190_v07.16.00_PUB) and SDK (SDK_26_06_00_LPCXpresso55S69) from the website. At first I imported the DiscoveryLoop example from the NxpNfcLib made for the K82F microcontroller. This was not a great success because there are a lot of micrcocontroller specific settings that were interfering with that process.  I then found the LPC porting guide mentioned earlier in this thread. This was also not a success because the SDK and Nfc lib versions were basically too old to properly use. I then did what you already mentioned. I imported the lpcxpresso55s69_lpc_gpio_led_output_cm33_core0 example from the newest SDK and added the DAL, intfs, NxpNfcRdLib, and phOsal folders directly to the project. Then I configured the paths, preprocessor and source locations. The I added the missing SDK components. I tried to modify the DAL but because there were quite a few differences between the DAL that worked for the old Nfc lib and the new lib I was not able to pull this off. It actually compiles but it gets stuck in the hardfault handler on the SPI_MasterInit function caled bij phbalReg_Init().  I think this is mostly because I'm quite new to using NXP products. I'll include a zip file of the project. Maybe there are things that I did wrong or maybe I missed something. Re: LPC55s28 PN5190 NFC Read Library porting Hello, Were you able to figure out how the library can be ported? I keep getting stuck at rewriting the DAL because the SDK and NFC-library structure were changed quite significantly. I tried to base my code of off this guide with included source code . However this NFC-library version does not include the PN5190 drivers. When the PN5190 was added quite a few significant changes were added to the library which causes a lot of errors when I tried to just replace the NfcRdLib, phOsal and intfs folders. I also ran into a couple of errors that were caused by the newer SDK version so I basically don't really know what to do now. Especially because the recommended guides 1 & 2 are not up-to-date anymore. Thanks in advance!  Re: LPC55s28 PN5190 NFC Read Library porting Hi Emiel, Are you using the same hardware combination (LPC55xx + PN5190)? Basically, you can use the existing porting guides as a reference, even though there is no official LPC55S28 + PN5190 project. I would recommend downloading the latest NxpNfcRdLib_PN5190 package and importing it into MCUXpresso. As a starting point, create a new project from an LPC55xx SDK example (for example, hello_world) and port the NFC Reader Library manually. The approach that worked for me was: Copy the DAL, intfs, NxpNfcRdLib, and phOsal folders directly into the LPC55S28 project so everything is part of the project structure. Manually configure all required include paths, preprocessor symbols, and source locations. Rewrite the DAL for the LPC55xx platform (SPI, GPIO, IRQ handling, timing, etc.). Enable any missing MCU drivers through Manage SDK Components in MCUXpresso and adapt the DAL to use those drivers. Regarding the drivers you mentioned as missing: which ones are they exactly? If you can list the missing modules or post the compiler errors, it will be much easier to identify what still needs to be ported. The errors caused by the newer SDK may also depend on the exact LPC device and SDK version you're using. I would first verify that you're using the latest SDK available for your MCU from NXP and make sure it matches the version expected by your project. From your description I can only make an educated guess, but if you can share: the exact LPC55xx device, the SDK version, the NFC Reader Library version, and a few of the compilation errors, I'd be happy to help identify the required changes. I went through a similar manual port, so I may be able to point you in the right direction. I hope this helps you move a bit further. Re: LPC55s28 PN5190 NFC Read Library porting EDIT: I managed to "fix" this error by adding uint32_t flags instead of void to the definitions of PH_DRIVER_LPC_TIMER_IRQ_HANDLER. Still doesn't work though Re: LPC55s28 PN5190 NFC Read Library porting Thank you very much. I'm not entirely sure how I should configure the pin_mux and clocks. I did it via the pin configuration tool though but I'm not sure if I have done it correctly. But I also don't quite understand why I would have to do it like this because these settings seem to be overwritten in the phbalReg_LpcOpenSpi.c file anyway.  I did find out that in phbalReg_Init(), I think it was, I needed to change the way the clock frequency was selected because this had been changed some time ago.  I then was able to compile and download the code to the microcontroller. However, nothing works except the debug text :(. I took a look at your code however, I ran into more problems. The library version I have expects the interrupt handler to be like this: PH_DRIVER_LPC_TIMER_IRQ_HANDLER(uint32_t flags); while literally every example I have found thus far uses your define: PH_DRIVER_LPC_TIMER_IRQ_HANDLER(void); This results in the following error:  ../DAL/src/LPCOpen/phDriver_LPCOpen.c:42:47: error: initialization of 'void (*)(uint32_t)' {aka 'void (*)(unsigned int)'} from incompatible pointer type 'void (*)(void)' [-Wincompatible-pointer-types] 42 | ctimer_callback_t ctimer_callback_table[] = { PH_DRIVER_LPC_TIMER_IRQ_HANDLER, NULL, NULL, NULL, NULL, NULL, NULL, NULL}; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Your help has been very helpful thus far. Would it be possible to include the phDriver_LPCOpen.c file or a zip of the entire project? Thanks in advance! Re: LPC55s28 PN5190 NFC Read Library porting Hi Emiel, From your description, the first thing I would double-check is your pin configuration (pin_mux) and verify that the correct Flexcomm instance is configured for SPI. A mismatch there can easily cause the code to end up in the HardFault handler during SPI_MasterInit(). Additionally, make sure that the spi_master_config structure is properly initialized before calling SPI_MasterInit(). It's also worth reviewing the Exchange function to ensure that both the WRITE and READ phases are implemented correctly, as the newer Reader Library expects slightly different behavior than the older versions. I've attached my files for reference. They may help you compare your implementation with a working example, but I can't guarantee they'll work without modification since they were created for a different setup. Hopefully this points you in the right direction. Re: LPC55s28 PN5190 NFC Read Library porting Hi Emiel, Yes, you need to configure the ports using the MCUXpresso Config Tools (Pins/Clock Configurator). The DAL assumes that the MCU peripherals are configured correctly, so those settings are not completely replaced by phbalReg_LpcOpenSpi.c. I've attached my pin_mux files and the LPCOpen sources for reference. Please keep in mind that this is reference code only. The project was never fully tested or finalized, so I can't guarantee it will work out of the box. I think there's still quite a bit of debugging ahead before everything works correctly. Unfortunately, I won't be available for about the next two weeks, so I probably won't be able to respond to any further questions until then. Good luck with the porting, and I hope the attached files help you move forward. Re: LPC55s28 PN5190 NFC Read Library porting EDIT: Yes the data stream send over SPI seems correct Line 151 of phhalHw_Pn5190.c: uint8_t PH_MEMLOC_REM pTxBuff[] = {0x7F /* Direction byte */, 0x00, 0x04 /* HDLL Get Version command length */, 0xE1 /* HDLL Get version command OP code */, 0x00, 0x00, 0x00, 0x75, 0x48 /* Crc */}; This is exactly the data that can be seen in the logic analyzer screenshot I sent earlier. Re: LPC55s28 PN5190 NFC Read Library porting Hello, Thanks yet again. This is my last week before school starts so I doubt I'll be able to work on it after you get back from your holiday 🥲. I managed to get the SPI sort of working though. I'm not really sure how though. Out of desperation I replaced the pin_mux.c and .h files with your files. This obviously didn't work so I changed them back to what I had before and the SPI started working 🤷‍♂️. Anyway, I have included the logic analyzer screenshot. I have no idea if the data that is being send is correct but it looks sensible to me. However, as you can see there is no response from the PNEV5190B. I have also included a photo of my setup. I've switched R5 over to R7 to enable the external SPI interface. In the debug window you can see that it goes through the functions without a problem. However, after sending the config in line 286 of phhalHw_Pn5190.c it waits for an interrupt it never receives and errors out.  This is the pin map: JP1 on PNEV5190B P23 on LPCXpresso55S69 (Mikroe) P24 on LPCXpresso55S69 (Mikroe) 1.   EXT_SPI1_CLK 4.  LSPI_HS_SCK (PIO1_2) X 2.  EXT_SPI1_MOSI 6.  LSPI_HS_MOSI (PIO0_26) X 3.  EXT_SPI1_MISO 5.  LSPI_HS_MISO (PIO1_3) X 4.  EXT_SPI1_CS0 3.  LSPI_HS_SSEL1 (PIO1_1) X 5.  EXT_NFC_IRQ X 1.  PIO1_5_GPIO_ARD (PIO1_5) 6.  EXT_NFC_CLK_REQ X X 7.  EXT_NFC_WKUP_REQ X 2.  WAKE/GPIO (PIO1_18) 8.  EXT_NFC_DWL_REQ X 3.  PLU_OUT6/GPIO/FC2_USART_RXD_ARD/SD1_D1 (PIO1_24) 9.  GND X X 10. GND 8. GND X

68LC302 and serial bootstrap feature Hi all. Hopefully there is still someone around in 2026 that has some knowledge tucked away in the back of their brains regarding the LC302. I've been working on a little project involving an LC302 and I am interested in using the serial bootstrap feature. I just cant seem to get it to work and I wondered if there is anything particularly special that needs to be done to make it work. I've tried everything I can think of, and I'm currently looking at replacing the LC302 that I currently have in case it is somehow faulty, but thought I'd ask the question before I go to that effort. FWIW the markings on the package are (with Motorola logo): MC68LC302PU25CT 2J29A QQDJ0316 I am powering it with 5V. Basically I cannot get it to echo back anything that I am sending to it. I came across the following post which seemed to describe the same problem, but I dont seem to have the same issue: https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/We-have-been-using-the-68LC302-for-decades-without-major/m-p/612300 Things I've tried/I can observe with my scope/logic analyser: I've tried using both PLL mode and not. In PLL mode I used a 4MHz oscillator (4.192 is hard to come across). In this mode I used 9174 baud (4MHz*4, /109, /16). Without the PLL I used a 20MHz oscillator with baud 11467. I've used my signal generator to feed 4.192MHz in and used the baud rate quoted in the datasheet also to no avail. If I pull PA7 high to disable bootstrap mode, I can observe some brief activity on the AS pin, presumably as the CPU tries to read its reset vector from external memory. If I pull PA7 low to enable bootstrap mode I don't observe this activity any more, presumably as the CPU is held in reset. I did early on discover that PA7 seems to have some kind of current source on it, and was sourcing approx 3-4mA of current (measured with my multimeter in current mode), overpowering my external pull down resistor and resulting in a logic high. This feels like an extremely high amount of current to me, and does anyone have an explanation for that? It seems vaguely related to the above thread causing PA7 to be pulled too high unexpectedly. Maybe my part is faulty? Reset and HALT are being asserted simultaneously (I've got lots of 68k experience from hobby projects over the past several years). 🙂 I've double and triple checked all of my wiring including the polarity of the TX/RX signals, and even pulled the flow control inputs for SCC1 to their negated state just in case. I've measured with my oscilloscope that my USB-serial adapter does indeed generate the baud rate that I am requesting, and looping TX to RX allows me to echo back the characters that I send in putty, so I am fairly confident there is nothing odd going on there. I havent wired up any of the memory busses, because for now I am just interested to see if I can load some code in via serial and make an LED blink, but the BUSW pin has been strapped for 16-bit bus operation, if that matters? Does anyone have any other suggestions before I go desoldering stuff? Thanks! Re: 68LC302 and serial bootstrap feature Hi, thanks for the message. I have made sure that I am using SCC1 related pins. My setup is on a perfboard with wire wrap, so there are no other influences on any of the pins other than what I have wire wrapped. I've verified with a multimeter that reset and halt are asserted together and that they reach 0V, and that all strap pins are seeing the required voltage levels with no floating pins. Also, as mentioned in my post, I have also tried using 4.192MHz supplied by my signal generator and the baud rate quoted in the datasheet, but this didn't help. Apologies when I said I had tied CD1 to its negated state, I've just mixed up my terminology and it is indeed tied to ground (asserted), along with CTS1 for good measure. I'll try sending 576 bytes as a test in case it is just not echoing them back for some reason, but is still receiving them correctly. Thanks Re: 68LC302 and serial bootstrap feature Hello, The first thing I would check is CD1 . For the LC302 serial bootstrap echo path, the manual says the SCC hardware echoes received characters back on TXD1 , but CD1 must be asserted; on SCC1 the external CD1 pin must be tied low . If you pulled the SCC1 modem-control inputs to their “negated” state, that may be exactly why you see no echo. Other important points from the LC302 boot description: Serial bootstrap is enabled by sampling PA7 = 0 during hard reset , where hard reset means both RESET and HALT asserted . PA7 must not float; it must be deliberately pulled high or low during reset. The first 576 bytes received on SCC1 are stored in dual-port RAM, and each received character is echoed back out of TXD1 ; the device will not leave boot mode until all 576 bytes are received. For internal-clock bootstrap, the documented nominal clock assumptions are 4.192 MHz or 32.768 kHz , with the SCC programmed to approximately 9600 baud. In asynchronous UART mode, the bit rate is 1/16 of the TCLK1/RCLK1 clock rate when using the external clock option. So before replacing the part, I would try this exact minimal setup: Hold RESET and HALT low together . Strap PA7/BOOT low with a strong enough pulldown to overcome whatever is on your board. Select the intended clock mode with PA5 : PA5 = 0 : internal boot clock mode. PA5 = 1 : external clock on TCLK1/RCLK1 , 16× baud. Strap PA12/MODCLK0 consistently with the clock source; the manual samples it during hard reset to distinguish the nominal EXTAL frequency. Tie CD1 low . Keep RXD1 , TXD1 , RCLK1 , and TCLK1 wiring consistent with SCC1, not SCC2. The boot feature is for SCC1 in the LC302 description. Send a full 576-byte test stream, not just one character, although the echo should appear character-by-character once receive is working. The 3–4 mA sourced from PA7 is suspicious . The datasheet-level input leakage value retrieved is only 20 µA max , far below milliamps. Since PA7 is also a bidirectional multi-function pin, it is possible to get contention if something else is driving it or if the part has already left the reset-sampling state, but during reset-as-boot-strap it should not require sinking several mA just to read a low. I would check for a board-level pullup/driver/solder bridge on PA7 , verify the package pin orientation, and measure the current while both RESET and HALT are actively asserted. One more practical note: your 4 MHz internal-clock attempt is not equivalent to 4.192 MHz . It may be close enough for some UARTs if the other side is adjusted, but the documented internal bootstrap mode assumes the nominal LC302 clock values, so for eliminating variables I would use 4.192 MHz with the documented baud , or use the external-clock mode and provide clean TCLK1/RCLK1 = 16 × baud .   regards Re: 68LC302 and serial bootstrap feature So, I replaced the 68LC302 for another one, and for about 2 seconds it worked (echoed back the characters I was sending it), until I power cycled it, and from then on it wouldnt work any more again. Initially I didnt have CD1 grounded, because the datasheet says this is a "dont care" for the purposes of the serial bootstrap process, and it did indeed work in this configuration. After it stopped working I tried grounding CD1 but this didnt help. So close, and yet so far. This project is just cursed. 😞 This one also seems to have some kind of heavy-ish current source on PA7 that needs a reasonably strong resistor to pull it down sufficiently, or a tri-state driver to override it. Re: 68LC302 and serial bootstrap feature Initially when I tested with the signal generator I didnt have it terminated. In the most recent case I am using an on-board 20MHz oscillator and ignoring the PLL configuration for the time being just to simplify things. (This isn't the configuration I want to run in the final version of my project (if I ever get there) though, becuase I want to use a 4MHz oscillator to drive another part as well.) Power for the whole board is coming from a small USB-serial module from Mikroe which has an MCP2221A on it. This unfortunately has a diode in series with the 5V supply so the board sees closer to 4.7V, but I have also used a bench PSU to supply a solid 5V. I cant think of a case where the CPU would not have power but a 5V signal would be present on any of the pins - power is either there for everything or it isnt. But if that is a situation that could result in latch-up and destroy the chip then I might just ditch the whole project now, because I am looking at building it into an arduino style board, and if these parts are just too overly sensitive to wierd and wacky power situations then they are probably highly unsuitable for this project. 😞 Re: 68LC302 and serial bootstrap feature I think you're killing the chip. There are a few ways to do that, and reading your posts suggests two possibilities. You're running (or have run) the clock from an external signal generator. Have you terminated the cable from the signal generator so as to avoid reflections and overshoots? If you've got a 50 ohm coax from the signal generator without a 50 ohm resistor on the end, it'll glitch (the reflections) up to 10V and down to -5V. That'll kill the chip for sure. If you have an Agilent signal generator (others might be similar), program it to "0 to 5V" and don't notice the "terminated or not" option, then setting it to terminated and not adding one will have it generate 0-10V which will then glitch to -10V to 20V. Check the clock signal at the CPU with a good (high frequency, like 100MHz or better) oscilloscope. How are you powering the chip driving the serial port on the CPU? Do you have a MAX RS232 transceiver powered from the 5V that is powering the CPU (and being fed 12V RS232 from a PC or something)? Or are you using an external TTL-level (3V3 or 5V) serial port connected directly to the CPU? If you're using the latter then when you power the CPU off you'll still be driving that external voltage into that CPU pin. TTL-RS232 idles at 5V, so doing that might damage the pin or even cause fatal latch-up. Google says this chip can suffer fatal latch-up if you do this. Check "latch-up" on Wikipedia. And make sure everything is grounded together. This but this is something people using CAN always forget to do. Ditto RS-232. Tom Re: 68LC302 and serial bootstrap feature I suppose another option is to just build something properly on a PCB. I have one designed already, but I was hoping to test said design with a prototype first, before comitting to PCBs. I sort of get the feeling that if I tried to build it up on a PCB where it has a better electrical environment, maybe it would just work. Part of the reason for wanting to prototype it was to make sure I had the correct logic for multiplexing the strapping pins between their straps and GPIOs to enter bootstrap mode during reset. The reset and bootstrap enable can be provided by some GPIOs of the MCP2221A, such that you can either do a reset on its own, or reset with bootstrap enabled. My signal generator is a Siglent SDG2122X. When I use it I have it set to 5V peak to peak with a 2.5V offset such that it ranges from 0 to 5V, rather than -2.5 to +2.5. My scope is a Keysight MSOX2024A, and I used that to check the signal coming from the signal gen. I wouldnt say I was using a fully optimal ground setup at the time when I did that, so I was seeing over/undershoot on the clock signal, but I'd have put that down to the fact I wasnt using a group clip or ground spring on the scope probe - I was more interested in measuring the frequency seen at the pin of the chip and just double checking the voltage was achieving 5V and not being dragged down by anything. I dont remember to what extent it was over/under shooting, I'd have to measure it again I guess. Re: 68LC302 and serial bootstrap feature We've flown to the moon on wire wrap too. 🙂 Power is formed by some rings of wire that I've run around the perimiter of the footprint for the breakout board that the chip is soldered to. It's probably not 100% ideal, but the general technique has worked pretty well for me to date. But I have added decoupling caps to all power pins as close to the chip as I can get them. I recovered the chips from some old Cisco modules. They were known to be working when I pulled them off, and probably wouldn't be fakes coming from Cisco. I'm travelling for work at the moment but I am thinking to try wiring up a ROM when I get back , and program it with some simple code to see if I can make it receive and echo back data. Re: 68LC302 and serial bootstrap feature I'll have to check the settings of the signal generator when I get back home as I don't recall off the top of my head what that is set to. I've only used the signal generator on the first chip I tried though, the second one has only ever had the on-board 20MHz oscillator connected to it. Re: 68LC302 and serial bootstrap feature There's nothing wrong with wire-wrap. I've seen some very high speed stuff built on that. The thing you need to do is to have a perf-board with power traces or a ground plane on it. A ground plane is best (and maybe a power grid on the other side). Then you wrap the ground pins with a short wire and solder to the power plane. You can get better signal integrity on one of those than you can manage with a PCB. Make sure all ground pins are solidly grounded and that you have plenty of small and large bypass caps on the board. It should work. Unless the chips you have are dark-grey-market and scraped off of faulty boards. I've seen that. That's a good signal generator. But if you have it defaulting to "Load: 50 ohm" like it shows in the User Manual, but don't have that terminator it will (and is documented to) send a -2.5V to 7.5V signal with 50 ohms source impedance. Connected to your board, the MPU input protection diodes will cut in, conducting 50mA into the ground and power rails, so it might not be obvious on the oscilloscope that is happening. But 50mA is way too much. Tom

LX2162A USXGMII link never completes Hey all, I have an LX2162A SoM manufactured by Solidrun. I'm using a Clearfog devkit but moving to a custom carrier soon.  Solidrun provides base RCW/DCP/DPL and I've verified functionality. In my case, the DPC for dpmac3 works for the SFP cage and I get an XFI link via SFP DAC cable and various SFP modules. The RCW "rcw_2000_650_2900_3_11_0_auto" sets to SerDes1=3, SerDes2=11 and I'm using a QorIQ kernel (lf-6.6.52-2.2.0) and mc-utils (10.39.0) but with some Solidrun patched applied to both. Uboot and other things are also patched. All patches come from here: https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 I have a MaxLinear GPY245-EKV-1 (and -2) devkit(s) that wants USXGMII over DAC cable to connect the phy to the device. Apparently this is pretty normal. Eventually this phy chip will be integrated into SerDes2=7 Lane6 and Lane7 but I have to use the SFP cage on the Clearfog for testing. Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP I'm only trying to configure dpmac3 to use this USXGMII link via DPC: mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; (I've also tried MAC_LINK_TYPE_BACKPLANE) Confirmed via "restool dpmac info dpmac.3" shows "DPMAC ethernet interface: DPMAC_ETH_IF_USXGMII". In Linux, I added the MaxLinear driver and patched a few things: gpy_update_interface() fix (LKML, Daniel Golle). This was returning -EINVAL for USXGMII interface, crashing phy_state_machine. Patched lynx_pcs_config_usxgmii() in pcs-lynx.c to also write MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) via mdiobus_c45_modify(), since the function only ever wrote MII_ADVERTISE and never enabled AN on the Replicator block itself. This gap matches another post on this forum ("LS1028A 10g-qxgmii phy bring-up") which found the identical symptom (MMD31.0/Replicator control register stuck at 0) and got AN to kick in after manually setting bit 12. This is the DPMAC3 Linux devicetree entry: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; where `gpy245_0` is the MDIO node. MDIO traffic to the phy is working. I added a printout in the lynx_pcs driver which shows the readback: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 Question: Given writes to MDIO_MMD_VEND2 registers on this PCS instance don't appear to persist, is there a known additional step (SerDes/PCS block enable, protocol-specific initialization, or similar) required before the USXGMII on the LX2162A family SoCs will accept configuration? Is protocol 3 fully validated for USXGMII on dpmac3, or primarily intended/tested for XFI? Other questions: Maybe I don't understand GPY245 and USXGMII. I see some folks refer to this as QXGMII and I can't tell if the LX2162A is even capable of that working. Maybe I need to reach out to Solidrun, but all of their patches do not seem to limit the LX2162A's capability. Thanks!

Code, Connections, NXP with WS2812 Hello, I am new to NXP microcontrollers and would like to interface a 16-pixel WS2812B RGB LED strip. Which NXP development board would you recommend for this project? I would also appreciate any example projects, SDK examples, or documentation for controlling WS2812B LEDs. Thank you. Re: Code, Connections, NXP with WS2812 Thank you for your interest in NXP products! The FRDM-MCXA366 is an ideal board for your project. NXP provides a dedicated, beginner-friendly application note that specifically demonstrates how to control WS2812B LEDs using the MCX A366. The document includes board recommendations, hardware connections, source code, and step-by-step setup instructions. AN14980 – Emulating the WS2812 Bus with FlexIO on MCX A366 This application note explains in detail how to use the FlexIO module on the MCX A366 to emulate the WS2812 communication protocol and drive WS2812B LEDs. This should provide everything you need to get started with your design. Please let me know further questions Best regards, Alondra Re: Code, Connections, NXP with WS2812 Hello Alondra, Thank you for the suggestion! Our design is still in the evaluation phase. Before we decide on a board, I wanted to check if the LPC5514JBD64E can also support WS2812 LEDs? Best regards, Kishore