PTP over SJA1110 Hi, We are debugging PTP on a PolarFire SoC GEM connected through an SJA1110 switch. We observe that: PTP over Layer 2 (ptp4l -2) is received by the switch (ingress counters increase), but it is not forwarded (egress counters do not increase). PTP over UDP (ptp4l ) is forwarded correctly through the same bridge path. Normal Ethernet traffic (ICMP/ARP) also forwards correctly. Is there any special handling or additional configuration required on the SJA1110 to forward Layer 2 PTP frames (destination MAC 01:1B:19:00:00:00) across bridged ports? Are there any known restrictions on forwarding Layer 2 PTP? Also, is PTP over UDP (ptp4l) fully supported and recommended with the PolarFire SoC GEM, or is Layer 2 the only supported/recommended transport? Any guidance would be appreciated. Re: PTP over SJA1110 Hello @Ankur_pixl , In a typical gPTP / time-aware bridge use case, the switch is not expected to forward all gPTP frames transparently as ordinary multicast traffic. The usual flow is that the switch receives the gPTP frames from the Grandmaster, processes them through the gPTP stack running on the internal Cortex-M7 and then generates its own gPTP frames with the appropriate timestamps towards the connected downstream devices.   SJA1110 is typically configured for the Layer 2 Automotive Profile, where the PTP destination MAC address is 01:80:C2:00:00:0E. This address is used for 802.1AS/gPTP style Layer 2 transport and such frames are normally handled by the switch PTP/gPTP function rather than simply bridged as regular multicast traffic.   Your observation that the ingress counters increase, while the egress counters do not increase, suggests that the Layer 2 PTP frames are received by the switch but are not forwarded through the normal bridge path. One likely explanation is that the used PTP multicast MAC address is matched by the SJA1110 configuration, for example in the General Parameters table, DPI configuration, L2 Lookup Table or another PTP/trap-related configuration item, and the frames are therefore trapped to the host port, most likely to the internal Cortex-M7 host, instead of being forwarded to the expected external egress port.   This would also explain why PTP over UDP and normal Ethernet traffic such as ICMP/ARP are forwarded correctly. These frames do not match the same Layer 2 PTP/gPTP classification rule and are therefore handled as normal bridge traffic.   Please check the following points in your SJA1110 configuration:   1. Which PTP destination MAC address is configured in the switch, especially in the General Parameters table. 2. Whether PTP/gPTP frames are configured to be trapped to the host port. 3. Whether the internal Cortex-M7 host is running a gPTP stack or receiving the trapped PTP frames. 4. Whether the used destination MAC address is 01:1B:19:00:00:00 or 01:80:C2:00:00:0E. 5. Whether the L2 Lookup Table or multicast forwarding configuration contains an entry that forwards this destination MAC to the required external ports. 6. Whether the ingress and egress ports are in the same VLAN and forwarding domain for this traffic.   If your intention is to use SJA1110 as a gPTP/time-aware bridge, then the expected configuration is usually not simple transparent forwarding of the original gPTP frames. The switch should participate in the gPTP timing domain and generate the corresponding gPTP messages towards the connected devices.   If your intention is instead to use SJA1110 only as a plain Ethernet bridge for raw Layer 2 PTP frames, then the PTP trapping/special handling must be disabled or avoided for this traffic, and the corresponding multicast destination MAC address must be explicitly allowed in the L2 forwarding configuration.   Regarding the PolarFire SoC GEM, I cannot make a definitive statement about the recommended or fully supported PTP transport mode for that device. From the SJA1110 point of view, PTP over UDP may be forwarded as ordinary IP/UDP traffic if the bridge path allows it. However, this does not necessarily mean that UDP transport is supported or recommended by the PolarFire GEM driver for hardware timestamping. Please confirm the supported PTP transport and timestamping modes with the PolarFire SoC GEM documentation or with Microchip support.   Best regards, Pavel Re: PTP over SJA1110 Hello @Ankur_pixl , The destination MAC address 01:1B:19:00:00:00 is an IEEE 1588 Layer 2 PTP multicast address. This is different from the 802.1AS / Automotive Profile gPTP destination MAC address 01:80:C2:00:00:0E, which is typically used in the SJA1110 gPTP Automotive Profile configuration.   Based on your description, this does not look like a standard Linux bridge MDB issue. The MDB entries may be correctly installed and even reported as offloaded, but the frame may still not reach the normal multicast forwarding path.   A likely explanation is that the SJA1110 hardware or the SJA1110 DSA driver classifies this destination MAC as a PTP/control frame before the normal L2 multicast forwarding decision is applied. In that case, the frame may be redirected to the CPU/management path instead of being forwarded directly between the two user ports.   This would explain the observed behavior:   - the ingress counter increases, so the frame is received by the switch, - the MDB entries are installed and shown as offloaded, - but the egress counter does not increase, because the frame is likely trapped to the CPU/management route before normal port-to-port forwarding is applied.   If the CPU/management route is not available in your port-to-port forwarding path, the trapped frame may effectively be dropped.   Regarding the Cortex-M7: if you are using the switch through the Linux DSA bridge and you do not run or control a gPTP stack on the internal Cortex-M7, then this should not normally be something configured from the Cortex-M7 application. In this use case, the relevant configuration is owned by the Linux DSA driver and by the switch hardware configuration programmed by that driver.   However, "bridge mdb" may not be sufficient if a dedicated PTP/control-frame trap rule is active for 01:1B:19:00:00:00. To forward this traffic directly in hardware between two user ports, the switch configuration would need to ensure that:   1. the PTP/control-frame trap for 01:1B:19:00:00:00 is disabled or bypassed for this traffic, and 2. a valid L2 multicast forwarding entry exists for 01:1B:19:00:00:00 towards the required user ports.   At this point, I would not expect the standard `bridge mdb` command alone to override a lower-level PTP/control-frame trap rule if such a rule is active in the SJA1110 DSA configuration.   As the next step, please check whether your SJA1110 DSA driver or BSP enables PTP hardware timestamping or installs any MAC filter / PTP trap rule for 01:1B:19:00:00:00. If such a rule is present, the solution will likely require a driver-level change or a switch static configuration change, rather than only a runtime Linux bridge MDB command.   Could you please share the following information?   - Linux BSP/kernel version, - SJA1110 DSA driver source baseline, - full output of "bridge -d mdb show", - the involved DSA port names and physical switch port numbers, - whether PTP hardware timestamping is enabled in the SJA1110 DSA driver, - and, if possible, a packet capture on the DSA master/CPU interface to confirm whether the Layer 2 PTP frames are being trapped to the CPU path.   With this information we can further check whether the frames are being consumed by the PTP/control trap path, or whether there is another L2 multicast forwarding limitation. Best regards, Pavel Re: PTP over SJA1110 Hello, The destination MAC is 01:1B:19:00:00:00. We're using the switch with the Linux DSA bridge and have no control or configuration access over the Cortex-M7 core. How do we allow this traffic through in the L2 configuration? We used bridge mdb, but it doesn't work; the entries install and even show as offloaded, yet the frames still aren't forwarded between the ports. Does this need to be set explicitly on the Cortex-M7 core? Additional context on our setup: Our MAC/port configuration is as follows: bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent These show as offloaded in bridge -d mdb show, but L2 PTP frames arriving on one port are not forwarded out the other. Importantly, one of the switch ports does not have a working CPU port; it operates purely as a route between two ports (port-to-port forwarding), with no host/CPU port in that path. Since the reserved multicast 01:1b:19:00:00:00 appears to be trapped to the management/CPU route by default, and that route is not available here, we suspect the frames are being dropped rather than forwarded. Could you advise how to configure the switch to forward this reserved PTP multicast MAC in hardware between the two user ports, without relying on a CPU/management port? -- Ankur

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

Fallback mechanism for failed AB_SWAP update Hello, We are developing an application that uses the AB_SWAP mechanism of the HSE firmware on the S32K342 to perform OTA updates. We are currently activating the passive block once the passive region of the flash is entirely written to. We were wondering whether there is a fallback mechanism that we can use to verify/check whether the image we are booting from is corrupted, and if we can fallback to the 'known good' active region that has become the passive region after resetting. This arises from the fact that on some occasions, we overwrite the passive region without issuing a reset and midway through we reset the processor, resulting in a corrupted image in the flash.  Re: Fallback mechanism for failed AB_SWAP update Hey @lukaszadrapa , Thanks for the clarification. We are still trying to understand which type of secure boot strategy to use in our application. Advance Secure boot seems a bit complicated with having to install the SMR and CR. On the other hand, Basic Secure boot seems slightly easier to install but the exact implementation and installation details seem unclear. I was wondering if you could provide some insight into these options. I am referring to the HSE B Reference Manual and was also wondering if there is any additional documentation I should be referring to for this. Regards, Shiv Re: Fallback mechanism for failed AB_SWAP update Hi @Shiv_peak  I answered very similar question a couple of days ago, please take a look at: https://community.nxp.com/t5/S32K/S32K-OTA-Rollback/m-p/2400332/highlight/true#M60125 If you need more details, just let me know. Regards, Lukas Re: Fallback mechanism for failed AB_SWAP update Can you also elaborate on what you mean by 'device goes in recovery mode' if the basic secure boot fails? Does this mean that the core will not be released from reset and there is no fallback or recovery in this case? I ask because we want to have the functionality where if the secure boot fails, we boot another image, possibly in the passive bank. Re: Fallback mechanism for failed AB_SWAP update We provide this application note: https://www.nxp.com/webapp/Download?colCode=AN13465   It’s updated version of Secure Boot application note v0.1.1.0 (AN744511) released in 2021 which can be downloaded from: https://www.nxp.com/products/S32K3 Application note can be found here: Documentation -> Secure Files -> Secure Boot Application note v0.1.1.0 (AN744511) Associated demo project can be downloaded here: Design Resources -> Software -> Secure Files -> SecureBootAppNoteDemo (SW745310) The software was not updated, so use mentioned SW745310 if you are interested. Other examples for secure boot can be found in HSE Demo Examples (recommended): https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples There are examples for all three modes – advanced secure boot, basic secure boot and SHE secure boot. Generally, advanced secure boot mode is recommended. Yes, it is not trivial task to configure the secure boot in this mode. However, it provides the best protection and configurability. The advantage is that you can select any signature scheme you want,  you can cover multiple regions and you can configure different sanctions if the secure boot fails. On other hand, basic secure boot mode always uses only GMAC tag which is calculated using a key derived from ADKP and it can cover one region only. If it fails, the device goes directly to recovery mode. I recommend to study following projects in HSE DemoExamples: S32K344_Advanced_SecureBoot S32K344_Basic_SecureBoot These are configuration projects which are supposed to protect application S32K344_SecureBootBlinky which is linked to those projects. Regards, Lukas Re: Fallback mechanism for failed AB_SWAP update Thanks for the clarity Lukas. I will look into the application note and the HSE demo examples and revert back in case of any queries. Regards, Shiv Re: Fallback mechanism for failed AB_SWAP update Ok that clears things up, thanks! So from what I am understanding: The Basic Secure Boot goes into recovery mode if the image verification fails. This recovery mode can be configured as Secure recovery using the attribute HSE_SECURE_RECOVERY_CONFIG_ATTR_ID. Configuring this mode requires programming the UTEST mode. Configuring this also needs the BOOT_SEQ == 1 in the IVT. The ADKP needs to be configured using HSE_APP_DEBUG_KEY_ATTR_ID in order to compute the GMAC. Couple of follow ups as I wrap my head around this: The Application Note you shared mentioned that configuring the ADKP can only be done in the CUST_DEL lifecycle. How do I verify the lifecycle of my system and is it safe to do so? Is the AppBL same as the IVT in the Basic Secure Boot. Do I need to append the GMAC and Recovery Image address to the IVT? Hoping to get a bit more clarity on these before I start implementation and testing on my boards. Thank you so much for being responsive and clearing my doubts! Regards, Shiv Re: Fallback mechanism for failed AB_SWAP update Take a look at section “2.6.1.3 Recovery Mode” in HSE firmware reference manual rev. 2.7. In short, there are two modes: JTAG based recovery mode – the device just hangs in endless loop in RAM (this piece of code is loaded to RAM by SBAF), so user can connect a debugger and perform some recovery steps. Secure recovery mode – this needs to be enabled by attribute HSE_SECURE_RECOVERY_CONFIG_ATTR_ID. Notice that this is OTP attribute programmed to UTEST memory. This starts recovery image which needs to be verified first. So, it is similar to basic secure boot. If the verification fails, it goes to JTAG recovery mode. The secure recovery mode can be used for recovery/rollback in runtime. But I do not recommend to run this from passive partition. All the code should be executed from active partition. In AB swap mode, you will have a copy of secure recovery image in both partitions anyway. Another option is to put this code to data flash memory if there’s enough space. Re: Fallback mechanism for failed AB_SWAP update See please my comments below. The Basic Secure Boot goes into recovery mode if the image verification fails. Yes. This recovery mode can be configured as Secure recovery using the attribute HSE_SECURE_RECOVERY_CONFIG_ATTR_ID. Yes. Configuring this mode requires programming the UTEST mode. The UTEST is programmed by HSE when calling set attribute service with HSE_SECURE_RECOVERY_CONFIG_ATTR_ID. Common issue – be aware that flash block 0 and UTEST are in the same read partition. You code cannot run from flash block 0 when programming this attribute. Configuring this also needs the BOOT_SEQ == 1 in the IVT. Yes. The ADKP needs to be configured using HSE_APP_DEBUG_KEY_ATTR_ID in order to compute the GMAC. Yes. Couple of follow ups as I wrap my head around this: The Application Note you shared mentioned that configuring the ADKP can only be done in the CUST_DEL lifecycle. How do I verify the lifecycle of my system and is it safe to do so? Yes, you can’t advance the life cycle until ADKP is set. Once the life cycle is advanced, secure debug is enabled, so you need to configure your debugger accordingly to be able to establish the connection. Take a look at this post: https://community.nxp.com/t5/S32K/S32K3-HSE/m-p/2066312/highlight/true#M47070 The life cycle status can be read from register DCMLCC in DCM module. Is the AppBL same as the IVT in the Basic Secure Boot. AppBL and IVT is signed and verified in the same way. IV and GMAC is also appended to the IVT. You can see that in “Table 118. IVT structure” in HSE firmware reference manual. Do I need to append the GMAC and Recovery Image address to the IVT? If you want to verify IVT, IV and GMAC must be added to IVT as mentioned above. If you want to use secure recovery image, pointer to the image and length of the image must be added to IVT. Regards, Lukas Re: Fallback mechanism for failed AB_SWAP update Thanks for the reply Lukas, this clarifies things! I will start implementing the Basic Secure Boot and will be in touch in case of any queries or doubts. Regards, Shiv 

S32K314 CAN issue I am using S32K314  , and recently I got a issue about CAN when I doing  the test by short-circuiting of the oscillator ; after recovery  ,I monitored  SPI ,ADC ,these modules works OK, but CAN module can not work normally, the debuger show these information,  in this status, CAN can not receive or send any fram, how could this happened, and how to recover this fault by sw? Snipaste_2026-08-04_13-32-47.jpg   Re: S32K314 CAN issue Hi,  Thanks for your  reply . I try to add some test code in "Mcu_ClockSourceFailure_Notification" , but this notification do not be trigged; so from software side , how can we notice this issue happened then reset CAN Module? thanks Below is the value of the registers you mentioned: MCR KidhRobin_0-1785975444257.png CTRL1 KidhRobin_1-1785975470032.png CBT: KidhRobin_2-1785975496485.png FDCBT: KidhRobin_6-1785975801928.png ECR KidhRobin_4-1785975599003.png ESR1 KidhRobin_5-1785975618985.png Re: S32K314 CAN issue Hi, From the provided screenshot, the receive error counter (RXERRCNT) is increasing while TXERRCNT remains 0, which does not fully match a typical transmit-related issue even though ESR1 indicates a transmission attempt is ongoing. The oscillator short-circuit could potentially have affected the clocking, resulting e.g. in incorrect CAN bit timing after recovery. However, the current information is not sufficient to confirm this. Could you please provide: a wider view of the FlexCAN registers (including MCR/CTRL1/CBT/FDCBT, ECR and ESR1), the module and CAN protocol clock configuration after recovery, TX, RX and CAN bus measurements captured during the failure? If the FlexCAN module clock and the CAN protocol clock are running and have the expected frequency, you can also try performing a FlexCAN module software reset followed by a complete module reinitialization and check whether communication is restored. BR, Petr Re: S32K314 CAN issue Hi, If Mcu_ClockSourceFailure_Notification() is not entered, my first assumption would be that the corresponding MCU interrupt/notification path is not configured or enabled in the project. Could you please check: Whether clock monitoring (CMU) is enabled for the affected clock source. Whether the CMU interrupt is enabled. Whether the MCU module is configured to call Mcu_ClockSourceFailure_Notification() upon detection of a clock failure. It may also be useful to inspect CMU and RGM status registers after the oscillator short-circuit event to verify that a clock failure is actually being detected. From the FlexCAN register dump, the module appears enabled and synchronized to the bus (SYNCH=1), while RXERRCNT increases and TXERRCNT remains 0, now without bus activity. I see the bit timing registers shown (CTRL1, CBT, FDCBT) do not contain a valid CAN timing configuration, although this may be expected if Enhanced CAN Bit Timing is used and the actual timing is configured through the respective enhanced CAN bit timing registers. Therefore, before implementing a CAN reset strategy, it would be good to first verify whether the clock failure event is detected at all and whether the notification mechanism is properly configured. BR, Petr

PNEV5190B does not work After loading Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin from the "Load Secondary Firmware" option on the Extra tab of NFC Cockpit, my PNEV5190B no longer responds and cannot be operated from NFC Cockpit. According to the update log, the firmware download completed successfully without any reported errors. The board became unresponsive only after the update was finished. I found a similar issue in this thread, but I would like to understand the root cause. What could cause the board to become unresponsive even though the firmware update completed successfully? Is it possible that I used an incorrect secondary firmware image for my board or firmware version? Why does loading the secondary firmware result in a state where NFC Cockpit can no longer communicate with the board? Thank you for your support. Re: PNEV5190B does not work Hello @Miyazaki001 Hope you are doing well. Could you please provide more details on your setup? What is the procedure you are following? I tried the following setup: - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - "Extra" tab > "Secondary FW" tab > Load Secondary Firmware - Select NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin NFC Cockpit should indicate to close the COM port and open it again: EduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.png After reopening the COM port, you should be able to start the Secondary Firmware in "Extra" tab. Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. My setup is as follows: - PNEV5190B (B1 chip) - PN5190 FW v02.05 - NFC Cockpit v7.4 - Extra tab → Secondary FW → Load Secondary Firmware Selected: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin The secondary firmware update appears to complete successfully. According to the log, the firmware download finishes without any reported errors. The relevant part of the log is shown below. 20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png After the update, NFC Cockpit prompts me to manually close and reopen the Board Connection. I followed this procedure, and I also tried disconnecting and reconnecting the COM port manually. However, after reopening the connection, the board no longer responds to any commands. The log shows a timeout when NFC Cockpit attempts to communicate with the board. I have attached the relevant log for your reference. Could you please advise: - Is PN5190 FW v02.05 compatible with this secondary firmware? - Is there any known issue with NFC Cockpit v7.4 and this secondary firmware? I found a similar issue in this thread, but I would like to understand the root cause. Thank you for your support. Best regards, Re: PNEV5190B does not work Hi, I could not locate any documented instance for an unexpected behavior using this specific setup. NFC Cockpit v7.4.0 is outdated; please update to the latest version available (v9.0.0) and perform FW update on PN5190. After this, let me know your findings. If this behavior persists after updating your setup, please let me know your jumper configuration and power connections (a picture of your board would also be helpful). Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. Based on your comment, we changed the NFC Cockpit version to the latest version, v9.0.0. We also updated the PN5190 firmware from v02.05 to v02.0D, which is the latest version available on the NXP website, and then retried the Secondary Firmware update. However, the result was the same, and the issue still persists. 画像.png画像.png画像.png画像.png画像.png画像.png画像.png画像.png We have also attached a photo of the board for reference. 画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg The following jumper settings are used: J8: Closed J9: 2–3 (External power supply) J12: Closed J22: Closed J23: Closed For this test, we are using an external 5 V DC power supply with a current limit of 1 A. Please let us know if there are any other settings or points we should check. Re: PNEV5190B does not work Hi, Your jumper and power configuration seems to be ok. By any chance, are you able to flash and run any of the demo applications (e.g. DiscoveryLoop) provided in the NFC Reader Library for PN5190? You can refer to PNEV5190B evaluation board quick start guide, Chapter 5.3, for more information on this. As an additional test, could you please try using a different PC and system language (not only display) set to English? Regards, Eduardo. Re: PNEV5190B does not work Hi, As mentioned in PNEV5190B evaluation board quick start guide, Section 5.1, it is recommended updating to the latest version of the firmware, using the latest version of the NFC Cockpit. An external debugger is necessary for the firmware programming, as described in NXP NFC Cockpit User Guide, Section 3.3. Unfortunately, there is no document available that provides a formal compatibility matrix between Bootloader versions and Secondary FW versions. The closest available reference is the version changelog inside the VCOM source package (NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h). Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. We will separately try the method you suggested. In the meantime, we performed an additional test on our side and obtained the following result. First, we programmed the following firmware included with NFC Cockpit v9.0.0 via J-Link: BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin After that, we updated the following Secondary Firmware using NFC Cockpit: Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin With this procedure, the error we had previously encountered did not occur, and the update completed successfully. Based on this result, we suspect that there may be a compatibility dependency between the BootLoader and Secondary Firmware versions. Could you please clarify the following points? 1. When changing the NFC Cockpit version, is it necessary to update not only the Secondary Firmware but also the BootLoader to a compatible version? 2. Is there a way to update the BootLoader using NFC Cockpit? Or is an external debugger/programmer such as J-Link required to update the BootLoader? 3. Is there any documentation describing the compatibility between the Secondary Firmware and BootLoader included with each NFC Cockpit version? For example, we would like to know which versions of the Secondary Firmware can be used with the same BootLoader. There is also another issue behind these questions that we would like to resolve. We have been controlling the PNEV5190B from our own application, rather than NFC Cockpit, using serial communication through the COM port. When using the Secondary Firmware included with NFC Cockpit v7.4.0, our application was able to communicate with and control the PNEV5190B successfully. However, after updating to the Secondary Firmware included with NFC Cockpit v9.0.0, the same application using the same communication method encounters a communication error. Could you also please clarify the following point? 4. Are there any changes between the Secondary Firmware included with NFC Cockpit v7.4.0 and v9.0.0 regarding the initialization sequence, COM communication settings, communication protocol, command specifications, or related behavior? If there are any release notes or documents describing these changes, we would appreciate it if you could share them with us. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your clarification. We understand that an external debugger is required to program the firmware, including the BootLoader. We also understand that there is no formal compatibility matrix between BootLoader and Secondary Firmware versions, and that the version changelog in the VCOM source package is the closest available reference. Regarding the other issue we mentioned, where our application could no longer communicate properly after updating the BootLoader and Secondary Firmware to the versions included with NFC Cockpit v9.0.0.0, we performed some additional investigation and found a difference related to DTR handling. For clarification, our application had previously been working with the BootLoader and Secondary Firmware included with NFC Cockpit v5.3, not v7.4. With the BootLoader and Secondary Firmware included with NFC Cockpit v5.3, our application was able to communicate successfully by simply keeping DTR statically ON after opening the COM port, without any explicit DTR state transition. However, with the BootLoader and Secondary Firmware included with NFC Cockpit v9.0.0.0, simply keeping DTR ON is not sufficient. We found that the board returns a response only after explicitly toggling DTR from LOW to HIGH. It appears that this transition is required at least once at the beginning of the communication session. We identified this DTR operation by capturing and analyzing the USB communication generated by UcBalPCTestApp.exe using Wireshark. Could you please clarify the following points? In the PN5190 VCOM Firmware, is the LOW-to-HIGH transition of DTR used as a trigger for any internal processing, such as communication session initialization or internal buffer handling? If so, is this behavior documented anywhere? Is it possible that this DTR behavior changed between VCOM Firmware versions? In particular, were there any changes related to DTR handling between the versions included with NFC Cockpit v5.3 and v9.0.0.0? Is there any officially recommended way to initiate communication without explicitly toggling DTR from LOW to HIGH on the host side, such as a specific IOCTL, vendor-specific command, or other mechanism? Thank you again for your support. Best regards, Re: PNEV5190B does not work Hi, The VCOM FW is intended for usage with our NFC Cockpit tool. If you are trying to create a custom implementation for a different tool, please consider using the NFC Cockpit VCOM source code as reference and adapt it to your needs. Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your clarification and support. We would like to use the same Secondary Firmware with both NFC Cockpit and our application. Therefore, we will refer to the NFC Cockpit VCOM source code and modify our application to support the current VCOM Firmware behavior. Thank you again for your support. Best regards, Miyazaki

MINISASTOCSI Latest Schematics Hi Team, Could you please help to share MINISASTOCSI latest schematics? Re: MINISASTOCSI Latest Schematics Hi @ramkrish, The most recent revision of the MINISASTOCSI board is A1. I have just sent the file to your email address for your reference. Please let me know if you have any trouble receiving it or if you need any additional information related to this board revision. Best regards, Chavira Re: MINISASTOCSI Latest Schematics Hi @Chavira Received, Thanks

K312 RTD3.0.0到RTD6.0.0 IIC部分驱动更换 Hi  当前我在RTD3.0.0中遇到了一个IIC  从机时钟挂起的问题，发现与IIC 的时钟延展功能相关，经过FAE的推荐，说6.0.0驱动中没有这个问题，因为项目周期原因，基于最小更改原则，我将 IIC的相关驱动文件从6.0.00中摘出，放到的我3.00 RTD 中，但是我发现无法正常运行。更改完成后，IIC一旦接收到数据，就无法退出中断。 我想请问： 1 、是否有人曾经尝试过这样的操作（3.00RTD 更换部分驱动为6.00），你们是否支持这样的更改，我还有别的关联驱动未移植吗？ 2、我发现 在6.0.00中有一个IIC的更改项目， 它在4.00中被修复了 5.00继承了这个修复，但是6.00又恢复到了3.00的逻辑，但是我在6.00的release note中并没有发现它的相关描述，请问6.00是做了其他更改修复了这个bug吗？ static void Lpi2c_Ip_SlaveIRQHandlerInternal(uint8 Instance) { LPI2C_Type *BaseAddr; Lpi2c_Ip_SlaveStateType * Slave; boolean StopDetect = FALSE; boolean RepeatStartDetect = FALSE; BaseAddr = Lpi2c_Ip_pxBase[Instance]; Slave = Lpi2c_Ip_pxSlaveState[Instance]; StopDetect = LPI2C_Get_SlaveSTOPDetectEvent(BaseAddr); RepeatStartDetect = LPI2C_Get_SlaveRepeatedStartEvent(BaseAddr); /* Check address valid and tx/rx event */ Lpi2c_Ip_SlaveCheckDataEvent(Instance, BaseAddr, Slave); if (RepeatStartDetect) { Slave->RepeatedStarts++; if ((1U == Slave->RepeatedStarts) && (Slave->Is10bitAddress))  //  此处  在4.00中已修改 { RepeatStartDetect = FALSE; LPI2C_Clear_SlaveRepeatedStartEvent(BaseAddr); } } if ((TRUE == StopDetect) || (TRUE == RepeatStartDetect)) { /* Stop/repeated start detected */ Lpi2c_Ip_SlaveStopDetectHandler(BaseAddr, Slave); if (TRUE == StopDetect) { /* reset repetead starts for a new transfer */ Slave->RepeatedStarts = 0U; } } /* Check for slave errors */ Lpi2c_Ip_SlaveCheckErrorEvent(BaseAddr, Slave); } 关联bug ：ARTD-6112 Reyna_pan45_0-1785920300296.pngReyna_pan45_0-1785920300296.pngReyna_pan45_0-1785920300296.png Re: K312 RTD3.0.0到RTD6.0.0 IIC部分驱动更换 嗨@VaneB 关于这个bug还有其他更相关的描述吗？我在测试过程中发现，即使无法确定根本原因，修改ARTD-81841项也可以缓解一些问题（在频繁切换中断时）。 Re: K312 RTD3.0.0到RTD6.0.0 IIC部分驱动更换 你好@Reyna_pan45 目前，由于调查仍在进行中，因此只能提供这些信息。由此造成的不便，我们深表歉意。 Re: K312 RTD3.0.0到RTD6.0.0 IIC部分驱动更换 NXP工程师能否尽快解决这个问题？因为我们在开发过程中遇到了这个问题，造成了不便，我们的客户也催促我们尽快解决。谢谢你！

ddr_stress_tester cannot work on some DDRs I have been using  ddr_stress_tester tools for many years, this year, I found the tool cannot work well on some newer manufacturing process DDRs, (20nm or 25nm DDRs),  we found that the binary will hang when I select cpu frequency. For example, winbond  w631gu6rb and ISSI IS43TR166640C-125JBLI-TR. by the way  CPU model is mx6solo/dl i.MX6DL Re: ddr_stress_tester cannot work on some DDRs The symptom is more likely tied to the DDR initialization/MMDC setup or board-level margin than to the DDR die process node itself. I could not find an NXP-documented issue that says the i.MX6Solo/DL ddr_stress_tester hangs specifically because the DDR3 is 20 nm/25 nm, nor anything specific to Winbond W631GU6RB or ISSI IS43TR166640C after checking NXP library/community paths by part number, process node, and “CPU frequency” hang wording. What I would check first: Use the i.MX6/7 DDR Tool flow, not an old fixed script The i.MX6/7 DDR tools are intended to generate and test a custom DRAM initialization based on the actual device configuration — density, chip-selects, bus width, board layout/swizzling, etc. — and they explicitly cover i.MX6DL/S devices. If you changed DDR vendors or DDR geometry/timing, regenerate the .inc initialization script using the DRAM Register Programming Aid / DDR tool flow; NXP notes that scripts “may need to be modified for your custom board and memory.” Do not assume old calibration values still apply The stress tool performs write leveling, DQS gating, read/write delay calibration, and stress testing on i.MX6 boards. If it hangs right after selecting frequency, the DDR may already be marginal before calibration can complete. NXP community guidance for similar i.MX6 DDR stress hangs points to incorrect MMDC parameters, power brownout, board noise, or layout issues. Check DDR voltage/mode and frequency selection i.MX6Solo/DualLite DDR pads support LPDDR2 and DDR3/DDR3L modes. For DDR3/DDR3L I/O supply, the i.MX6Solo/DL datasheet excerpt gives OVDD as 1.425–1.575 V for DDR3 and 1.283–1.45 V for DDR3L . The i.MX6 DDR stress tool supports DDR stress testing between 135 MHz and 672 MHz ; select a conservative DDR frequency first, then work upward after calibration passes. Review refresh timing There is an i.MX6 case where low-frequency hang was resolved by correcting MMDC0_MDREF , changing tREFI from 3.9 µs to 7.8 µs . NXP documentation also points to MMDCx_MDREF as the register controlling DDR refresh behavior, and notes that some DDR3 devices require temperature-dependent refresh changes, e.g. 64 ms refresh period at ≤85 °C and 32 ms above 85 °C. Eliminate known tool-environment hang causes If running from U-Boot, disable splash screen / IPU or any DMA that may still access DRAM; NXP notes that active IPU/splash access can make the system hang during the DDR stress flow. Check whether the watchdog fuse/configuration is enabled; NXP notes that on i.MX6Solo the watchdog can reset the device while DDR_Stress_Tester is doing calibration or stress test. If you are using the JTAG version, one reported i.MX6 case stopped after DDR frequency selection, and the guidance was to check JTAG mode/connection and use simple SDK DDR tests plus signal/power probing. My recommendation: regenerate the DDR init script for each new DDR part, start with a lower MMDC/DDR frequency, verify MDREF /timing values against the DDR datasheet, then rerun calibration. If it still hangs at CPU/DDR frequency selection, scope DDR power rails and clocks during that transition and compare MMDC register values between the old working DDR and the new Winbond/ISSI parts. The issue should be treated as an i.MX6Solo/DL DDR initialization and margin problem first; I did not find evidence that NXP identifies 20 nm/25 nm DDR3 process itself as a ddr_stress_tester incompatibility.

Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Subject: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi, I am trying to configure and program the OTP on the FS2400 using the KITFS24SKTFDMEVM evaluation board. Evaluation board: https://www.nxp.com/design/design-center/development-boards-and-designs/KITFS24SKTFDMEVM However, when I connect the board to the NXP GUI, I am unable to establish communication with the device. The GUI reports the error shown below, and no communication takes place. I have previously used the same NXP GUI with the FS26 evaluation board without any issues, so I believe my PC setup and GUI installation are working correctly. The evaluation board is in its default configuration, and I have not intentionally changed any jumper or switch settings. To verify, the current configuration is as follows: S12 (OTP): OFF J30: Pins 1-2 connected SW4 (WAKE2): ON S19 (WAKE3): ON J33: Open J37: Pins 2-3 connected J36: Pins 2-3 connected J10: Pins 2-3 connected SW9: All switches ON J45: Pins 2-3 connected J26: Pins 5-6 and 9-10 connected SW20: All switches OFF S2: ON (I could not locate this switch in the schematic ) SW18: All switches ON SW1 (Main Power Switch): Position 3 (2-3) I have not programmed the S32K144 MCU on the evaluation board. My understanding is that the board is shipped with the required firmware already programmed. Could someone confirm whether this is correct, or whether the MCU needs to be flashed before the GUI can communicate with the FS2400? Below is the error message displayed by the GUI: Any help would be greatly appreciated. Thank you. FS85&FS84 FSBC+PMIC Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hello, Thank you for contacting us. Could you please update the firmware according to Section 5, "Installing and Configuring Software and Tools," of the UM12015 KITFS24SKTFDMEVM User Manual? This procedure should resolve the error you are experiencing. If the issue persists after completing the update, could you please provide a picture of your hardware setup? This will help us review the configuration and investigate the problem further. Thanks! Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi @ErikaC , Thank you for your response. I checked Section 5, “Installing and Configuring Software and Tools,” of the UM12015 KITFS24SKTFDMEVM User Manual. However, I am unable to find the KITFS2400FRDMEVM_HW_Test_Package_W20.zip file mentioned in the document. Could you please let me know where I can download this .zip file? I need it to update the firmware as described in the manual. I was able to find fs23xx-fw-FS24-v0.86.hex in the NXP GUI. Is this the firmware file that should be used for the update, or is it a different file included in the KITFS2400FRDMEVM_HW_Test_Package_W20.zip? I also checked the link provided in the manual: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=S32DS-IDE-ARM-V2-XI downloaded and installed the executable from there (this was design studio but not the main S31244_Flash File), but I could not find the required .zip package. Could you please provide the download location for KITFS2400FRDMEVM_HW_Test_Package_W20.zip, or let me know where I can find the correct firmware package needed to perform the update? Thank you for your help. Ganesh Bhagwat Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi @ErikaC  If fs23xx-fw-FS24-v0.86.hex is the correct firmware file, is there any specific procedure required to directly load/flash this .hex file to the KITFS24SKTFDMEVM, or is there a specific tool/setup that needs to be used? If possible, it would also be greatly appreciated if you could provide the KITFS2400FRDMEVM_HW_Test_Package_W20.zip package or the download location for it, as this would make it much easier to follow the firmware update procedure described in the manual. Thank you for your help. Ganesh Bhagwat Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hello, I could not find the KITFS2400FRDMEVM_HW_Test_Package_W20.zip folder. It was likely included in an earlier version of NXPGUI. However, that package only contained the fs23xx-fw-FS24-v0.86.hex file, which is the only file required to program the firmware. ErikaC_1-1786381048598.png Please follow all the steps described in the UM12014 KITFS2400FRDMEVM User Manual. The use of a debugger is required, as shown in Figure 17, and you must also install the S32 Design Studio tool. The firmware update procedure cannot be completed successfully without the required debugger connection and software environment described in the user manual. Hope this helps! Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi @ErikaC , Thanks for this. It worked, and I am now able to communicate with the NXP-GUI. The only issue was that these two settings were not present by default. As you mentioned, after adding them, everything worked. The command added under Executable was: ${cross_prefix}gdb${cross_suffix} Thanks again for your support. Regards, Ganesh Bhagwat

[LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S69 Hi, I've been trying to get Zephyr's MCUboot to work on the LPC55XpressoS69 using core 0. I am running the simple Blinky sample application in Zephyr.  Running the application just fine without any errors. However, I've been trying to send a device firmware update (DFU) over UART using mcumgr and for some reason I can't even establish a connection between mcumgr and my device. I keep getting a "NMP timeout." For context, my directory structure looks like the following: | __boards                 |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf My prj.conf looks as follows:   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y My sysbuild.conf is as follows:   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y My mcuboot.conf looks like    CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   My mcuboot.overlay looks like /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; And finally my lpcxpresso55s69_lpc55s69_cpu0.overlay looks like / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; When I run the following MCUmgr command, I get back an NMP timeout, as seen below: > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout So the mcumgr definitely realizes that the port is available (it would deny access otherwise), but it keeps getting timed out. I'm pretty sure this is a config option error. I've tried changing the config options numerous times but nothing quite seems to do the trick. I'm also pretty sure I'm missing some config option somewhere which is crucial for this to work.  I've looked through about as many application notes and user manuals out there as I can. None of them seem to help for my particular case: DFU using Zephyr MCUboot on an LPC55Sxx chip running a Zephyr application. Any help would is appreciated, though it may be best if someone tried it out on their board e.g. LPCXpresso55S69 and confirm they can carry out a UART DFU with any simple program. LPC55S6x LPC55S69-EVK  LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @ZQ2  Since mcumgr echo is already returning NMP timeout, I think you can  verify the MCUmgr UART communication before debugging the MCUboot DFU flow. You can  confirm the following: flexcomm0 is the UART connected to COM11 on the LPCXpresso55S69 board. The application is running normally (not staying in MCUboot serial recovery mode). No console, shell, or log output is sharing the same UART used by MCUmgr. As a quick validation, I would recommend starting from Zephyr's smp_svr sample and verifying that the following command works first: mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR Harry Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @Harry_Zhang , Coincidentally, I was using Zephyr's smp_svr sample yesterday immediately after posting this question. I get the same exact problem though. I followed the Zephyr documentation for the sample at the following link. I simply created a project for the sample and then built the code successfully, enabling the configs for the Raw UART (serial) smp_svr option from the docs using the following command, as instructed: west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" And then I flashed the code successfully. Nonetheless: C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout   I even tried changing the debugger probe from Link2 to JLink, after which the debug probe became attached to COM16. I also disabled any mass storage device functionality, just in case, using JLink commander. Then I tried flashing and running: > west flash -r jlink but yet again: C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" Error: NMP timeout What could I possibly be missing? I assume it has something to do with the configs? If so, I wonder why the Zephyr official sample for smp_svr isn't compatible with the LPC55S69 and requires modification. Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @Harry_Zhang , Your solution does indeed work. In fact, I was able to strip down the command to merely west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" This also worked. Thank you a ton for replicating my problem, it's deeply appreciated. Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @ZQ2  I was able to reproduce and verify the setup on an LPCXpresso55S69 board. 1. The key point is that MCUmgr must be used together with MCUboot in this configuration. The application is linked to slot0 (not the flash base address), so building and flashing the smp_svr application alone will not work correctly. MCUboot is required to boot and hand over control to the application. 2. i add the overlay file lpcxpresso55s69_lpc55s69_cpu0.overlay in file /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards. &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. built the project using the following command: west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. after built it. you can use command  grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts Harry_Zhang_2-1786007232854.png 5. and west flash 6. Harry_Zhang_0-1786007007588.png 7. Harry_Zhang_1-1786007044209.png which confirms that the UART transport, SMP server, MCUmgr, and MCUboot integration are all working correctly. BR Harry

LX2162A USXGMII link never completes Hey all, I have an LX2162A SoM manufactured by Solidrun. I'm using a Clearfog devkit but moving to a custom carrier soon.  Solidrun provides base RCW/DCP/DPL and I've verified functionality. In my case, the DPC for dpmac3 works for the SFP cage and I get an XFI link via SFP DAC cable and various SFP modules. The RCW "rcw_2000_650_2900_3_11_0_auto" sets to SerDes1=3, SerDes2=11 and I'm using a QorIQ kernel (lf-6.6.52-2.2.0) and mc-utils (10.39.0) but with some Solidrun patched applied to both. Uboot and other things are also patched. All patches come from here: https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 I have a MaxLinear GPY245-EKV-1 (and -2) devkit(s) that wants USXGMII over DAC cable to connect the phy to the device. Apparently this is pretty normal. Eventually this phy chip will be integrated into SerDes2=7 Lane6 and Lane7 but I have to use the SFP cage on the Clearfog for testing. Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP I'm only trying to configure dpmac3 to use this USXGMII link via DPC: mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; (I've also tried MAC_LINK_TYPE_BACKPLANE) Confirmed via "restool dpmac info dpmac.3" shows "DPMAC ethernet interface: DPMAC_ETH_IF_USXGMII". In Linux, I added the MaxLinear driver and patched a few things: gpy_update_interface() fix (LKML, Daniel Golle). This was returning -EINVAL for USXGMII interface, crashing phy_state_machine. Patched lynx_pcs_config_usxgmii() in pcs-lynx.c to also write MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) via mdiobus_c45_modify(), since the function only ever wrote MII_ADVERTISE and never enabled AN on the Replicator block itself. This gap matches another post on this forum ("LS1028A 10g-qxgmii phy bring-up") which found the identical symptom (MMD31.0/Replicator control register stuck at 0) and got AN to kick in after manually setting bit 12. This is the DPMAC3 Linux devicetree entry: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; where `gpy245_0` is the MDIO node. MDIO traffic to the phy is working. I added a printout in the lynx_pcs driver which shows the readback: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 Question: Given writes to MDIO_MMD_VEND2 registers on this PCS instance don't appear to persist, is there a known additional step (SerDes/PCS block enable, protocol-specific initialization, or similar) required before the USXGMII on the LX2162A family SoCs will accept configuration? Is protocol 3 fully validated for USXGMII on dpmac3, or primarily intended/tested for XFI? Other questions: Maybe I don't understand GPY245 and USXGMII. I see some folks refer to this as QXGMII and I can't tell if the LX2162A is even capable of that working. Maybe I need to reach out to Solidrun, but all of their patches do not seem to limit the LX2162A's capability. Thanks! Re: LX2162A USXGMII link never completes @yipingwang I really appreciate the detailed response! Everything you said makes sense and I've started learning more about the platform. I've started using the advice in AN13329.pdf. Some of the addresses and things aren't working (probably a version mismatch) but at least I can get the MC log as shown below: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ I've attempted to poke at the PCCC via uboot. Here are the relevant things: crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... I really hope 0x1ea10b0 is the right address. According the LX2162ARM.pdf, that *could* be the right address and decoding the bits shows: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI Is the right right register address (PCCC) to observe? Is there any other information I can provide? Thanks! Re: LX2162A USXGMII link never completes The LX2162A side is documented to support USXGMII on the paths you are using , but the symptom you show looks less like a missing Linux pcs-lynx write and more like the selected PCS instance is still not actually in USXGMII application mode, or MC firmware is programming the wrong 10G PCS selector. For SerDes1 protocol 3 , the LX2162A reference manual lists all four SerDes1 lanes as USXGMII / XFI , including USXGMII / XFI.3 for the first lane, which corresponds to the DPMAC3 use case you are testing on the Clearfog SFP path . For your future custom-carrier target, SerDes2 protocol 7 also documents lane 6 and lane 7 as USXGMII / XFI.13 and USXGMII / XFI.14 . The important catch is that the USXGMII / XFI entry is not automatically “USXGMII.” The reference manual says that between USXGMII and XFI on a lane, the default is XFI . The mode is selected through PCCC , the Protocol Configuration Register C, and its SXGMII*_XFI bits select 0b = USXGMII and 1b = XFI/SFI . So the first thing I would check is not the Linux BMCR write itself, but whether the specific SXGMII instance for DPMAC3 has its PCCC XFI-select bit cleared after MC/DPC initialization. There is also precedent for this exact class of failure being in MC firmware , not in the Linux PCS driver: one LX2162A ticket shows MC clearing the wrong 10G interface selector in PCCC for a USXGMII configuration, and an MC firmware engineering build, version 10.35.101 , resolved the issue . Another ticket notes that MC settings are done by MC firmware, with NXP providing MC as a binary . Since you are on MC 10.39.0 , you should be beyond that specific old fix, but the failure mode you see is still consistent with “MC did not put the intended PCS into USXGMII mode” or “the wrong PCS instance is being addressed.” What I would do next: Read PCCC before Linux changes anything. After RCW + MC + DPL/DPC load, but before the Linux PCS driver runs, read PCCC and confirm the relevant SXGMII*_XFI bit is 0 . For DPMAC3 / USXGMII/XFI.3 , expect the first SXGMII selector, not the selector for MAC13/14. If that bit remains 1 , the lane is still XFI/SFI and your VEND2/USXGMII PCS writes are not being applied to a live USXGMII PCS path. Check that the MDIO access is hitting the intended PCS management port. The SXGMII protocol-control register has an MDEV_PORT field used to match MDIO accesses, and the manual says software must wait at least 3 platform clocks after changing it before MDIO accesses to the SGMII/PCS target . If the MDIO address decode is wrong, writes can appear to “not persist” because you are reading a different or reset/default PCS window. Confirm the USXGMII AN registers are meaningful only after the mode select is correct. The USXGMII PCS CONTROL register has AUTO_NEGOTIATION_ENABLE at bit 12, and DEV_ABILITY / PARTNER_ABILITY are RW registers . The DEV_ABILITY lower vendor arbitrary speed field must be non-zero, because zero can cause auto-negotiation failure . But if PCCC still selects XFI, these BMCR/ability writes are not the real root problem. Do not treat QXGMII as a separate required external protocol unless the GPY245 board documentation explicitly says so. LX2162A documentation does contain QXGMII protocol-converter registers, including reset/powerdown control bits such as PD_QXGM and RST_QXGM . NXP community material for LS1028A also refers to a 10G_QXGMII Lynx SerDes driver path . But the documented LX2162A DPMAC interface you are selecting is still USXGMII / XFI , and NXP documentation separately states that LX2160-class devices support USXGMII and that “SXGMII” is not the same thing . In other words: “QXGMII” references in driver/community discussions may describe an internal converter/driver naming path, not necessarily a different MAC-to-PHY contract than the USXGMII mode you configured. For this Clearfog SFP test, keep the DPC simple. MAC_LINK_TYPE_PHY with enet_if = "USXGMII" is the more natural model for a managed external PHY over MDIO. I would not expect MAC_LINK_TYPE_BACKPLANE to fix a PHY-facing USXGMII setup unless you are intentionally using a backplane/KR-style flow. I would not conclude that protocol 3 is “primarily XFI-only.” The reference manual documents protocol 3 as USXGMII / XFI for DPMAC3’s SerDes1 lane . What I cannot verify from the retrieved material is a separate validation statement saying “protocol 3 + DPMAC3 + USXGMII was validated with GPY245.” The stronger, evidence-backed statement is: the hardware mode exists, defaults to XFI unless PCCC selects USXGMII, and there is known MC-firmware precedent for programming the wrong 10G PCS selector . For your specific readback: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 that is exactly the kind of result I would expect if the PCS instance is not fully enabled/selected for USXGMII, or the MDIO management window is not addressing the intended PCS instance. I would verify PCCC and the MC log first, before adding more Linux-side writes. LX2162A protocol 3 is documented for USXGMII / XFI on DPMAC3, but USXGMII depends on MC/PCCC selecting the USXGMII PCS; if VEND2/BMCR writes do not persist, first prove the correct PCCC bit is cleared for DPMAC3 and that MDIO is addressing the correct SXGMII PCS instance. Re: LX2162A USXGMII link never completes Yes. For SerDes1 ,  0x1ea10b0  is the right address for PCCC : LX2162A CCSR map lists SerDes 1 at  0x1EA_0000–0x1EA_FFFF  . The SerDes memory map lists Protocol Configuration Register C / PCCC at offset  0x10B0  . Therefore: 0x1EA0000+0x10B0=0x1EA10B00x1EA0000+0x10B0=0x1EA10B0 So your U-Boot read: Copy => md.l 0x1ea10b0 1 01ea10b0: 88889991   is observing the expected SerDes1 PCCC register. The important caveat is the naming: I would not describe those fields as physical SerDes lane A/B/C/D for your current setup. In the LX2162A SerDes1 protocol table, protocol  3  maps physical lane H / lane 0 to  USXGMII / XFI.3  , then lane G/lane 1 to  .4  , lane F/lane 2 to  .5  , and lane E/lane 3 to  .6  . PCCC field names such as  SXGMIIA_XFI  ,  SXGMIIB_XFI  , etc. are PCS/protocol-control fields, not necessarily the same naming convention as the physical lane letters. For your value  0x88889991  , the high nibbles decode like this: Copy PCCC = 0x88889991 bits 31:28 = 0x8 -> SXGMIIA_XFI = 1, CFG = 000 bits 27:24 = 0x8 -> SXGMIIB_XFI = 1, CFG = 000 bits 23:20 = 0x8 -> SXGMIIC_XFI = 1, CFG = 000 bits 19:16 = 0x8 -> SXGMIID_XFI = 1, CFG = 000 bits 15:12 = 0x9 -> SXGMIIE_XFI = 1, CFG = 001 bits 11:8 = 0x9 -> SXGMIIF_XFI = 1, CFG = 001   The key bit is the  _XFI  bit. The RM defines  0  as USXGMII mode and  1  as XFI/SFI mode for these fields . So the value you read strongly suggests the relevant USXFI/SXGMII PCS instances are still being selected as XFI/SFI , not USXGMII. That lines up with your symptom: Linux/restool may report  DPMAC_ETH_IF_USXGMII  , but if PCCC still has the relevant  _XFI  select bit at  1  , the underlying SerDes/PCS selection is still effectively in XFI/SFI mode. The RM also explicitly says that to enable 10G-SXGMII, software must set  PCCC[SGMIIa_XFI] = 0  . Your MC log extraction also looks sane. AN13329 says to read MCFBAL/MCFBAH at  0x8340020  , build the MC firmware base, then dump the log-buffer structure at offset  0x01000000  ; the structure contains the magic, log-buffer offset, and log-buffer length . Your  0x21e1000000  dump shows the expected  0x4d430100  magic and points to log offset  0x01400000  , which matches your later dump at  0x21e1400000  . What I would capture next: PCCC snapshots at each stage Copy md.l 0x1ea10b0 1 Capture it: immediately after reset / before MC boot if possible, after MC boot, after DPC/DPL apply, after Linux boots, after the DPMAC is probed/configured. Adjacent protocol config registers Copy md.l 0x1ea10a0 1 # PCC8 md.l 0x1ea10a4 1 # PCC9 md.l 0x1ea10b0 1 # PCCC PCC8/PCC9 contain other SGMII configuration fields, while PCCC is the SXGMII/XFI selector register . Confirm which PCCC field changes when you try forcing USXGMII If you can safely poke in U-Boot for experiment only, try clearing the candidate  _XFI  bit and reading it back immediately. For example, if dpmac3 corresponds to the first SXGMII/USXFI control field, clearing bit 31 would be the experimental check: Copy mw.l 0x1ea10b0 0x08889991 1 md.l 0x1ea10b0 1 If it immediately reads back as  0x88889991  , then either the write is blocked/overridden, or that field is not writable in the current block state. If it sticks until MC or Linux runs, then MC/Linux is likely restoring XFI/SFI mode. Full RCW SerDes decode You already have  SerDes1=3, SerDes2=11  ; that matches the dpmac3 lane being available as  USXGMII / XFI.3  under SerDes1 protocol 3 . Still, include the full RCW string and raw RCW dump when escalating, because MC firmware often keys off the complete protocol set. MC firmware + DPC/DPL artifacts Since your MC is  10.39.0  , include: MC firmware version, DPC source, DPL source, exact  dpmac@3  block, restool dpmac info dpmac.3  , the PCCC value after each step. My current read of your data: yes,  0x1ea10b0  is the correct SerDes1 PCCC address, and  0x88889991  looks like the relevant PCS selectors are still in XFI/SFI mode. That is consistent with XFI working through the SFP cage and USXGMII not accepting/retaining the expected PCS configuration.

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

S32K3 ADC Optimize DMA Streaming Hello, When the adc group has only one channel and the Adc Enable Optimize DMA Streaming Groups configuration item is checked, a hard fault occurs when the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function is executed. In the case of a single channel, if the Adc Group Without Interrupts configuration item is checked and ACCESS_MODE_STREAMING, Select Adc Streaming Dma Channel is enabled. Otherwise, the number of the dma channel in the configuration file is 255, which is reasonable here. But what I don't understand is why when ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_GROUPS is STD_ON, instead of STD_ON==GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function will be called. This seems unreasonable, and also because the call to this function leads to hard fault. Jason22_0-1785831767968.png BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 Please do not use your QQ email account next time; please use your company email account instead. I tested this, but I didn't find any problems. I have attached my test project and test result for your reference. Also, i check your code and i found some error in your code. 1.clock init is wrong, your code can't not run successfully, Senlent_0-1785915417329.png 2."adc_group0_val" should be attribute to "no-cacheable area" also: The usage instructions for Optimize DMA streaming groups are clearly explained in the user manual. RTD_ADC_UM.pdf Senlent_0-1785915908665.png Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent The optimization level of my project is -O0, and I ran your project (also with -O0). I found that in Adc_Ipw_SetupTcdSingleAdcChannelMajorLink -> ...... -> Dma_Ip_ConvertLogicChToHwCh, the LogicCh value is still 255. 1.png In your screenshot, was Dma_Ip_ConvertLogicChToHwCh called as a result of Adc_Ipw_SetupTcdSingleAdcChannelMajorLink? Mcl_Init also calls Dma_Ip_ConvertLogicChToHwCh, and in that case LogicCh is 0, which seems consistent with your screenshot. I ran a test in your project. When Adc_Ipw_SetupTcdSingleAdcChannelMajorLink indirectly calls Dma_Ip_ConvertLogicChToHwCh, I observed that &Dma_Ip_pxInit->ppxLogicChannelConfigArray[LogicCh] is 0x429F28, which matches &Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]. 2.png I then modified the value at address 0x429F28 to 0x1FFFFFF0, and executed the code at line 348. 3.png A hard fault occurred, and the BFAR value was 0x1FFFFFF6, as expected. 4.png This confirms that the out‑of‑bounds access does exist. Whether a hard fault occurs depends on the value at Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]. Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent The picture in the last reply is not clear. I have uploaded the picture again in the form of attachment. I numbered the order of the pictures with numbers. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Thank you very much for your reply. I have registered a new account using my company email address, and I will use that account after this thread is closed. I ran your project and found that no hard fault occurred. However, my question still remains. As shown in the screenshot below, the function Adc_Ipw_SetupTcdSingleAdcChannelMajorLink configures the DMA_IP_CH_SET_MAJORLOOP_LOGIC_LINK_CH parameter for the DMA channel. When Dma_Ip_ConvertLogicChToHwCh is called, the LogicCh value is 255. Dma_Ip_pxInit->ppxLogicChannelConfigArray points to the Dma_Ip_paxLogicChannelConfigArrayPB array, which has a size of 2. Accessing Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] should be an out‑of‑bounds access. Although no hard fault occurred, I believe this is not reasonable. Jason07_0-1785979871220.png Jason07_1-1785979890128.png Jason07_2-1785979907208.png This out‑of‑bounds access is caused by calling Adc_Ipw_SetupTcdSingleAdcChannelMajorLink, which is another question I have. I have reviewed the relevant content in RTD_ADC_UM.pdf and also checked the driver code. For Optimize DMA Streaming Groups (single channel), the data is transferred directly from the CDR to the user buffer, unlike the multi‑channel case where data is first moved from the CDR to the DmaIntermediateBuffer and then from there to the user buffer. Optimize DMA Streaming Groups (single channel) does not use a Streaming DMA channel. In the configuration file, the values of AdcIpwConfigPtr->Mapping.AdcCountingDmaChanLogicId array are indeed ADC_IPW_INVALID_DMA_CHANNEL_ID (255). Jason07_3-1785980010767.png I do not understand why Adc_Ipw_SetupTcdSingleAdcChannelMajorLink still needs to be called. The function that really should call this is Without Interrupt Group (single channel), but when ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_GROUPS is STD_ON, instead of STD_ON == GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function is called. Jason07_4-1785980037684.png I have found the issue in my project: when I uncheck "Data sections", the hard fault no longer occurs. However, I do not think this is the key point of the problem. Jason07_5-1785980062079.png BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason07 @Jason22 Please set the optimization build option to -O0 . This is the result I observed during single-step debugging. Senlent_1-1786003373031.png This is likely because the build optimization (-Os) prevents the debugger from accurately mapping source code variables. Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Yes, I used your project without any modifications. In your video, the Dma_Ip_ConvertLogicChToHwCh function is called indirectly by Mcl_Init, which is not the intended behavior. The intended behavior is for Adc_Ipw_SetupTcdSingleAdcChannelMajorLink to indirectly call Dma_Ip_ConvertLogicChToHwCh. My video demonstrates this: while running Mcl_Init, I skipped all breakpoints, and after Mcl_Init completed, I re‑enabled the breakpoints. At that point, Dma_Ip_ConvertLogicChToHwCh was entered again, and LogicCh was 255. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 These are my test results. If you are using the project I provided and the optimization level is set to -O0, then our observations should be the same. I don't think there's anything wrong here. If the boundary is exceeded, it should definitely enter a hard fault, but the test results didn't, which can only mean that it's due to the compilation optimization level. There's no need to continue analyzing under an error condition. Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent I'm glad you can see that LogicCh is 255. In your project, it does run correctly, but this is an out‑of‑bounds access, right? Regarding your statement: "If the boundary is exceeded, it should definitely enter a hard fault" – I don't fully agree with that. In C language, there is no runtime boundary checking like in C++. For a pointer array, whether a hard fault occurs depends on the value obtained from the out‑of‑bounds access. Consider a pointer array: uint32* pArr[2] = {0x20400000, 0x20400004}. Suppose the address of pArr is 0x204300A0, then the value of pArr[2] is the value is stored at address 0x204300A8. If 0x204300A8 contains 0x20400008, then *pArr[2] (an out‑of‑bounds access that ultimately reads the value at address 0x20400008) will not cause a hard fault. However, if 0x204300A8 contains 0x1FFFFFF0, then *pArr[2] (which ultimately reads from 0x1FFFFFF0) will cause a hard fault. Both are out‑of‑bounds accesses, but whether a hard fault occurs is a matter of probability. To be precise, the hard fault is not directly caused by the out‑of‑bounds access itself, but rather because the out‑of‑bounds access to the pointer array got an invalid pointer, and accessing that invalid pointer triggers the hard fault. This is exactly why, in your project, accessing Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]->LogicChId.HwChId does not cause a hard fault, but in my project, it does. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 I will send you the design team's feedback. Usually, if it's a bug with significant impact, they will release it in a new version and include it in the release notes.  Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Thank you very much for reporting this issue to your design team. If there is a final result, where should I check for it? If there is indeed an error, will it be published in a document similar to SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf? BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Sorry. Step4 is Click the ‘Step Over’ button. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent I'm not sure if my operation was correct – I tried debugging with your ELF file but it didn't work. 1.png Could you please perform the same steps as shown in my video? I believe you will be able to reproduce the issue. Here are the steps: Set a breakpoint at the line Mcl_Init(NULL_PTR);. Run the program until it hits the breakpoint at Mcl_Init(NULL_PTR);. Disable all breakpoints (Click the ‘skip all breakpoints’ button). Step over Mcl_Init(NULL_PTR);(Click the ‘Step All’ button) Re‑enable breakpoints(Click the ‘skip all breakpoints’ button) and Click the ‘resume’ button. You will see that Dma_Ip_ConvertLogicChToHwCh is entered again, and LogicCh is 255. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 I can forward this issue to the design team for confirmation. Since I wasn't the one who designed the RTD driver, I won't delve into why they designed it this way unless users encounter problems. This feedback process might be lengthy, but I will relay the findings to the relevant design team. Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 I might still not understand your question. I'd like to ask if this project is running as expected? If it is, is there any problem? I can see LogicCh is showing 255, but the program is running normally. Is there anything wrong with this?

Error reporting module MCU: S32K148 in 144 pin package RTD version: SW32K1_S32M24x_RTD_4.4_3.0.0_QLP03_D2507 S32 DS Version: 3.6.6 Target OS: Bare Metal Host OS: Windows With the above, I cannot find a module called "ERM" (or anything similar) in the driver module. I have looked in both both MCAL and Non-MCAL modules. Is the ERM supported as a driver module or should the user manipulate raw pointers, as it used to be with the older 'Processor Expert' based framework? Re: Error reporting module Hello @VaneB  Thank you for the follow up. So what you are saying is that these modules are supported in the SPD drivers only and not the freely available RTD. Is that right? Is there any reason why someone cannot use these modules just by bit-banging the registers of the module directly? I tried an example for the 'Processor Expert' driver model (using S32 DS v2.2) and it seemed to work. Re: Error reporting module Hi @durga_choudhury  For S32K1 devices, the Safety Peripheral Drivers (SPD) are available. These drivers include the Extended Microcontroller Error Manager (eMCEM), which supports memory error injection and detection through the Error Injection Module (EIM) and Error Reporting Module (ERM) hardware modules. For further information regarding the SPD, please contact your NXP representative or one of our authorized distributors in your region (Distributor Network | NXP Semiconductors). BR, VaneB Re: Error reporting module Hi @durga_choudhury  Yes, your understanding is correct. They are provided as a separate software package and is not included as part of the RTD. Regarding the reason for this separation, I am currently reviewing internaly. However, it is important to note that SAF and SPD were developed as safety-oriented software components in compliance with the ISO 26262 functional safety standard. This enables their integration into applications requiring functional safety support up to ASIL D. Re: Error reporting module Thank you very much for the update.

新舊硬件版號差別 _0-1785831056367.png 同樣 ringo 版本，為什麼 左邊是舊的 版號 332 可以使用，右邊新的 B222 不能使用，332/B222 區別 怎麼樣 B222可以正常使用

RW612 WiFi Init stuck on HAL_ImuLinkIsUp() I am trying to run the MQTT example on a custom board. The module used is ublox IRIS-W106-30B. I followed the instructions to use j-link to install the wifi fw blob serperatly. However, I am getting stuck in an infinite loop in WPL_Init().   natered21_0-1785877418073.png I was also unable to initialize the BLE due to similar issue. SDK 25.09.00 using MCUXpresso  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Yes, I am able to run my normal application code, log to UART etc.  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Hi, Are you able to test a simple Hello World example? Also, have you already applied the required modifications to enable your module? Please refer to the following article for guidance. Regards, Daniel. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Are you using the RD-RW61X-BGA SDK or the FRDM-RW612 SDK? Which files did you modify to port the original example to your module? Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() If I'm understanding correctly, you're able to run the Wi-Fi and Bluetooth examples on your custom board without any issues. The problem appears when you start integrating or porting the networking functionality into your own application. My recommendation is to use the MQTT example as the foundation for your application. If your use case requires Wi-Fi and BT/BLE to run simultaneously, then it would be better to start from one of the coexistence examples and add your application-specific functionality on top of it, rather than trying to add coexistence support to an existing custom application afterward. By the way, SDK 25.09 is already three releases behind. I would recommend upgrading to the latest SDK 26.06 before continuing. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() SDK_2.x_RW610 From the mqtt example I copied everything from "main_task" and after into my existing project. This leave the hardware init, as a major difference. I am unable to identify which aspects from the example are causing IMU to not initialize.  I can run the base example project on my custom board but am unable to port it into existing project. 

Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello. I am currently developing based on the MPC5777C MCU. I have a question regarding the development process. I designed code to perform ECC checks based on the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code. Under normal circumstances, this code performs the ECC checks correctly. However, when running the ECC check code with a debugger like Trace32 connected to the MCU, errors often occur where bit errors are not detected. Is it possible that the "GHS614" example code as a whole does not function correctly when connected to a debugger such as Trace32? Thank you. Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello. Assuming the Trace32 debugger is connected and the dump window is open, and my custom application code is running, is it possible for a case to occur where a bit error is not detected within the ECC check function, which was designed referencing GHS614? Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello, I am not sure what your setup is, but have in mind that any open dump window in the Trace is constantly reading the memory and will rise the ECC fault immediately if detected. ECC errors will never happen on the not corrupted address. As ECC mechanism is also guarded by EDC. Such is simply not possible. Best regards, Peter Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello, If the address which is read by SW or by debugger is corrupted ECC will always rise indepenant of example SW, or any other influences. best regards, Peter Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello. I will explain the situation in a little more detail. My ECC check code execution is as follows: (void)FCCU_ClearNCF(); /* 1-bit RAM data Error Injection */ GenerateRam1bitEccError(); uiErmSR0 = ERM.SR0.R; uiErmSR1 = ERM.SR1.R; uiErmSR2 = ERM.SR2.R; /// 4. If a RAM 1-bit ECC Error occurs, perform the following. if((((uiErmSR0 & ERM_SR0_1b_all) == ERM_SR0_1b_PRAMC_1) || ((uiErmSR2 & ERM_SR2_1b_all) == ERM_SR2_1b_Core1_data)) && ((uiErmSR1) == CLEAR)) { /// 4.1. If the value stored in the ERM EAR Register is the same as the address where the error occurred, perform the following. if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_PRAMC_1].EAR.R)) { ucStatus = OK; } /// 4.2. If the value stored in the ERM EAR Register is not the same as the address where the error occurred, perform the following. else if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_Core1_data].EAR.R)) { ucStatus = OK; } else { ucStatus = NOT_OK }; } /// 5. If no RAM 1-bit ECC Error occurred, perform the following. else { ucStatus = NOT_OK }; This structure forcibly injects a 1-bit RAM Data Error and checks whether the ECC error occurred successfully and the address of occurrence was accurately detected. If the Trace32 memory dump window is enabled while the above code is running, could the results of the ECC check be executed abnormally? (i.e., failure to detect ECC error or an error at the ECC occurrence address) Thank you.

S32DS ARM 2018 R1 许可证延期申请 你好我的许可证已经过期，因此我想申请延期。 zhangtr_0-1785825418457.png Re: S32DS ARM 2018 R1 许可证延期申请 谢谢

Not able to Download S32K3 Standard Software Not able to download  V1_0-1785824291602.png Re: Not able to Download S32K3 Standard Software Hello, I have just download it with no issues. Try different browse, clear cookies, etc... Download itself is working properly on NXP side. Best regards, Peter

LPC5514JBD64E Use for WS2812. Hi, Is LPC5514JBD64E suitable for working with WS2812 for a beginner. If yes Where Can I get The Code and other Details.  Thank you. LPC55xx Re: LPC5514JBD64E Use for WS2812. hi @Kishore02  Thank you for your post! There is not information about the implementation of WS2812 for the LPC551x, you could use the Programmable Logic Unit to do it, in another devices there are example using the FlexIO modules like in application code hub for the MCXA366: https://mcuxpresso.nxp.com/appcodehub?search=an-emulating-ws2812-bus-with-flexio-on-mcx366  Also, there is a post of a colleague that implement it for a Kinetis board: NXP FlexIO Generator for the WS2812B LED Stripe Protocol Hope this information help as a reference