GPIO wakeup triggered by short noise pulses during suspend Hi NXP team, We are using i.MX8MP on a custom board with Linux BSP LF-6.12.20. Several GPIO pins are configured as wakeup sources. Problem: during EMC transient testing (ESD), short noise pulses on these GPIO lines falsely wake the suspended system. We have already confirmed that software debounce cannot solve this: the wakeup decision is made by hardware while the CPU is suspended, and the GPIO interrupt handler — including the gpio-keys debounce — only runs after the system has resumed, so software cannot prevent the wakeup itself. We have also reviewed the Linux drivers (LF-6.12.20) and the i.MX8MP reference manual, and we could not find any hardware filter for the GPIO wakeup path. Please confirm whether this understanding is correct. Questions: 1. Does i.MX8MP have ANY hardware option (in GPIO, GPC, or configurable via ATF) to ignore very short pulses on a wakeup pin — for example a glitch filter or a minimum pulse-width setting? This includes level-trigger mode: does it require the level to be held for a minimum time, or does any instantaneous pulse still trigger wakeup? 2. If no such hardware option exists, what is NXP's recommended solution for this kind of false wakeup? Any application note on ESD protection for GPIO wakeup inputs would be appreciated. 3. Is there any NXP reference design where the Cortex-M7 checks/filters wakeup signals while the A53 stays in suspend? Platform: i.MX8MP custom board, BSP: LF-6.12.20 Best regards, i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: GPIO wakeup triggered by short noise pulses during suspend Hello @Leo_dev  Hope you are doing very well. Q1. Your understanding is correct. The i.MX8MP GPIO/GPC wakeup path has no hardware glitch filter or minimum pulse-width setting or debouncing register. Q2. As there is not an On-chip solution, the recommended design is adding a filter to the PAD. Q3. Yes, you can take a look to the AN13400 "i.MX 8M Low Power Design By M Core Running In System Suspend" is the primary NXP reference for this kind of architecture. Best regards, Salas.

Modbus RTU communication error I am writing code for MC9S08JM60 to read MODBUS RTU holding registers. I am reading 15 holding registers which gives me a 35 byte frame. So i am expected to get 1 interrupt for each byte but i am getting 1 interrupt for the first byte of the frame and next interrupt is for the first byte of the next frame. So I am losing the rest 34 bytes. Please provide any input for this. I am attaching my code snippets. Re: Modbus RTU communication error Hi @An95  Thank you for your post! There is any documentation of Modbus RTU with the S08. But the issue you are facing could be related to not clear the RDRF. The RDRF (Receive Data Register Full) flag is cleared only by reading SCI1D after reading SCI1S1. If SCI1D is not read in the ISR, the interrupt fires once and then the receiver stalls. Refer to 14.2.4 SCI Status Register 1 (SCIxS1) of the MC9S08JM60 Series Data Sheet. Make sure your code is clearing the flag correctly. BR Re: Modbus RTU communication error Hi @carlos_o , Thank you for your response. The RDRF flag is cleared when it enters the callback function of the interrupt service routine. The 35 byte frame is coming in a single interrupt. If I take a buffer of 35 bytes even then i am not able to read the whole frame. Please share your input regarding this. BR Re: Modbus RTU communication error I have changed my implementation to bare metal code still i am receiving only 1 byte. Please share any input. Re: Modbus RTU communication error Hi @An95  The SCI only could receive 1 byte each time RDRF is trigger. So, you will need to trigger 35 interrupts to read the 35 bytes you are sending.  You could refer to the chapter 14.3.3 Receiver Functional Description The SCI module only has one SCI Data Register (SCIxD) that could save 8 bits each time. 

LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from DT. Hello, I am working on a custom board based on the LS1046A and I am experiencing a boot issue with a Debian image generated using FlexBuild. As a first step, I built the default LS1046AFRWY BSP without making any modifications and tested it on my custom board. During kernel boot, the system always hangs after printing: psci: probing for conduit method from DT. There is no kernel panic or exception; the system simply stops at this point. I found the following NXP forum thread describing a very similar issue: https://community.nxp.com/t5/Layerscape/LS1043A-RDB-Linux-Hangs-At-PSCI/td-p/750075 As a temporary workaround, I can boot Linux manually from U-Boot using the following commands. However, the kernel only boots successfully when I limit the available memory to 1982 MB using the "mem=" boot argument. If I increase this value, the kernel hangs again (sometimes at different points during boot). mmc dev 0 part uuid mmc 0:3 partuuidr load mmc 0:1 0x81000000 Image load mmc 0:1 0x90000000 fsl-ls1046a-frwy-sdk.dtb setenv bootargs "console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=PARTUUID=${partuuidr} rw rootwait mem=1982M" booti 0x81000000 - 0x90000000 Test environment: SoC: LS1046A DDR: IS43/46QR16512A (4 GB DDR4) Boot media: SD Card BSP: FlexBuild (LSDK 25.12) To rule out a FlexBuild-specific issue, I also built a completely new BSP using Yocto (YP 6.0 / lf-6.18.20) and tested it on the same hardware. The result is exactly the same. The kernel again hangs after printing: psci: probing for conduit method from DT. The relevant part of the bdinfo output is shown below: DRAM bank 0 Start: 0x80000000 Size : 0x7be00000 DRAM bank 1 Start: 0x880000000 Size : 0x80000000 LMB memory regions: memory[0] : 0x80000000 - 0xfbdfffff memory[1] : 0x880000000 - 0x8ffffffff reserved[0] : 0xfac154c0 - 0xfbdfffff reserved[1] : 0x8ffff5000 - 0x8ffffffff Has anyone encountered a similar issue or have any suggestions on what I should investigate next? Any advice would be greatly appreciated. QorIQ LS1 Devices Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from Hello, Root Cause — BL31 Memory Collision The LS1046A boot flow is: Boot ROM → BL2 (DDR Init) → BL31 (stays resident in DRAM) → U-Boot → Linux     BL31 remains permanently resident in DRAM and handles all SMC calls (PSCI: psci_get_version , CPU on/off, etc.). Its typical placement is near top-of-RAM minus ~10 MiB, with a size of up to 2 MiB.   When Linux boots with the full 4 GB DDR map, it allocates pages that physically overlap BL31's region. The first PSCI SMC call ( psci_get_version ) jumps into now-corrupted memory and the system hangs — with no panic, no exception, just silence. Your bdinfo output confirms the exact pattern — DDR Bank 1 ends at 0x8FFFFFFFF , and BL31 is at approximately RAM_END - 10 MiB = 0x8FF600000 : DDR Bank Start End Notes Bank 0 0x80000000 0xFBDFFFFF ~1982 MiB — your working mem= limit Bank 1 0x880000000 0x8FFFFFFFF 2 GB high bank — BL31 lives here The mem=1982M workaround keeps Linux within Bank 0, never touching Bank 1 where BL31 resides — which is precisely why it works. Fix — Reserve BL31 Memory in the Device Tree The correct permanent fix is to add a reserved-memory node to your DTS marking BL31's region as off-limits to the Linux memory allocator. Step 1: Find where BL31 is loaded Check your ATF build configuration ( plat/nxp/soc-ls1046a/.../platform_def.h ) for BL31_BASE and BL31_SIZE . For LSDK/lf-6.x with the FRWY BSP, the typical placement is: BL31_BASE = 0x8FF80000 (top of high DDR bank minus ~512 KB to 2 MB) BL31_SIZE = max 2 MiB     You can confirm at runtime by checking U-Boot output or the ATF build log for BL31: v2.x... Entry point address = ... . Step 2: Add the reserved-memory node to your DTS In your board DTS file (based on fsl-ls1046a-frwy-sdk.dts ), add: / { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* Reserve BL31 runtime region — adjust addresses to match your ATF build */ bl31_reserved: bl31@8ff600000 { reg = <0x8 0xff600000 0x0 0x00200000>; /* 2 MiB at RAM_END - 10 MiB */ no-map; }; }; }; dts   Adjust 0x8ff600000 and size 0x200000 to match your actual BL31 load address from the ATF build. Step 3: Rebuild and test with full memory After adding the reservation, rebuild the DTB and boot without the mem= workaround. The kernel will skip that region, BL31 remains intact, and PSCI will function correctly.   Regards Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from Hello, I tried the suggested solution, but unfortunately it did not resolve the issue. First, I verified the BL31 address from the TF-A (ATF) build: - BL31_BASE = 0xFBE00000 - BL31_SIZE = 0x200000 (2 MiB) Next, I added a "reserved-memory" node to the Device Tree to reserve the BL31 runtime region and rebuilt the DTB. After that, I booted the system again without the "mem=1982M" boot parameter. However, the system still hangs at the same point.

SPC5777CCMMO3 pin out reading eepron IMG_7633.png   What is the pinout to be able to read the eeprom of this micro with the reader? 3155ac18-7996-4a1a-bf47-f749ef4e56dd.jpeg   Re: SPC5777CCMMO3 pin out reading eepron Hello, If the micro is censored, you won't be able to connect to flash without 256-bit censorship password. So trying to connect without valid secure keys is just waste of time, as there are additional protection mechanisms like PASS, and CSE. Its not like it used to be in old days, uC has now advance secure features to prevent unauthorized accesses. Best regards, Peter Re: SPC5777CCMMO3 pin out reading eepron Thanks, what I'm looking for is to read the internal flash to be able to remove an anti-tunig block that doesn't allow writing modified files, only writing the original. Re: SPC5777CCMMO3 pin out reading eepron Hello, The pins are described in IOMUX table as I have mention before: petervlna_0-1757661184211.png But I am not sure what your intention is. You will need a JTAG properly connect, like it is on evaluation board in order to work. Also if the device is censored you need correct password to unlock its flash. Without it you cannot connect to the device at all. Best regards, Peter Re: SPC5777CCMMO3 pin out reading eepron Hi yes try  reading flash via JTAG. The micro is good. I removed it so I could track and locate where each pin went on the board, and mark points for reading and writing, without having to remove it. Re: SPC5777CCMMO3 pin out reading eepron Hello, Not sure what your intention is, but the pins are explained in IOMUx table attached to reference manul: https://www.nxp.com/webapp/Download?colCode=MPC5777CRM You are probably speaking about reading flash via JTAG. I am confused as your micro looks damaged. So no read of flash is possible if the micro is not working. Best regards, Peter Re: SPC5777CCMMO3 pin out reading eepron where to buy this 256-bit censorship password.

Please help identify the genuine discontinued model MPC8306SCVMAFDCA. We purchased two batches of EOL discontinued component MPC8306SCVMAFDCA for repair spare parts, but the two batches appear to be different. The batch year is missing two letters: one is TCTCJX1901, and the other is TCLB2144. Previously, all products in this series have batch numbers starting with TCTC. We are unsure of the authenticity of these two batches. Could experts please help us identify them? Thank you! We have purchased two batches of EOL (End of Life) discontinued devices, MPC8306SCVMAFDCA, for use as repair spare parts.However, it appears that there are differences between the two batches, specifically the absence of two letters at the beginning of the batch year.One batch is labeled TCTCJX1901, while the other is TCLB2144.Previously, all products of this series we have encountered began with TCTC.We are uncertain about the authenticity of these two batches.We kindly request the assistance of experts in identifying their authenticity.Thank you! Re: 帮忙鉴定真伪停产型号MPC8306SCVMAFDCA， help to check the EOL part MPC8306SCVMAFDCA Please contact the DFAE from whom you purchased the device and ask them to work with the CSR team for confirmation. Thanks

Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog Dear NXP Expert, We have a question regarding the HSE key management functionality. We are using the S32K312 with HSE-B, and we store an ECC public key in the NVM Key Catalog. In our application, we need to obtain the SHA-512 hash of the ECC public key stored in the NVM Key Catalog. After the key is stored, we would like to verify that it has been stored correctly by comparing its SHA-512 hash. For example: Let K be the ECC public key stored in the NVM Key Catalog. We would like to obtain the value SHA-512(K). Does HSE provide any API or mechanism to obtain the SHA-512 hash of a key stored in the NVM Key Catalog? If not, is there any recommended way to calculate or verify SHA-512(K) for a key that is stored in the catalog? Thank you for your support. Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog I got it. Thank you for your support Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog Hi @NghiaLX308  There is no API that allows the user to perform SHA-512 directly on key material. As a workaround, you can export the ECC public key  (using service HSE_SRV_ID_EXPORT_KEY) and then perform the SHA-512 operation (using service HSE_SRV_ID_HASH). Since an ECC public key is not secret, it can be exported in plaintext. There is no need to export it in an encrypted or authenticated format. Regards, Lukas

Display resolution setup on imx8qm with AAOS 15 Hi Team, We are using AAOS 15.0.0_2.1.0 on i.MX8QM MEK. After flashing the board, the physical displays resolution is always set to 1024x600, while we want the display to run at 1920x1080. And we have multi display setup which has android main default display and passenger display. We verified that 1920x1080 is available in the supported display modes, but the active display mode after boot remains 1024x600. We also tried setting the preferred display mode to 1920x1080 from Android, but after reboot the display still comes up in 1024x600. Could you please advise: What determines the default physical display resolution during boot? How can we force the physical display resolution to 1920x1080@60Hz after boot? Is there any configuration required for ro.boot.displaymode, Display HAL, HWC3, or DRM to make 1920x1080 the default active mode? Any guidance would be appreciated. Re: Display resolution setup on imx8qm with AAOS 15 Hello, Please refer to the Android Automotive documentation we have available here: https://www.nxp.com/docs/en/user-guide/UG10176.pdf Especifically have a look to the chapter 8.3.4 Configuring the primary display resolution of the document above. Best regards/Saludos, Aldo.

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. Senlent_0-1785749467498.png 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. ernesto97xn_0-1785858229699.png 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 Senlent_0-1785895006227.png

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? ruthvik_1_1-1785737410834.png 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.

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

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:   Habib_MS_1-1785795604938.png 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:   Habib_MS_1-1785952920711.png 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? Henrik12345_0-1785920940991.png 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. kamaln16_0-1785454764324.png 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.

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: dragostoma_0-1784636089488.png 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 dragostoma_1-1784636129421.png 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. dragostoma_2-1784636149271.png 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. dragostoma_3-1784636164202.png 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. dragostoma_4-1784636183944.png 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. dragostoma_5-1784636199716.png 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. dragostoma_6-1784636215463.png 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. dragostoma_7-1784636229746.png 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. dragostoma_8-1784636242667.png 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. dragostoma_0-1785932572908.png 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 . image.png 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

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

S32K324 FlexIO SPI Master Emulation (S32DS 3.5 / RTD 4.0.0 ) Hello, I am configuring a FlexIO-emulated SPI Master on an S32K324 to communicate with an external SPI slave device. Due to trace routing on our custom board, the physical lines targeting this device are wired to the chip's default FlexSPI0 pins. Therefore, I must use the emulated Flexio_Spi driver stack. this is my setup BUS_FLEXSPI0_UP_SBC_CS PTD8 fxio_d11 BUS_FLEXSPI0_UP_SBC_CLK PTD9 fxio_d0 BUS_FLEXSPI0_UP_SBC_MOSI PTD15 fxio_d10 BUS_FLEXSPI0_UP_SBC_MISO PTD22 fxio_d27 My Environment: IDE:S32 Design Studio for S32 Platform (Version: 3.5, Build id: 240726 Update 13) CPU : S32K324 SDK: Real-Time Drivers (RTD) Version 4.0.0 (Production Release) Is there an official NXP application note or guide that illustrates the end-to-end integration stack specifically for RTD 4.0.0? I need a reference that covers everything from assigning the pins in the tool, mapping the shifters/timers, up to initializing the driver in the main application code. Re: S32K324 FlexIO SPI Master Emulation (S32DS 3.5 / RTD 4.0.0 ) Hello @Kazarian , There is no dedicated application note, to my knowledge, that describes the full end-to-end integration of FlexIO-emulated SPI specifically for S32K324 with RTD 4.0.0 and with this exact pin assignment. The closest official reference is the example project included in the S32K3 RTD package. Please check the RTD example similar to  Lpspi_Flexio_Ip_Transfer_S32K344. This example demonstrates the intended RTD integration flow for FlexIO-based SPI transfer, including the FlexIO SPI driver initialization and the relation between LPSPI and FlexIO SPI instances.   For your custom board, the main points to adapt are the following (as a general guidance): Pins configuration Configure the listed pins in the Pins tool as FlexIO signals: PTD8 → FXIO_D11, chip select PTD9 → FXIO_D0, clock PTD15 → FXIO_D10, MOSI PTD22 → FXIO_D27, MISO Make sure the MISO pin has the input buffer enabled. Also verify in the S32K324 IOMUX/pinout documentation that these FlexIO functions are available for your exact package. FlexIO SPI configuration In the FlexIO SPI configuration, map the SPI signals to the corresponding FlexIO pin numbers, not only to the physical MCU pins: SCK = FXIO_D0 MOSI = FXIO_D10 CS = FXIO_D11 MISO = FXIO_D27 Assign the required FlexIO timers and shifters consistently with the generated configuration. Best regards, Pavel

IMX8MP On chip RAM memory access Hello, I want to learn how I can access the OCRAM  to read and data to the memory. Can anyone advice how I could achieve that on Linux cortex A-53? On-Chip RAM - OCRAM (576 KB) start address: 0x00900000 => reserved for ROM start address: 0x00918000  =>OCRAM FREE AREA end address: 0x0097FFFF https://www.nxp.com/webapp/Download?colCode=IMX8MPRM  Thank you! IMX8MPLUS  i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8MP On chip RAM memory access Hi Roman Luz, does this tip works for you? Regards, Stefano Gigli Re: IMX8MP On chip RAM memory access Hi @Roman_Loz , you could try including compatible = "shared-dma-pool"; and it should work. ocram_dma: ocram_dma@970000 { no-map; compatible = "shared-dma-pool"; reg = <0 0x970000 0 0xC00>; // 3KB }; Regards, Samhitha Kashyap Re: IMX8MP On chip RAM memory access Hi, I am trying to use the OCRAM the way you suggested but I get kernel panic when I try to memcpy to/from it. Could you please help me understand what am I doing wrong or missing? dtsi: resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; }; ocram_dma: ocram_dma@970000 { no-map; reg = <0 0x970000 0 0xC00>; // 3KB }; ... module init: // Find the OCRAM DMA node by name np = of_find_node_by_name(NULL, "ocram_dma"); if (!np) { pr_err("Failed to find OCRAM DMA node in device tree\n"); return -ENODEV; } // Lookup the reserved memory region rmem = of_reserved_mem_lookup(np); if (!rmem) { pr_err("Failed to lookup reserved memory for OCRAM DMA\n"); return -ENODEV; } // Map the reserved memory region ocram_dma_base = ioremap(rmem->base, rmem->size); if (!ocram_dma_base) { pr_err("Failed to map OCRAM DMA memory\n"); return -ENOMEM; } copy: memcpy(current_address, mv->A, MATRIX_STRUCT_SIZE);   Re: IMX8MP On chip RAM memory access Hi @Samhitha_Kashyap, Please note that the NXP does not recommend the modification in the node for 448 KB OCRAM Space as it is used by other drivers. One can use memory regions after 0x970000 to Support DMA using the compatible = "shared-dma-pool" property. Thanks & Regards Sanket Parekh Re: IMX8MP On chip RAM memory access Hi @Sanket_Parekh, Thanks for the response, it was helpful!  Would it be possible for me to modify the device tree to support DMA within the 448 KB OCRAM space, if I can't use it for the user application? Thanks & Regards, Samhitha Kashyap Re: IMX8MP On chip RAM memory access Hi @Samhitha_Kashyap , I hope you are doing well.   You can determine how much memory in the OCRAM, Linux kernel Reserved for itself by looking into the dtsi file (reserved memory node) of the soc in the case of imx8mp, it is 448 KB.   resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; };   ..... .....   }   So here 0x70000 ( 448K) bytes are reserved for Linux usage. and cannot be virtually mapped to the userspace as specified by the no-map property. after 0x7000 bytes you can use it for other applications. But you need to make sure that any  M7 core Application not using OCRAM. which can be determined by looking into the Linker script of a particular application.   Thanks & Regards Sanket Parekh   Re: IMX8MP On chip RAM memory access Hi Sanket, Would it be possible to verify how much memory the Linux utilizes and the rest can be used for the user application. If it is possible, how could I verify the same and allocate the rest of the memory for my application.  Thanks & Regards, Samhitha Kashyap Re: IMX8MP On chip RAM memory access Hi @Samhitha_Kashyap  I hope you are doing well. To access OCRAM First you need to ensure that you don't try to access the region that is used by ATF. in the case of u-boot, one can use md/mw command to access OCRAM directly. It is not recommended to use OCRAM in userspace as Linux itself uses it. Thanks & Regards Sanket Parekh

Question about RW612 OTBR Thread Certification Architecture Hello NXP Team,   I noticed the Thread Group certified component:   "NXP RW612 Wireless MCU With Integrated Tri-Radio OTBR" (Thread 1.4)   I also found separate certifications for:   - NXP i.MX MPU With IW610 Tri-Radio OTBR - NXP i.MX MPU With IW612 Tri-Radio OTBR - NXP RW612 Wireless MCU With Integrated Tri-Radio OTBR   I would like to better understand the certification architecture used for the RW612 OTBR certification.   Could you please clarify:   1. Was the certification achieved using RW612 as a standalone MCU/RTOS-based Thread Border Router?   2. Was an external RCP/NCP device used in the certified configuration?   3. Which software platform was used during certification (FreeRTOS, Zephyr, or another platform)?   4. Is there any public reference design or documentation describing the certified RW612 OTBR implementation?   Our goal is to understand whether the RW612 OTBR certification represents a standalone MCU-based Thread Border Router solution rather than a Linux-host-based OTBR architecture.   Thank you for your support.   Best regards, Kyonghwan Cho   Re: Question about RW612 OTBR Thread Certification Architecture Hello, Hope you are doing well. My name is Ricardo and I have been assigned this case. A1: Yes. The RW612 OTBR certification is a true standalone, single-chip solution. A2: No. Unlike the i.MX MPU + IW610/IW612 OTBR certifications (which use a Linux host with an external IW6xx radio co-processor in RCP mode), the RW612 certification does not use any external RCP or NCP device. A3: Let me confirm. A4: For specific details on the test configuration, test reports, or certification scope, please contact the Thread Group directly at threadgroup.org. Best Regards, Ricardo Re: Question about RW612 OTBR Thread Certification Architecture Hello @KyonghwanCho , Thank you for your patience. I have the confirmation that the SW platform used was FreeRTOS. Also, please check below OTBR user guide and build guide ot-nxp/examples/br/README-OTBR.md at release/v1.4.0.5_26.03 · NXP/ot-nxp ot-nxp/src/rw/rw612/README.md at release/v1.4.0.5_26.03 · NXP/ot-nxp Best Regards, Ricardo