软件启动时出现Synchronous Abort" handler, esr 0x02000000 1、一个偶现故障(上千次重启出现1次)：软件在uboot启动过程中卡死，故障现场是："Synchronous Abort" handler, esr 0x02000000，根据反汇编查看具体调用，发现是：initr_pci→pci_init→dm_pciauto_config_device（pci_auto.c:371）→ dm_pci_hose_probe_bus（pci-uclass.c:607）→dm_pciauto_prescan_setup_bridge → bl dm_pci_get_bdf 后 ret 返回时取指 0x8202fc20 发生异常。问题出在ret到了不正确的地址，而调用的asr只是寄存器移位，它本身没有任何可能出错的地方（不访问内存、不跳转）。 2、软件使用cpld主动喂狗(外部看门狗)，在问题出现后，外部看门狗使用PORESET进行复位，但未能成功 Re: 软件启动时出现Synchronous Abort" handler, esr 0x02000000 你好， 这不太可能是 asr 指令本身的错误。关键症状是 ret 从损坏或不正确的链接寄存器加载 PC，导致从 0x8202fc20 获取指令。因此，中止操作很可能是在指令获取阶段检测到的，而损坏则发生在更早的时候。 最可能的原因 首先调查以下几个方面： 堆栈损坏或堆栈溢出 检查每个 PCI 递归级别的 sp 。 在 U-Boot 堆栈周围添加堆栈金丝雀。 确认 PCI 枚举值未超过配置的堆栈大小。 无效的函数指针或损坏的 LR 捕获 x30/LR 、 SP 、 PC 以及 bl dm_pci_get_bdf 之前和之后的所有寄存器。 确认栈上保存的 LR 与预期的返回地址匹配。 反汇编完整的二进制文件，而不仅仅是源代码。 内存损坏 检查 DDR 稳定性、ECC/错误状态、缓存配置和 DMA 活动。 暂时禁用数据缓存、推测性访问和并发 DMA。 用已知模式填充未使用的内存和堆栈，然后在故障后检查损坏情况。 PCIe 配置访问超时/错误 在枚举之前，请确认链路训练和控制器 RESET 已完成。 验证缺失的设备是否返回合法的完成错误，而不是程序挂起或产生无效数据。 禁用 PCI 初始化进行测试；如果问题消失，则重点检查 PCIe 硬件/配置时序。 为什么外部看门狗复位可能会失败 即使 CPU 正在执行损坏的代码，CPLD 仍然可以向看门狗提供信号，因此系统可能永远不会达到看门狗超时。此外， PORESET 可能无法重置使系统保持故障状态的逻辑，或者其脉冲可能不符合所需的宽度/序列。 NXP 文档将外部看门狗逻辑描述为独立的 RESET 触发信号，但其实际 RESET 路径和受影响的功能域必须在 SoC 和板 RESET 架构中进行验证。 用示波器或逻辑分析仪检查： CPLD 看门狗超时输出 SoC引脚上的 PORESET HRESET /系统重置 PMIC复位输入/输出 复位尝试期间的电源轨 恢复后的RESET原因寄存器 建议的调试实验 修改监控策略，使其： U-Boot 仅通过受控的周期性路径向外部看门狗提供数据。 在 PCI 枚举期间，监视程序不会被喂食。 超时时，CPLD 会产生一个足够长的复位脉冲，以满足 SoC/PMIC 规范。 记录复位原因并将故障寄存器保存在 SRAM 或其他保持区域中。 下一个最有价值的工件是包含 PC 、 LR/x30 、 SP 、 ESR 、 FAR 、 SPSR 以及保存的返回地址周围的堆栈内容的完整异常转储。如果没有这些数据，故障定位只能确定检测到损坏的返回数据的位置，而不能确定损坏的源头。   此致

i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Hi NXP team, We are evaluating ECDSA P-384 black key/blob support on i.MX8DXL CAAM. Observed results P-256 Starting from an externally provided plaintext P-256 private key: Plaintext key → COVER → black key blob Restore black key from black blob ECDSA sign/verify Result: PASS P-384 (CAAM-generated black key) Generate ECDSA private key as KEY_COLOR_BLACK Generate black blob from private key without COVER operation Restore black key from black blob ECDSA sign/verify Result: PASS P-384 (external plaintext private key) Starting from an externally provided plaintext P-384 private key (48 bytes): Plaintext key → COVER → black key blob Restore black key from black blob ECDSA sign/verify Result: FAIL Additional observation We noticed the following comments in the NXP patch: https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEY commands seems limited to 32 bytes, so we should use the load * command instead which can load up to 64 bytes. * * TODO: The KEY command indicate it should be able to load key bigger * than 32bytes but it doesn't work in practice * * TODO: The LOAD command indicate it should be able to load up to 96 * byte keys it doesn't work in practice and is limited to 64 bytes */ We observed similar behavior. Using the LOAD command instead of the KEY command allows us to handle keys larger than 32 bytes, including a 48-byte P-384 private key. However, this does not resolve the issue above. Although the key can be covered and stored in a blob, the restored black key cannot be used successfully for ECDSA sign/verify.   Our questions: Is there any known limitation of the CAAM COVER operation for ECC private keys larger than 32 bytes? Is importing an external P-384 plaintext private key through COVER and then using it as an ECDSA black key a supported use case? Is the observed behavior expected due to a CAAM hardware limitation? Is there a recommended CAAM method to import an externally generated P-384 plaintext private key and use it as a black key for ECDSA operations? Any guidance would be appreciated. Thanks and best regards, hojames. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Additional note:   Our concern is not limited to the ECDSA use case.   Even if importing an external P-384 private key through COVER is not a supported ECDSA workflow, we would still like to understand the limitations of the COVER operation itself.   In our application, the COVER operation may also be used to protect general sensitive data, not only ECDSA private keys. Therefore, support for payload sizes larger than 32 bytes is an important consideration. Based on our testing, using the LOAD-command workaround allows handling payloads larger than 32 bytes. Payloads below approximately 80 bytes appear to work, while larger sizes show inconsistent behavior. We would like to understand whether these observations reflect an actual CAAM limitation or an implementation issue. Could NXP also clarify whether there are any documented size limitations for the COVER operation itself, independent of the ECDSA use case?   Thank you. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case We need to set up the environment to test this CAAM function. We will update you once We have some results. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Hi yipingwang, Thanks for the reply. >>For this part, what CAAM error did you observed? >>Could you provide the error code? We are using below code patch for all ECDSA related operations: "https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch" when calling caam_ecdsa_verify() for signature verification, it returns 'ECDSA_VERIFY_FAIL (0)'. The error occurs only with the case 'P-384 (external plaintext private key)'. >> The application note "AN12838-Strengthening Public Key Cryptography using CAAM Secure Key" describe a demo for ECDSA signature using black key, are you testing with similar implementation? For our succeed cases, yes, they are similar. But for our failed case 'P-384 (external plaintext private key)', it is a bit different: the key is from external. Best regards, Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case "Plaintext key → COVER → black key blob Restore black key from black blob ECDSA sign/verify Result: FAIL" For this part, what CAAM error did you observed? Could you provide the error code? The application note "AN12838-Strengthening Public Key Cryptography using CAAM Secure Key" describe a demo for ECDSA signature using black key, are you testing with similar implementation? Thank you.  For the KEY command limitation, it is still under investigation.  Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case For the failed case, are you using "KEY" command and "FIFO STORE" command to generate the black key based on the plaintext private key? Is it possible for you to dump the CAAM descriptors(the hex words) used in failure cases? It would be easier to check the commands and parameters. Thank you. Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case Hi yipingwang, >>For the failed case, >>are you using "KEY" command and "FIFO STORE" command >>to generate the black key based on the plaintext private key? No, we are using the LOAD command instead of the KEY command. The key is 48 bytes (P384) in this case. As mentioned in <https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch> "KEY commands seems limited to 32 bytes, so we should use the load * command instead which can load up to 64 bytes.". If use the KEY command for 48 bytes key, DECO error is reported: job ring status: 0x40000106, DECO, 06h - Invalid KEY Command So we modifed the code to use LOAD command the same as the patch code above. Thanks and best regards, Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case I have validated that an ECC P-384 key can be loaded to PKHA-E memory using the KEY command, and it can subsequently be used for ECDSA sign and verify.  Please check if you are using the "Class 1" register in KEY command, the Class 1 Key register on MX8DXL is 32 bytes. So please use PKHA-E memory instead. Here is the CAAM descriptor for your reference: Covert the plaintext private key to black key, the CAAM command is "KEY" + "FIFO STORE". b0800005 02010030    // KEY 60220030  ....0.....t.0."`    // FIFO SOTRE Please check the reply per the questions: Is there any known limitation of the CAAM COVER operation for ECC private keys larger than 32 bytes? The KEY command is effective at loading the KEY registers, but only to their respective max sizes.  So, the Class 1 Key register, the Class 2 Key register, and PKHA E register can all be loaded by the KEY command, but they will all have different sizes.  In general, the Class 2 Key Register is larger (128 bytes) than the Class 1 Key register, and could be substituted in this process for the use of ECC keys (which will not be larger than 1028 bytes).  More generally, you could always use the KEY command to put the ECC key into PKHA E and then store it from there as a black key. Is importing an external P-384 plaintext private key through COVER and then using it as an ECDSA black key a supported use case? Yes, the ECDSA Sign operation will accept a black key for signing. Is the observed behavior expected due to a CAAM hardware limitation? Yes.  If you LOAD (or STORE) beyond a register’s size, you will be dealing with dead space – so the LOAD bytes to the dead area are lost, and the STORE bytes will have a zero value.  The Class 1 Key register on MX8DXL is 32 bytes (256 bits),  big enough to handle a key for the available symmetric cipher engines, like AES. Is there a recommended CAAM method to import an externally generated P-384 plaintext private key and use it as a black key for ECDSA operations? Yes.  Load it into PKE (PKHA E register) and do the FIFO STORE from there like you would for a Class 1 Key (just use a different register source).

The software encountered a "Synchronous Abort" error during startup: "handler, esr 0x02000000". 1. An intermittent fault (occurring once out of thousands of reboots): The software freezes during the u-boot process. The fault message is: "Synchronous Abort" handler, esr 0x02000000. Disassembling the code reveals the following call path: initr_pci → pci_init → dm_pciauto_config_device (pci_auto.c:371) →dm_pci_hose_probe_bus (pci-uclass.c:607) → dm_pciauto_prescan_setup_bridge→ When fetching pointer 0x8202fc20 after `bl dm_pci_get_bdf` and `ret`, an exception occurred. The problem is that `ret` was accessing an incorrect address, while the `asr` call is just a register shift and has no inherent error-prone parts (it does not access memory or jump). 2. The software uses CPLD to actively feed the watchdog (external watchdog). After the problem occurred, the external watchdog was reset using PORESET, but it failed. Re: 软件启动时出现Synchronous Abort" handler, esr 0x02000000 Hello, This is not likely an error in the asr instruction itself. The key symptom is that ret loads the PC from a corrupted or incorrect link register, causing instruction fetch from 0x8202fc20 . The abort is therefore probably detected at instruction fetch, while the corruption occurred earlier. Most likely causes Investigate these areas first: Stack corruption or stack overflow Check sp at every PCI recursion level. Add stack canaries around the U-Boot stack. Verify that PCI enumeration does not exceed the configured stack size. Invalid function pointer or corrupted LR Capture x30/LR , SP , PC , and all registers immediately before and after bl dm_pci_get_bdf . Confirm that the saved LR on the stack matches the expected return address. Disassemble the exact binary, not only the source code. Memory corruption Check DDR stability, ECC/error status, cache configuration, and DMA activity. Temporarily disable data cache, speculative accesses, and concurrent DMA. Fill unused memory and stack with known patterns, then inspect corruption after failure. PCIe configuration access timeout/error Confirm that link training and controller reset are complete before enumeration. Verify that absent devices return a legal completion error rather than hanging or producing invalid data. Test with PCI initialization disabled; if the issue disappears, focus on PCIe hardware/configuration timing. Why the external watchdog reset may fail The watchdog can still be fed by a CPLD while the CPU is executing corrupted code, so the system may never reach the watchdog timeout. Also, PORESET may not reset the logic that is holding the system in the failed state, or its pulse may not meet the required width/sequence. NXP documentation describes external watchdog logic as an independent reset trigger, but its actual reset path and affected domains must be verified in the SoC and board reset architecture. Check with an oscilloscope or logic analyzer: CPLD watchdog timeout output PORESET at the SoC pin HRESET /system reset PMIC reset input/output power rails during the reset attempt reset-cause registers after recovery Recommended debug experiment Modify the watchdog policy so that: U-Boot feeds the external watchdog only from a controlled periodic path. The watchdog is not fed during PCI enumeration. On timeout, the CPLD generates a reset pulse long enough for the SoC/PMIC specification. Record reset cause and preserve the failing registers in SRAM or another retention area. The most valuable next artifact is a complete exception dump containing PC , LR/x30 , SP , ESR , FAR , SPSR , and the stack contents around the saved return address. Without that data, the failure location identifies where the corrupted return is detected, not where the corruption originated.   Regards

i.MX8DXL CAAM COVER 对 P-384 私钥/黑斑用例的限制 您好，NXP团队： 我们正在评估 i.MX8DXL CAAM 对 ECDSA P-384 黑键/blob 的支持情况。 观察到的结果 P-256 从外部提供的明文 P-256 私钥开始： 明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：通过 P-384（CAAM 生成的黑键） 生成 ECDSA 私钥，颜色为 KEY_COLOR_BLACK 无需 COVER 操作即可从私钥生成黑块 从黑斑中恢复黑键 ECDSA 签名/核实 结果：通过 P-384（外部明文私钥） 从外部提供的明文 P-384 私钥（48 字节）开始： 明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：失败 补充观察 我们在NXP的补丁中注意到以下注释： https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEY 命令似乎限制为 32 字节，因此我们应该使用加载方式。 * 改为使用最多可加载 64 字节的命令。 * * TODO：KEY 命令表明它应该能够加载更大的密钥。 * 小于 32 字节，但实际上行不通 * * TODO：LOAD 命令表明它应该能够加载最多 96 个文件 * 字节键在实践中不起作用，并且限制为 64 字节。 */ 我们观察到了类似的行为。 使用 LOAD 命令而不是 KEY 命令，我们可以处理大于 32 字节的密钥，包括 48 字节的 P-384 私钥。 然而，这并不能解决上述问题。虽然可以将密钥覆盖并存储在一个块状物中，但恢复后的黑密钥不能成功用于 ECDSA 签名/验证。   我们的疑问： CAAM COVER 操作对于大于 32 字节的 ECC 私钥是否存在任何已知限制？ 通过 COVER 导入外部 P-384 明文私钥，然后将其用作 ECDSA 黑密钥，这是否是支持的用例？ 观察到的这种现象是否是由于 CAAM 硬件限制造成的？ 是否有推荐的 CAAM 方法可以导入外部生成的 P-384 明文私钥并将其用作 ECDSA 操作的黑密钥？ 任何指导都将不胜感激。 谢谢，并致以最诚挚的问候！ 霍詹姆斯。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 补充说明：   我们关注的重点不仅限于 ECDSA 用例。   即使通过 COVER 导入外部 P-384 私钥不是 ECDSA 支持的工作流程，我们仍然想了解 COVER 操作本身的局限性。   在我们的应用中，COVER 操作不仅可以用于保护 ECDSA 私钥，还可以用于保护一般敏感数据。因此，支持大于 32 字节的有效载荷大小是一个重要的考虑因素。 根据我们的测试，使用 LOAD 命令变通方法可以处理大于 32 字节的有效载荷。小于约 80 字节的有效载荷似乎可以正常工作，而更大的有效载荷则表现出不稳定的行为。我们想了解这些观察结果反映的是 CAAM 的实际局限性还是实施问题。 NXP能否也澄清一下，COVER 操作本身是否存在任何已记录的大小限制，而与 ECDSA 用例无关？   谢谢！ Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 我们需要搭建测试CAAM功能的环境。一旦有了结果，我们会立即通知您。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 王一平您好， 谢谢回复。 >>对于这一部分，您观察到了什么CAAM错误？ >>请提供错误代码？ 我们对所有与 ECDSA 相关的操作都使用以下代码补丁： " https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch " 当调用 caam_ecdsa_verify() 进行签名验证时， 它返回“ECDSA_VERIFY_FAIL (0)”。 仅当使用“P-384（外部明文私钥）”时才会出现错误。 >> 应用笔记“AN12838-使用 CAAM 安全密钥加强公钥密码学”描述了使用黑密钥的 ECDSA 签名演示，您是否正在使用类似的实现进行测试？ 对于我们成功的案例，是的，它们很相似。 但对于我们失败的案例“P-384（外部明文私钥）”， 情况略有不同：密钥来自外部。 顺祝商祺！ Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case “明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：失败 在这一部分，你观察到了什么CAAM错误？能否提供错误代码？应用笔记“AN12838-使用 CAAM 安全密钥加强公钥密码学”描述了使用黑密钥的 ECDSA 签名演示，您是否正在使用类似的实现进行测试？谢谢。 关于KEY命令的限制，目前仍在调查中。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 对于失败的案例，您是否使用“KEY”命令和“FIFO STORE”命令根据明文私钥生成黑密钥？您能否提供故障案例中使用的 CAAM 描述符（十六进制单词）？检查命令和参数会更容易些。谢谢。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 王一平您好， >>对于失败的案例， >>您是否使用了“KEY”命令和“FIFO STORE”命令？ >>如何根据明文私钥生成黑密钥？ 不，我们使用的是 LOAD 命令而不是 KEY 命令。 在这种情况下，密钥为 48 字节 (P384)。 如 < https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch > 中所述 “KEY 命令似乎限制为 32 字节，因此我们应该使用加载 * 改为使用最多可加载 64 字节的命令。 如果使用 KEY 命令输入 48 字节的密钥，则会报告 DECO 错误： 作业环状态：0x40000106 DECO，06h - 无效的 KEY 命令 因此，我们修改了代码，使其使用与上述补丁代码相同的 LOAD 命令。 谢谢，并致以最诚挚的问候！ Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 我已经验证过，可以使用KEY命令将ECC P-384密钥加载到PKHA-E内存中，并且该密钥随后可用于ECDSA签名和验证。 请检查您是否在 KEY 命令中使用“Class 1”寄存器，MX8DXL 上的 Class 1 Key 寄存器为 32 字节。所以请改用PKHA-E内存。 以下是 CAAM 描述符供您参考：将明文私钥转换为黑钥，CAAM 命令为“KEY” + “FIFO STORE”。 b0800005 02010030    // 密钥 60220030 ....0.....t.0."` // FIFO SOTRE 请根据问题查看回复： CAAM COVER 操作对于大于 32 字节的 ECC 私钥是否存在任何已知限制？ KEY 命令可以有效地将数据加载到 KEY 寄存器中，但只能加载到各自的最大值。因此，1 类密钥寄存器、2 类密钥寄存器和 PKHA E 寄存器都可以通过 KEY 命令加载，但它们的大小各不相同。一般来说，2 类密钥寄存器（128 字节）比 1 类密钥寄存器大，因此可以在此过程中用 2 类密钥寄存器代替 ECC 密钥（ECC 密钥的大小不会超过 1028 字节）。更一般地说，您可以始终使用 KEY 命令将 ECC 钥匙放入 PKHA E 中，然后将其作为黑钥匙存储。 通过 COVER 导入外部 P-384 明文私钥，然后将其用作 ECDSA 黑密钥，这是否是支持的用例？ 是的，ECDSA Sign 操作接受黑色钥匙进行签名。 观察到的这种现象是否是由于 CAAM 硬件限制造成的？ 是的。 如果加载（或存储）的数据超过寄存器的大小，就会进入死区——因此，加载到死区的字节会丢失，而存储的字节的值将为零。MX8DXL 上的 Class 1 密钥寄存器为 32 字节（256 位），足以处理 AES 等可用对称密码引擎的密钥。 是否有推荐的 CAAM 方法可以导入外部生成的 P-384 明文私钥并将其用作 ECDSA 操作的黑密钥？ 是的。将其加载到 PKE（PKHA E 寄存器）中，然后像处理 1 类密钥一样从那里执行 FIFO 存储（只需使用不同的寄存器源）。

i.P-384秘密鍵/ブラックブロブの利用ケースにおけるMX8DXL CAAMカバーの制限 こんにちは、NXPチームの皆様、 私たちは、i.MX8DXL CAAMにおけるECDSA P-384ブラックキー/ブロブのサポートを評価しています。 観察された結果 P-256 外部から提供された平文のP-256秘密鍵から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（CAAM生成の黒鍵） ECDSA秘密鍵をKEY_COLOR_BLACKとして生成する COVER操作なしで秘密鍵からブラックブロブを生成する 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（外部平文秘密鍵） 外部から提供された平文のP-384秘密鍵（48バイト）から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 追加の観察 NXPのパッチに以下のコメントがあることに気づきました。 https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEYコマンドは32バイトに制限されているようなので、ロードを使うべきです * コマンドは最大64バイトまで読み込み可能です。 * * TODO: KEYコマンドは、より大きなキーをロードできるようにする必要があることを示しています * 32バイトより小さいが、実際には機能しない * * TODO: LOAD コマンドは最大 96 までロードできるはずです * バイトキーは実際には機能せず、64バイトに制限されています */ 我々も同様の挙動を観察した。 KEYコマンドの代わりにLOADコマンドを使用することで、48バイトのP-384秘密鍵を含む、32バイトを超える鍵を扱うことができます。 しかし、これは上記の問題を解決するものではありません。鍵は覆ってブロブに保存できますが、復元された黒鍵はECDSA署名や検証に成功裏に使用できません。   私たちの質問： CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？ COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか? 観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？ 外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか? 何かアドバイスをいただければ幸いです。 ありがとうございます。よろしくお願いいたします。 ホジャメス。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 補足事項：   私たちの懸念はECDSAのユースケースに限られません。   COVERを介して外部のP-384秘密鍵をインポートすることがECDSAの標準ワークフローではないとしても、COVER操作自体の制限事項を理解しておきたいと考えています。   当社のアプリケーションでは、COVER操作はECDSA秘密鍵だけでなく、一般的な機密データの保護にも利用されることがあります。したがって、32バイトを超えるペイロードサイズのサポートは重要な考慮事項です。 我々のテストに基づくと、LOADコマンドの回避策を用いることで、32バイトを超えるペイロードを処理できることがわかった。約80バイト以下のペイロードは正常に動作するようですが、それより大きいサイズでは動作が不安定になります。これらの観察結果が、実際のCAAMの制限を反映しているのか、それとも実装上の問題を反映しているのかを理解したいと考えています。 また、ECDSAのユースケースとは独立して、COVER操作自体に文書化されたサイズ制限があるかどうかもNXPは明確にしていただけますか?   よろしくお願いします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case このCAAM機能をテストするための環境を構築する必要があります。結果が出次第、ご連絡いたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case こんにちは、イーピンワンさん ご返信ありがとうございます。 >>この部分で、どのようなCAAMエラーが発生していましたか？ >>エラーコードを教えてもらえますか? ECDSA関連のすべての操作には、以下のコードパッチを使用しています。 " https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch " 署名検証のために caam_ecdsa_verify() を呼び出すとき、 'ECDSA_VERIFY_FAIL (0)' を返します。 このエラーは「P-384 (external plaintext private key)」の場合のみ発生します。 >> アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストしていますか? 私たちの成功例については、はい、似ています。 しかし、失敗したケース『P-384(外部平文秘密鍵)』については、 少し違います。鍵は外部から来ています。 よろしくお願いいたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 「プレーンテキストキー → カバー → 黒キーの塊」 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 この部分で、どのようなCAAMエラーが発生していましたか？エラーコードを教えてもらえますか?アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストされていますか?ありがとう。 KEYコマンドの制限については、現在も調査中です。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 失敗した場合、「KEY」コマンドと「FIFO STORE」コマンドを使って、平文の秘密鍵に基づいて黒鍵を生成していますか?失敗時に使われるCAAMの記述子(十六進形の単語)を捨てることは可能ですか?コマンドとパラメータを確認する方が簡単でしょう。ありがとう。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case こんにちは、イーピンワンさん >>失敗したCASEのために、 >>「KEY」コマンドと「FIFO STORE」コマンドを使っていますか? >>平文の秘密鍵に基づいて黒鍵を生成するのですか? いいえ、KEYコマンドではなくLOADコマンドを使用しています。 この場合、キーは48バイト(P384)です。 < https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch > に記載されているとおりです。 「KEYコマンドは32バイトに制限されているようだ。だからロードを使うべきだ * コマンドは最大64バイトまで読み込める。 KEYコマンドで48バイトのキーを使用すると、DECOエラーが報告されます。 ジョブリングステータス: 0x40000106、 DECO、06h - 無効なKEYコマンド そこで、上記のパッチコードと同じLOADコマンドを使うようにコードを変更しました。 ありがとうございます。よろしくお願いいたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case ECC P-384キーはKEYコマンドでPKHA-Eメモリにロードでき、その後ECDSA署名や検証に使用できることを検証しました。 KEYコマンドで「クラス1」レジスタを使用しているかどうか確認してください。MX8DXLのクラス1キーレジスタは32バイトです。ですので、代わりにPKHA-Eメモリをご利用ください。 参考までに、CAAM 記述子を以下に示します。平文の秘密鍵をブラックキーに変換するには、CAAM コマンドは「KEY」+「FIFO STORE」です。 b0800005 02010030    // キー 60220030 ....0....t.0."` // FIFO SOTRE 質問に対する回答をご確認ください。 CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？ KEYコマンドはKEYレジスタへのデータロードに有効ですが、それぞれの最大サイズまでしかロードできません。したがって、クラス1キーレジスタ、クラス2キーレジスタ、PKHA EレジスタはすべてKEYコマンドでロード可能ですが、それぞれ異なるサイズを持ちます。一般的に、クラス2キーレジスタはクラス1キーレジスタよりも大きく(128バイト)、このプロセスでECCキー(1028バイトを超えない)の使用に代わることができます。より一般的には、KEYコマンドを使ってECCキーをPKHA Eに入れ、そこからブラックキーとして保存する方法もあります。 COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか? はい、ECDSAの署名業務では、署名にブラックキーを使用できます。 観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？ はい。 レジスタのサイズを超えてLOAD(またはSTORE)するとデッドスペースが発生し、デッドエリアへのLOADバイトは失われ、STOREバイトはゼロの値になります。MX8DXLのクラス1キーレジスタは32バイト(256ビット)で、AESのような対称暗号エンジンの鍵を処理するのに十分な大きさです。 外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか? はい。それをPKE（PKHA Eレジスタ）にロードし、クラス1キーの場合と同様にそこからFIFOストアを実行します（ただし、レジスタソースは別のものを使用します）。

Request for Marking Specification - PN# MFS2633HMDA0AD Dear Sir/Madam, We have received part number MFS2633HMDA0AD. We are unable to get the chip marking information for incoming part verification. Could you please help provide the Marking Specification document for this part? Your support will be much appreciated. Best regards, Joey

S32K36xブートローダーの実装 親愛なるNXPサポートチームへ、 現在、あなたのマイクロコントローラをアプリケーション向けに評価しているところです。特にS32K364マイクロコントローラモデルを使いたいと思っています。しかし、ブートローダー機能をどのように実装すればよいのか分かりません。 CAN-FDでMCUをフラッシュしたい場合、4年前にオリジナルのS32K31x/K32x/K34x用に作成された既存の「統一ブートローダーデモ」を単純に適用すればいいのでしょうか?それともS32K36xシリーズ専用の公式なブートローダー例プロジェクトを直接使えるのでしょうか? よろしくお願いいたします！ Re: S32K36x Bootloader Implementation こんにちは、 @SewerynPさん 利用可能なS32K3ブートローダーのサンプルについては、こちらに概要をまとめていますのでご覧ください。 https://community.nxp.com/t5/S32K/S32K385-Bootloader/m-p/2367874/highlight/true#M58710 NXPは、S32K3派生製品ごとに、製品版としてすぐに使用できるブートローダーコードを提供しているわけではありません。利用可能なブートローダーのデモは、自社のソリューション開発の出発点として意図されたリファレンスソフトウェアであり、S32K364に適応可能です。本番環境向けのソリューションとしては、Vector Flash Bootloaderのようなサードパーティ製品を検討できます。 よろしくお願いいたします。 ルーカス

MCU-LINK not working Hi, I am trying to use an MCU-LINK on a new PC (Windows 10 laptop) unfortunately without much success! I installed mcuxpresso, and when I plug the MCU-LINK into a USB port it makes the usual noise like it is enumerating, but mcuxpresso cannot see the probe and in Windows device manager, there is a yellow warning triangle next to the "USB composite device" that appears with a message in device status that says "This device cannot start (Code 10). Insufficient system resources exist to complete the API" I also tried manually downloading the MCU-LINK driver installer for Windows 10 from the NXP website, but still no success. Any pointers please? This is a relatively new laptop which I would not expect to be short on resources for this. Many thanks -Nick Re: MCU-LINK not working Hello, I found myself with the exact same problem. I just managed to solve it, so hopefully it can be usefull. I did the following: Going to C:\nxp\LinkServer_26.6.137\MCU-LINK_installer\scripts , click in "program_CMSIS", then follow the instructions on the command pannel (i.e., Short Jumper J3 of the MCU-link -> Connect via USB the MCU-link -> press space bar). (Otherwise you can try write "CMSIS" or look for "Program MCU-Link CMSIS-DAP" in the search bar of Windows to find directly the file). After perfoming this, the device was properly recognised without warnings by the computer in Device Manager and i could successfully debug my board. Not sure if related, or if it helped to work (maybe not required), but before performing that firmware update of the mcu-link i did: 1- Did "Windows Security" -> "App & browser control" -> Smart App Control settings -> off. 2- I re-installed the LinkServer installer, which you can find in "LinkServer for Microcontrollers" on nxp website. Also, after doing firmware update: 1- open mcuxpresso IDE with "run as administrator", and then on the project Explorer, i opened the project folder, and in the bottom i deleted the folder "(*project_name*)_ LinkServer Debug.launch" before debugging the code. This is the way that it worked for me. Hope someone finds it useful as well. Best, Kans. Re: MCU-LINK not working hi, im also using mcu-link, its working fine, when its connected directly to the laptop port, but when im using a usb hub, and connecting the mcu -link through that usb hub, the debbugging is not working, its throws an error, how can i overcome this?, im only having one port in my laptop, so its neccessary to use via an hub Re: MCU-LINK not working I can think of two other alternatives: One is making sure your Antivirus is not detecting the MCU-LINK as a threat, and disabling it for good measure. The second is trying with a different computer. If the problem persists with a different machine, then we have reasons to believe that the problem could be MCU-LINK related. Otherwise, I believe the problem is most likely related to the OS or the cable. I hope this helps. Re: MCU-LINK not working thanks @EdwinHz  Yes, we downloaded the drivers from that location. We are not using a USB hub, this is a direct connection. Will try a different USB cable, but this seems unlikely. Any other suggestions please? Thanks!   Re: MCU-LINK not working Hi @nickwallis, The drivers that you installed manually were from the “MCU-Link installer for Windows 10” software found at the bottom of the MCU-Link Debug Probe website? If not, I would recommend reinstalling the drivers using this installer. Check the connection to your MCU-LINK. If it’s connected to a USB hub try connecting it directly to the machine. Also try using a different USB cable. Regards, Edwin.

RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Platform: MacOS 15.6.1 (24G90) VS Code (Version: 1.112.0 (Universal)) MCUXpresso for VS Code: 26.8.29 Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 Application: amp_blinky imported as zephyr-freestanding Board: MIMXRT685-EVK Description: I am setting up dev environment on MacOS, same steps were working fine on my Linux machine. While build and flash threw no critical warning/error with MCUXpresso, application was running fine on both Arm and DSP cores. Then I edited the code under remote/src and remote/prj.conf, and flash it after a pristine build. However, the DSP core still ran the previous image before editing. Below are some of the interesting behaviors: I tried to edit the Arm core code too, but that change was applied successfully. Changes in the DSP core code can trigger a non-pristine build instead of showing "no work to do." Disabling CCACHE in cmake seems to solve the issue So far to me, it looks like a cahce-related issue that the compiler ignores the changes in the DSP image while running sysbuild, and uses the cached binary, regardless it has been rebuilt. It is probably caused by nxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgs.S isn't updated. Also, it might be a MacOS-only issue since I didn't notice it on my Linux machine. Is this a known issue? Is there an elegant solution instead of disabling CCACHE? Best Regards, Yue ZEPHYR-OS-EDGE  i.MXRT 600 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Dear @YueZ , Thank you for your questions. So far, this is not a known issue on our side. To help identify the root cause, could you please check whether the following outputs are updated consistently? The DSP BIN generated by the remote build process. The object file generated from dspimgs.S. The final Arm BIN that is actually programmed onto the device. If the DSP BIN has been updated, but the object file generated from dspimgs.S has not, one possible reason is that the build system did not update the DSP BIN timestamp. As a result, the dependency check may have skipped recompiling dspimgs.S. We recommend adding the following content to the CMake configuration responsible for dspimgs.S to ensure changes in the DSP BIN trigger a rebuild: set(DSP_BIN_DIR ${CMAKE_BINARY_DIR}/../remote/zephyr) set_property(SOURCE ${CMAKE_CURRENT_SOURCE_DIR}/src/dspimgs.S PROPERTY OBJECT_DEPENDS ${DSP_BIN_DIR}/zephyr_reset.bin ${DSP_BIN_DIR}/zephyr_text.bin ${DSP_BIN_DIR}/zephyr_data.bin ) (Please also verify that the actual file path is correct.) Please let us know if you have any questions.   Best Regards, Shelly Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Hello Shelly, Thanks for your reply! I checked the timestamps of the three DSP BINs under build/remote/zephy, the final Arm BIN, and the dspimgs.S.obj under build/amp_blinky/CMakeFiles/app.dir/.../adsp/rtxxx/common/src/, they were all updated by either pristine or non-pristine build. I also tried the recommended CMake configuration by replacing  set_source_files_properties( "${CMAKE_CURRENT_LIST_DIR}/src/dspimgs.S" OBJECT_DEPENDS ${HIFI4_BUILD_DIR}/zephyr.elf )   with   set(HIFI4_BIN_DEPS "${HIFI4_BUILD_DIR}/zephyr.elf" "${HIFI4_BUILD_DIR}/zephyr.reset.bin" "${HIFI4_BUILD_DIR}/zephyr.text.bin" "${HIFI4_BUILD_DIR}/zephyr.data.bin" ) set_source_files_properties( "${CMAKE_CURRENT_LIST_DIR}/src/dspimgs.S" PROPERTIES OBJECT_DEPENDS "${HIFI4_BIN_DEPS}" ) in dsp-load.cmake, and verified the change by `ninja -C build/amp_blinky -t query build/.../dspimgs.S.obj`   But unfortunately, the issue persists. Then I did another test as below: add `printk("TESTCCACHE");` to remote/src/main.c build call `strings build/.../dspimgs.S.obj | grep TESTCCACHE` call `strings build/remote/zephyr/zephyr.text.bin build/remote/zephyr/zephyr.data.bin | grep TESTCCACHE` Step 3 returned nothing while step 4 found the string. Then, I ran the test again with CCACHE disabled, and TESTCCACHE was found in both. It looks like dspimgs.S.obj did get its timestamp updated without loading the correct binaries when CCACHE is enabled. I would appreciate any thoughts on this. Best Regards, Yue Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Hello Shelly, Yes, CCACHE_RECACHE=1 works. BTW, I disable CCACHE by setting USE_CCACHE to 0 in CMakeLists. As for CCACHE_DISABLE, I have to explicitly set it in a west workspace terminal to make it work, which isn't quite ideal for using MCUXpresso for VS Code. The same thing goes for CCACHE_RECACHE, that I cannot use it by adding to CMakeLists. Best Regards, Yue Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS Dear @YueZ , Could you please try: CCACHE_RECACHE=1 ?   Unlike CCACHE_DISABLE, which completely bypasses ccache and performs a full rebuild without reading or writing any cache entries, CCACHE_RECACHE=1 forces regeneration of all outputs and updates the cache with the newly built results. If the issue disappears with CCACHE_RECACHE=1, it would indicate that the root cause is likely old cache contents. If the problem persists, it would suggest that the issue is related to ccache itself rather than a specific cached entry. Best Regards, Shelly  

MCXN547 SC Timer0 SDK driver Issue I am using MCXN547VKL MCU and SDK version 26.06.00.  Context: I am using SCT timer0  to generate two different PWM waveform using the COUNTER in split mode, CONFIG[UNIFY] = 0; i.e COUNT_L for one PWM generator and COUNT_H for another PWM generator. The issue: When I load the COUNTER_H with the driver API "SCTIMER_SetCOUNTValue(SCT0,kSCTIMER_Counter_H,0U);" , Bus Fault occurs.  I traced the issue to SDK driver code. The driver code uses 32 bit write to write both COUNT_H and COUNT_L instead of 16 bit write to COUNT_H alone. While the COUNT_H is being written COUNT_L was running and this caused bus fault. I modified the SDK driver code to use 16 bit write and the bus fault did not occur. I have attached the driver code and marked with colours, the code line which was causing the problem and the fix. If this is really the problem, the SDK driver can be updated. - Thanks /*! * @brief Set the value of counter. * * The function is to set the value of Count register, Writing to the COUNT_L, COUNT_H, or unified register * is only allowed when the corresponding counter is halted (HALT bits are set to 1 in the CTRL register). * * @param base SCTimer peripheral base address * @param whichCounter SCTimer counter to use. In 16-bit mode, we can select Counter_L and Counter_H, * In 32-bit mode, we can select Counter_U. * @param value the counter value update to the COUNT register. */ static inline void SCTIMER_SetCOUNTValue(SCT_Type *base, sctimer_counter_t whichCounter, uint32_t value) { SCTIMER_StopTimer(base, (uint32_t)whichCounter); switch (whichCounter) { case kSCTIMER_Counter_L: assert(value <= 0xFFFFU); assert(0U == (base->CONFIG & SCT_CONFIG_UNIFY_MASK)); /* Use Counter_L bits when user wants to setup the Low counter */ base->COUNT_ACCESS16BIT.COUNTL = (uint16_t)value; break; case kSCTIMER_Counter_H: assert(value <= 0xFFFFU); assert(0U == (base->CONFIG & SCT_CONFIG_UNIFY_MASK)); /* Use Counter_H bits when user wants to setup the High counter */ // base->COUNT = (uint32_t)base->COUNT_ACCESS16BIT.COUNTL | SCT_COUNT_CTR_H(value); base->COUNT_ACCESS16BIT.COUNTH = (uint16_t)value; //the fix break; case kSCTIMER_Counter_U: assert(1U == (base->CONFIG & SCT_CONFIG_UNIFY_MASK)); /* Use both Counter_L/Counter_H bits when counter is operating in 32-bit mode (unify counter). */ base->COUNT = value; break; default: /* Fix the MISRA C-2012 issue rule 16.4. */ break; } SCTIMER_StartTimer(base, (uint32_t)whichCounter); } Clock|Timers Re: MCXN547 SC Timer0 SDK driver Issue Hi @JawaharA  Thank you for your feedback. Your analysis of the cause of the Bus Fault is correct: updating COUNT_H uses a 32-bit write to the COUNT register, but the current function halts only the H counter. If the L counter is still running, this write access triggers an SCT bus error. However, changing the access to a 16-bit write to COUNTH is not compliant with the SCT hardware access requirements, because COUNT_H must be written as a word together with COUNT_L . The correct software solution is to halt both the L and H counters before performing the 32-bit write to COUNT , and then restore their previous running states afterward. We recommend reviewing and updating the SDK accordingly rather than using a separate 16-bit write to COUNT_H . BR Harry Re: MCXN547 SC Timer0 SDK driver Issue Hi Harry, Thanks for your quick response. As per the manual page you referenced in your response, if CONFIG[UNIFY] = 0, then both COUNT_L and COUNT_H registers can be read or written individually while the respective counters are not running. The SDK does use 16 bit write for COUNT_L register. COUNT_H register should be written using 32bit write irrespective of CONFIG[UNIFY] - is this an undocumented condition? Thanks - Jawahar

基于i.MXRT1052的pxp屏幕旋转问题 我正在使用rt1052的pxp将横屏旋转成竖屏显示，但是在不断刷新的情况下，整体显示会向下偏移，这是为什么？   static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { lv_area_t dest_area = { .x1 = 0, .x2 = 480 - 1, .y1 = 0, .y2 = 800 - 1, }; lv_gpu_nxp_pxp_blit(((lv_color_t *)s_inactiveFrameBuffer), area, 800, color_p, area,480, LV_OPA_COVER, LV_DISP_ROT_270); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)s_inactiveFrameBuffer); s_framePending = true;if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } }   i.MXRT 105x 回复： 基于i.MXRT1052的pxp屏幕旋转问题 我发现当我使用pxp绘制的时候就会出现偏移问题，是因为guiguider生成的默认初始化#define LV_USE_GPU_NXP_PXP_AUTO_INIT 1不能直接使用吗？ void lv_disp_drv_init(lv_disp_drv_t * driver) { lv_memset_00(driver, sizeof(lv_disp_drv_t)); driver->hor_res = 320; driver->ver_res = 240; driver->physical_hor_res = -1; driver->physical_ver_res = -1; driver->offset_x = 0; driver->offset_y = 0; driver->antialiasing = LV_COLOR_DEPTH > 8 ? 1 : 0; driver->screen_transp = 0; driver->dpi = LV_DPI_DEF; driver->color_chroma_key = LV_COLOR_CHROMA_KEY; #if LV_USE_GPU_NXP_PXP // driver->draw_ctx_init = lv_draw_pxp_ctx_init; // driver->draw_ctx_deinit = lv_draw_pxp_ctx_deinit; // driver->draw_ctx_size = sizeof(lv_draw_pxp_ctx_t); driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #else driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #endif } 回复： 基于i.MXRT1052的pxp屏幕旋转问题 嗨@dsd ， LV_USE_GPU_NXP_PXP_AUTO_INIT 允许 LVGL 利用 PXP 进行内部控件渲染，当应用程序还并行使用此 PXP 进行全屏旋转时，这肯定会导致问题。然而，这可能并非问题的根源。 从初始代码来看，你似乎没有使用 dest_area，或者说你将 area 同时用作 PXP blit 的源和目标，这意味着只有部分脏区域可能会被放置在不同的绝对位置，而不是预期的位置。 回复： 基于i.MXRT1052的pxp屏幕旋转问题 我用guiguider生成的代码去测试，即便我不使用pxp旋转 static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } } 仅仅去修改宏/*Use NXP's PXP GPU iMX RTxxx platforms*/ #define LV_USE_GPU_NXP_PXP 1 #if LV_USE_GPU_NXP_PXP /*1: Add default bare metal and FreeRTOS interrupt handling routines for PXP (lv_gpu_nxp_pxp_osa.c) * and call lv_gpu_nxp_pxp_init() automatically during lv_init(). Note that symbol SDK_OS_FREE_RTOS * has to be defined in order to use FreeRTOS OSA, otherwise bare-metal implementation is selected. *0: lv_gpu_nxp_pxp_init() has to be called manually before lv_init() */ #define LV_USE_GPU_NXP_PXP_AUTO_INIT 1 #endif /* LV_USE_GPU_NXP_PXP */ 也会有同样的问题，并且偏移的方向与旋转后的一致 回复： 基于i.MXRT1052的pxp屏幕旋转问题 更奇怪的是在同一个工程下会有两种不同的结果，我认为配置应该是相同的 没有发生显示偏移 发生显示偏移    

i.MXRT1052に基づくPXP画面回転の問題 rt1052PXPを使って横向き表示を縦向き表示に回転させているのですが、ページを更新すると全体の表示が下方向にずれてしまいます。なぜこのようなことが起こるのでしょうか？   static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) ヤージュ lv_area_t dest_area = ヤージュ .x1= 0、 .x2= 480 - 1、 .y1= 0、 .y2= 800 - 1、 }; lv_gpu_nxp_pxp_blit(((lv_color_t *)s_inactiveFrameBuffer), area, 800, color_p, area,480, LV_OPA_COVER, LV_DISP_ROT_270); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)s_inactiveFrameBuffer); s_framePending = true;if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) ヤージュ /* 重要！！！ * グラフィックライブラリに、フラッシュの準備ができたことを通知します */ lv_disp_flush_ready(disp_drv); } それ以外 ヤージュ PRINTF("ディスプレイのフラッシュに失敗しました\r\n"); assert(0); } }   i.MXRT 105x 回复： 基于i.MXRT1052的pxp屏幕旋转问题 こんにちは、 @dsd さん。 このLV_USE_GPU_NXP_PXP_AUTO_INITにより、LVGLはPXPユーザーを内部ウィジェットレンダリングに活用できますが、アプリケーションがこのPXPを並列で全画面回転に使う場合、問題を引き起こす可能性があります。しかし、それが問題の原因である可能性は低い。 初期のコードを見ると、dest_areaを使っていないか、PXPブリットのソースと宛先の両方にエリアを使っているように見えます。つまり、部分的な汚れた領域だけが意図された絶対位置ではなく、異なる絶対位置に配置されている可能性があります。 回复： 基于i.MXRT1052的pxp屏幕旋转问题 PXPで描画する際にオフセットの問題が発生することに気づきました。これは、guiguiderによって生成されるデフォルトの初期化設定`#define LV_USE_GPU_NXP_PXP_AUTO_INIT 1`が直接使用できないためでしょうか？ void lv_disp_drv_init(lv_disp_drv_t * driver) ヤージュ lv_memset_00(driver, sizeof(lv_disp_drv_t)); driver->hor_res = 320; driver->ver_res = 240; driver->physical_hor_res = -1; driver->physical_ver_res = -1; driver->offset_x = 0; driver->offset_y = 0; driver->antialiasing = LV_COLOR_DEPTH > 8 ? 1 : 0; driver->screen_transp = 0; driver->dpi = LV_DPI_DEF; driver->color_chroma_key = LV_COLOR_CHROMA_KEY; #if LV_USE_GPU_NXP_PXP // driver->draw_ctx_init = lv_draw_pxp_ctx_init; // driver->draw_ctx_deinit = lv_draw_pxp_ctx_deinit; // driver->draw_ctx_size = sizeof(lv_draw_pxp_ctx_t); driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); ＃それ以外 driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #endif } 回复： 基于i.MXRT1052的pxp屏幕旋转问题 pxp回転を使わなくても、guiguiderで生成されたコードを使ってテストしてみました。 static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) ヤージュ DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) ヤージュ /* 重要！！！ * グラフィックライブラリに、フラッシュの準備ができたことを通知します */ lv_disp_flush_ready(disp_drv); } それ以外 ヤージュ PRINTF("ディスプレイのフラッシュに失敗しました\r\n"); assert(0); } } マクロ /*NXPのPXP GPU iMX RTxxxプラットフォームを使用する*/ を修正するだけです。 #define LV_USE_GPU_NXP_PXP 1 #if LV_USE_GPU_NXP_PXP /*1: PXP 用のデフォルトのベアメタルおよび FreeRTOS 割り込み処理ルーチンを追加します (lv_gpu_nxp_pxp_osa.c) * lv_init() の実行中に lv_gpu_nxp_pxp_init() を自動的に呼び出します。シンボルSDK_OS_FREE_RTOSに注意してください。 * FreeRTOS OSAを使用するには、これを定義する必要があります。定義しない場合は、ベアメタル実装が選択されます。 *0: lv_gpu_nxp_pxp_init() は lv_init() の前に手動で呼び出す必要があります / #define LV_USE_GPU_NXP_PXP_AUTO_INIT 1 #endif /* LV_USE_GPU_NXP_PXP */ 同じ問題が発生し、オフセットの方向は回転後と同じになります。 回复： 基于i.MXRT1052的pxp屏幕旋转问题 さらに奇妙なことに、設定は同じはずなのに、同じプロジェクト内で2つの異なる結果が出てしまったのです。 表示オフセットは発生しませんでした 表示オフセットが発生します    

如何选择用于国际流媒体的 IPTV 提供商 找到一家可靠的 IPTV 提供商可能很困难，尤其是在您需要国际频道、电影、体育赛事和良好的流媒体质量时。 根据我的经验，在选择服务之前，我通常会考虑以下几个重要方面： 流畅播放，缓冲极少 画面质量良好，包括高清和 4K（如有提供）。 丰富的国际内容选择 定期更新的视频点播内容 兼容智能电视、安卓设备、Fire TV 和其他主流平台 响应迅速的客户支持 在正式订阅之前，您可以选择试用期。 我测试过各种不同的服务，目前我正在使用 nexusiptv.live （链接在此） 。我喜欢它的主要原因是设置简单，而且提供丰富的国际节目选择。 当然，IPTV 的性能可能取决于您的互联网连接、设备、位置和正在播放的内容，因此我建议您在选择长期订阅之前先自行测试该服务。 在选择IPTV服务提供商时，您最看重哪些功能？

S32K36x引导加载程序实现 尊敬的恩智浦技术支持团队： 我目前正在评估贵公司的微控制器，以用于某个应用。我特别想使用S32K364微控制器型号。但是，我不太确定如何为其实现引导加载程序功能。 如果我们想使用 CAN-FD 为我们的 MCU 刷写固件，我们是否应该直接采用四年前为原始 S32K31x/K32x/K34x MCU 编写的现有“统一引导加载程序演示”？或者是否有专门为 S32K36x 系列编写的更官方的引导加载程序示例项目可供我们直接使用？ 提前感谢！ Re: S32K36x Bootloader Implementation 嗨@SewerynP 请看我整理的S32K3引导加载程序示例： https://community.nxp.com/t5/S32K/S32K385-Bootloader/m-p/2367874/highlight/true#M58710 NXP 并未针对每个 S32K3 衍生产品提供可用于生产的引导加载程序代码。提供的引导加载程序演示是参考软件，旨在作为开发您自己的解决方案的起点，并且可以适配 S32K364。对于可直接投入生产使用的解决方案，您可以考虑使用第三方产品，例如 Vector Flash Bootloader。 此致， Lukas

How I Choose an IPTV Provider for International Streaming Finding a reliable IPTV provider can be difficult, especially when you need international channels, movies, sports, and good streaming quality. From my experience, I usually look at a few important points before choosing a service: Stable streaming with minimal buffering Good picture quality, including HD and 4K where available A wide selection of international content Regularly updated VOD content Compatibility with Smart TVs, Android devices, Fire TV, and other popular platforms Responsive customer support A trial option before making a longer subscription I have tested different services over time, and one of the services I currently use is nexusiptv.live (here) . I like it mainly because the service is simple to set up and offers a broad international selection. Of course, IPTV performance can depend on your internet connection, device, location, and the content being streamed, so I recommend testing a service yourself before choosing a long-term subscription. What features matter most to you when choosing an IPTV provider?

i.MX RT1176 – FlexIO2パラレル受信：達成可能な最大シフトクロックは？わずか約48 MSPSしか到達しなかった iMXR1176 SDK 25.09.00 Manifest 3.15.0 ゴール i.MX RT1176に搭載されているLTC2164 16ビットADCからデータを取得しています。データパスは次のとおりです。 LTC2164（フルレートCMOS出力）→FlexIO2（パラレルRX）→eDMA→外部SDRAM ハードウェアのセットアップ LTC2164フルレートCMOS出力モードで構成され、外部100MHz発振器(100MSPS、16ビット並列)でクロックされます。 ADCデータ出力D0–D15はGPIO_AD_00...GPIO_AD_15。 ADC CLKOUT+はGPIO_AD_30に接続され、FlexIOタイマークロック(外部ピンクロックソース)として使用されました。 ソフトウェアのセットアップ FlexIO2は並列レシーバとして構成され、データはシフター7にラッチされます。シフター7から>0は、DMA要求が主張される前に32バイトバッファリングされるようにチェーンされています。 kDmaRequestMuxFlexIO2Request0Request1によってトリガーされたeDMAは、ピンポン（スキャッター/ギャザー）モードで2つのTCDを使用します。各メジャーループ完了時、つまり16384サンプルごとに割り込みが発生します。 FlexIO2の機能クロック：120MHz。 バスクロック（eDMA/SEMC側）：240MHz。 問題 100 MSPS の場合、16384 サンプルの処理には163.84 µsかかるはずです。連続する 2 つの DMA 割り込み間の時間を測定 (GPIO トグル + オシロスコープ) すると、常に338 µsという結果が得られ、これは約 2.06 倍です。 これは約48 MSPSの実効持続レートに相当し、ボトルネックはADCやSDRAMではなくFlexIO側にあることを示唆している。 質問 RT1176の並列受信モードにおけるFlexIOの最大シフトクロック周波数に関する公式な文書はありますか？RMやデータシートにはそのような数値は見つかりませんでした。 タイマークロックのソースが外部ピンの場合、FlexIOの機能クロックと外部シフトクロックの比率はどのようになりますか？私のFlexIOクロック（120MHz）は、入力される100MHzクロックのわずか1.2倍ですが、それで十分でしょうか？それとも、入力同期ロジックには2倍または4倍が必要ですか？ ほぼ正確な×2の比率を考えると、これはFlexIOタイマーがクロックの両端で減少している(TIMMPの慣例)によるもので、タイマー比較値が実質的にスループットを半分に減らしているのではないでしょうか? この部分でのFlexIO + eDMAの最大現実的な持続スループットについてのガイダンスがあれば、非常に助かります。なぜなら、別のペリフェラルに移行するか外部FIFOに切り替えるかを判断するからです。 よろしくお願いいたします。 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、ご返信ありがとうございます。確かに望ましい性能は達成できましたが、Flexioペリフェラルの推奨クロック周波数を最大を超えたことでしかできませんでした。具体的には、120MHzでクロックを設定するのではなく、100MSpsの取得には200MHz以上のクロック速度が必要ですが、120MHz構成ではクロックエッジがミスされます。問題は、200 MHzで動作しているにもかかわらず(リファレンスマニュアルには最大120 MHzと記載されていますが)、温度条件や生産バッチごとに安定して動作する保証がないことです。 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、@azed38 さん。 外部ピンをクロックソースとして使用した場合、わずかな同期レイテンシが発生することに注意してください。RMのセクション67.3.3.2によると、このレイテンシは0.5から1.5 FlexIOクロックサイクルの範囲です。 Habib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.png FlexIOとDMAで達成可能な最大スループットに関しては、FlexIOとDMAの性能テストは存在しません。しかし AN12686 、FlexIOとDMAを用いた並列通信実装を示しているため、あなたのユースケースに関連する指針となるかもしれません。 BR ハビブ Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、@azed38 さん。 このトピックに関してはすでに別のチャネルでサポートを受けているのに気づきましたので、すべてのコミュニケーションを集中管理するために引き続きサポートを続けます。FlexIOを最大周波数仕様を超えて運用すると、最終アプリケーションに影響を与える予期せぬ挙動を引き起こす可能性があることを付け加えたいと思います。RMの表15-4「クロックルート」に記載されている情報に基づき、最大周波数を120MHzにすることを推奨します。 BR ハビブ Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、 この問題は、セクション「67.3.3.2」で説明されているピン同期の遅延が原因である可能性が高い。「ピン同期」というリファレンスマニュアルの内容です。 前述の構成を考慮すると、問題の根本原因は、このモジュールのピン同期遅延に起因する、入力データ周波数とFlexIOの動作クロック周波数の比率にある。 例えば、ピン同期遅延が存在するため、SPI MasterのようなFlexIOエミュレート**ペリフェラル**は、FlexIO動作クロック周波数の最大ボーレートでしか動作できません。RMの67.4.3節に記載されているように:「同期遅延のため、シリアル入力データのセットアップ時間は1.5 FlexIOクロックサイクルとなり、最大ボーレートはFlexIOクロック周波数の4で割られます。」 この場合、スループットは減少することが予想されており、ピン同期遅延はFlexIOモジュール固有の動作であるため、回避策はありません。 このため、FlexIOモジュールの適切な動作を保証するための最大動作周波数が120MHzであることと相まって、RT1170では期待される100MSPSは実現できません。 BR ハビブ Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached > ほぼ正確な ×2 比率を踏まえると、これはFlexIOタイマーがクロックの両端で減少していること(TIMCMPの慣例)によるもので、タイマー比較値が実質的にスループットを半分に減らしているのではないでしょうか? 念のため申し上げておきますが、FlexIOタイマーは、ピンまたはトリガーからクロック供給されている場合、デュアルエッジ検出に対応しています。つまり、外部信号が上昇エッジと下降エッジを1つだけ作った場合、タイマーは比較値に2回カウントされます。 また、これまでのFlexIOの一般的な経験から言うと、外部信号はFlexIOのクロックレートの半分までしか扱えないと思います。他にどうやって二重エッジを感知できるのでしょうか?エッジを検出するためには、クロック周期ごとに外部ピンを2回サンプリングする必要がある。

国際ストリーミングのためのIPTVプロバイダーの選び方 信頼できるIPTVプロバイダを見つけるのは難しいことがあります。特に国際チャネル、映画、スポーツ、そして良好なストリーミング品質が必要な場合はなおさらです。 私の経験から言うと、サービスを選ぶ前に、私は通常いくつかの重要な点を確認します。 バッファリングを最小限に抑えた安定したストリーミング HDや4Kも含めて良好な品質を提供 幅広い国際コンテンツ 定期的に更新されるVODコンテンツ スマートテレビ、Androidデバイス、Fire TV、その他の人気プラットフォームとの互換性 迅速なカスタマーサポート 長期契約前に試用できるオプション 私はこれまで様々なサービスを試してきましたが、現在利用しているサービスの1つがnexusiptv.live （こちら）です。このサービスが気に入っている主な理由は、設定が簡単で、幅広い国際的なコンテンツを提供しているからです。 もちろん、IPTVのパフォーマンスはインターネット接続、デバイス、場所、ストリーミングコンテンツによって異なるため、長期契約を選ぶ前にご自身でサービスを試すことをおすすめします。 IPTVプロバイダーを選ぶ際に最も重要な機能は何ですか?

MCXN547 SC Timer0 SDK 驱动程序问题 我使用的是MCXN547VKL单片机和SDK版本26.06.00。 背景：我使用 SCT timer0 通过分割模式下的 COUNTER 生成两个不同的 PWM 波形，CONFIG[UNIFY] = 0；即 COUNT_L 用于一个 PWM 生成器，COUNT_H 用于另一个 PWM 生成器。 问题：当我使用驱动程序 API " SCTIMER_SetCOUNTValue(SCT0,kSCTIMER_Counter_H,0U);" 加载 COUNTER_H 时，发生总线故障。 我发现问题出在 SDK 驱动程序代码上。驱动程序代码使用 32 位写入同时写入 COUNT_H 和 COUNT_L，而不是仅使用 16 位写入 COUNT_H。在写入 COUNT_H 时，COUNT_L 正在运行，这导致了总线故障。我修改了 SDK 驱动程序代码，使其使用 16 位写入，总线故障就没有发生。我已附上驱动程序代码，并用颜色标记出导致问题的代码行和解决方法。如果这确实是问题所在，可以更新 SDK 驱动程序。- 谢谢 /*! * @brief 设置计数器的值。 * 该功能用于设置计数寄存器的值，写入 COUNT_L、COUNT_H 或统一寄存器。 只有当相应的计数器停止时（CTRL 寄存器中的 HALT 位设置为 1），才允许使用 *。 * * @Param base SCTimer 外设基地址 * @Param whichCounter 要使用的 SCTimer 计数器。在 16 位模式下，我们可以选择 Counter_L 和 Counter_H。 * 在 32 位模式下，我们可以选择 Counter_U。 * @Param value 计数器值更新到 COUNT 寄存器。 */ static inline void SCTIMER_SetCOUNTValue ( SCT_Type *base, sctimer_counter_t whichCounter, uint32_t value) { SCTIMER_StopTimer(base, ( uint32_t )whichCounter); 切换（whichCounter） { case kSCTIMER_Counter_L : assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当用户想要设置低计数器时，请使用 Counter_L 位 */ base-> COUNT_ACCESS16BIT.COUNTL = ( uint16_t ) value; 休息; case kSCTIMER_Counter_H : assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当用户想要设置高位计数器时，请使用 Counter_H 位 */ // base->COUNT = (uint32_t)base->COUNT_ACCESS16BIT.COUNTL | SCT_COUNT_CTR_H(value); base-> COUNT_ACCESS16BIT.COUNTH = ( uint16_t ) value; //修复 休息; case kSCTIMER_Counter_U : assert(1U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当计数器在 32 位模式下运行时，同时使用 Counter_L/Counter_H 位（统一计数器）。*/ 基本->计数= 值； 休息; 默认： /* 修复 MISRA C-2012 问题规则 16.4。*/ 休息; } SCTIMER_StartTimer(base, ( uint32_t )whichCounter); } 时钟|计时器 Re: MCXN547 SC Timer0 SDK driver Issue 你好@JawaharA 感谢您的反馈。您对总线故障原因的分析是正确的：更新 COUNT_H 需要对 COUNT 寄存器进行 32 位写入，但当前函数只会停止 H 计数器。如果 L 计数器仍在运行，则此写入访问会触发 SCT 总线错误。 然而，将对 COUNTH 的访问更改为 16 位写入不符合 SCT 硬件访问要求，因为 COUNT_H 必须与 COUNT_L 一起作为一个字写入。正确的软件解决方案是在对 COUNT 执行 32 位写入之前停止 L 计数器和 H 计数器，然后在之后恢复它们之前的运行状态。我们建议相应地审查和更新 SDK，而不是使用单独的 16 位写入 COUNT_H。 BR 哈里 Re: MCXN547 SC Timer0 SDK driver Issue 嗨，哈里， 感谢您的快速回复。 根据您在回复中引用的手册页，如果 CONFIG[UNIFY] = 0，则在相应的计数器未运行时，可以单独读取或写入 COUNT_L 和 COUNT_H 寄存器。SDK 对 COUNT_L 寄存器使用 16 位写入。无论 CONFIG[UNIFY] 设置如何，COUNT_H 寄存器都应该使用 32 位写入进行写入 - 这是未记录的条件吗？ 谢谢 - 贾瓦哈尔

KW47-EVK板的蓝牙通道发声示例在哪里？ KW47-EVK 板及其子卡 (KW47-001-M10)的蓝牙通道发声示例在哪里？ 我在https://github.com/nxp-mcuxpresso/ 的仓库中查找过，但找不到任何针对 KW47-EVK 开发板的具体示例。我还找到了FRDM-MCXW72的通道探测示例：FRDM-MCXW72：动手实践 8：FRDM 到电话的通道探测。 我还使用了 NXP AI 的帮助功能，但它给出的链接并不存在。 我已经安装了基于 Eclipse 的 MCUXpresso，以及适用于 KW47-EVK 板和子卡 (KW47-001-M10) 的 SDK。 提前致谢！——保罗 Re: Where are Bluetooth Channel Sounding Examples for the KW47-EVK board 你好， 希望你一切都好。感谢您的联系。要访问 KW47-EVK 的通道探测示例，建议使用 MCUXpresso for VS Code 扩展以及 MCUXpresso SDK GitHub 存储库，而不是手动浏览存储库。 步骤如下： 安装适用于 VS Code 的 MCUXpresso 扩展。您可以从 VS Code 应用商店或 NXP 页面下载并安装： https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-for-visual-studio-code :MCUXPRESSO-VSC 从存储库导入 SDK 在 VS Code 中，打开 MCUXpresso 快速入门面板，点击“从存储库导入示例”，然后选择 KW47-EVK 板。该扩展程序将直接从 GitHub 存储库拉取 SDK。 使用 SDK 版本 26.06.00 (LTS) 我们建议使用 SDK 版本 26.06.00，这是当前的 LTS 版本，包含 KW47 的最新 BLE 协议栈更新，包括通道探测支持。   具体来说，我建议您查看以下文档：运行低功耗蓝牙定位场景 — MCUXpresso SDK 文档 希望这能帮到你！ 顺祝商祺！ 里卡多 Re: Where are Bluetooth Channel Sounding Examples for the KW47-EVK board 谢谢你，里卡多！这样就成功了，我可以使用 Visual Studio Code 扩展导入 mcxw72evk_loc_reader_bm。

S32K36x Bootloader Implementation Dear NXP Support Team, I am currently in the process of evaluating your microcontrollers for an application. I would specifically like to use the S32K364 microcontroller model. However, I am uncertain about how to implement a bootloader function for it. Are we supposed to simply adapt the existing "unified bootloader demo" from four years ago made for the original S32K31x/K32x/K34x MCUs if we want to flash our MCU using CAN-FD or is there a more official bootloader example project written specifically for the S32K36x series we could use directly?  Thanks in advance! Re: S32K36x Bootloader Implementation Hi @SewerynP  Please see my summary of the available S32K3 bootloader examples here: https://community.nxp.com/t5/S32K/S32K385-Bootloader/m-p/2367874/highlight/true#M58710 NXP does not provide production-ready bootloader code specifically for every S32K3 derivative. The available bootloader demos are reference software intended as a starting point for developing your own solution and can be adapted to S32K364. For a production-ready solution, you can consider third-party products such as Vector Flash Bootloader. Regards, Lukas