内部DCDC DCDC_ANA_SENSEおよびVOUT_DCDC_1V8/DCDC_ANAに関する問題 親愛なるNXPサポートチームの皆様、 MX RT1172を搭載したカスタムボードで作業中に、 DCDC_ANA_SENSEの波形をキャプチャしたところ、最初に1.9Vまで上昇し、その後1.51Vで安定することがわかりました。 なぜこうなるのか教えてもらえますか?参考のために波形と回路図を添付しました。 あなたからの返信を楽しみにしています。 よろしくお願いいたします。 深い Re: Issue with internal DCDC DCDC_ANA_SENSE and VOUT_DCDC_1V8/DCDC_ANA こんにちは、 @deeporbit さん。 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 提供された波形に基づくと、VOUT_DCDC_1V8 (DCDC_ANA_SENSE) の定常状態電圧は約 1.51 V であり、これは期待される動作と一致しません。MIMXRT1170-EVKBでテストしたところ、DCDC_1V8_OUTレールは約1.8Vに安定化することが分かりました。 以下の点を確認することをお勧めします。 1: DCDC_ANA_SENSEが正しくVOUT_DCDC_1V8に接続されているか確認し、0 Ωフィードバック抵抗R166が正しく埋め込まれてはんだ付けされているか確認してください。 2: 外部の1.8Vレギュレーター、ペリフェラル、レベルシフター、その他の電源領域がVDD_1V8/VOUT_DCDC_1V8レールに接続されていて、レールを引き寄せたり逆動させたりしている可能性があるか確認してください。 3: DCDC_ANA / VOUT_DCDC_1V8に接続された総負荷を確認してください。DCDC_ANAにかかる負荷は、規定の出力能力である150mAを超えてはならない。 4: 可能であれば、下流の 1.8 V 負荷を分離し、VOUT_DCDC_1V8 を再度測定します。レールが絶縁後に約1.8Vに戻る場合、問題は過剰な負荷か1.8Vレールに接続された外部回路に関連している可能性が高いです。 よろしくお願いします、 5月

68LC302 和串行引导功能 大家好。希望到了 2026 年，仍然有人对 LC302 有一些了解。 我一直在做一个涉及 LC302 的小项目，我对使用串行引导功能很感兴趣。我就是弄不好，不知道是不是需要特别注意什么才能让它正常工作。 我已经尝试了我能想到的一切办法，目前正在考虑更换我现有的 LC302，以防它出现故障，但在采取这一措施之前，我想先问问这个问题。仅供参考，包装上的标记是（带有摩托罗拉标志）： MC68LC302PU25CT 2J29A QQDJ0316 我用5V电源供电。 基本上，我无法让它回显我发送给它的任何内容。我偶然看到一篇帖子，似乎描述了同样的问题，但我遇到的问题似乎并不相同： https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/We-have-been-using-the-68LC302-for-decades-without-major/mp/612300 我用示波器/逻辑分析仪尝试过/观察到以下现象： 我尝试过使用PLL模式和不使用PLL模式。在 PLL 模式下，我使用了一个 4MHz 的振荡器（4.192MHz 的振荡器很难找到）。在这种模式下，我使用了 9174 波特率（4MHz*4，/109，/16）。如果没有锁相环，我使用了一个 20MHz 的振荡器，波特率为 11467。我使用信号发生器输入 4.192MHz 信号，并使用了数据手册中给出的波特率，但仍然没有成功。 如果我将 PA7 拉高以禁用引导模式，我可以观察到 AS 引脚上有一些短暂的活动，这大概是因为 CPU 尝试从外部存储器读取其复位向量。如果我将 PA7 拉低以启用引导模式，我就不再观察到这种活动了，大概是因为 CPU 处于 RESET 状态。 我很快就发现 PA7 上似乎有一个电流源，并且输出大约 3-4mA 的电流（用万用表电流模式测量），超过了我的外部下拉电阻，导致逻辑高电平。我觉得这电流非常大，有人能解释一下这是为什么吗？这似乎与上述导致 PA7 意外拉高的帖子略有相关。或许是我的零件有问题？ Reset 和 HALT 同时钳位（过去几年我在业余项目中积累了丰富的 68k 经验）。 🙂 我已经反复检查了所有接线，包括 TX/RX 信号的极性，甚至为了以防万一，还将 SCC1 的流控制输入拉到了反相状态。我用示波器测量过，我的 USB 转串口适配器确实能产生我请求的波特率，而且将 TX 连接到 RX 可以让 PuTTY 回显我发送的字符，所以我相当确信那里没有什么异常情况发生。 我还没有连接任何内存总线，因为目前我只是想看看能否通过串口加载一些代码并让 LED 闪烁，但是 BUSW 引脚已经绑定为 16 位总线操作，这重要吗？ 在开始拆焊之前，大家还有什么其他建议吗？ 谢谢您！ Re: 68LC302 and serial bootstrap feature 你好，谢谢你的留言。 我已经确认我使用的是与 SCC1 相关的引脚。 我的电路是安装在带绕线的万用板上的，所以除了我绕的线之外，其他任何引脚都不会受到其他因素的影响。我用万用表验证过，复位和停止信号同时钳位，并且电压达到 0V，所有引脚都达到所需的电压电平，没有浮空引脚。 另外，正如我在帖子中提到的，我也尝试过使用信号发生器提供的 4.192MHz 信号和数据手册中规定的波特率，但这并没有帮助。 抱歉，我之前说我把 CD1 连接到了它的否定状态，我只是把术语搞混了，它实际上是接地的（钳位），为了保险起见，CTS1 也接地了。 我尝试发送 576 字节的数据进行测试，看看是不是因为某种原因它没有回显这些数据，但仍然能够正确接收它们。 谢谢！ Re: 68LC302 and serial bootstrap feature 你好， 我首先要检查的是 CD1 。对于 LC302 串行引导回显路径，手册中说 SCC 硬件会将接收到的字符回显到 TXD1 上，但 CD1 必须置位；在 SCC1 上，外部 CD1 引脚必须拉低。如果你将 SCC1 调制解调器控制输入拉到“否定”状态，这可能就是你看不到回声的原因。 LC302启动说明中的其他要点： 通过在硬复位期间采样 PA7 = 0 来启用串行引导，其中硬复位意味着 RESET 和 HALT 同时钳位。 PA7 不能悬空；RESET时必须故意将其拉高或拉低。 SCC1 接收到的前 576 个字节存储在双端口 RAM 中，并且接收到的每个字符都会从 TXD1 回显出来；设备只有在接收到所有 576 个字节后才会退出启动模式。 对于内部时钟引导，记录的标称时钟假设为 4.192 MHz 或 32.768 kHz，SCC 编程为大约 9600 波特。 在异步 UART 模式下，使用外部时钟选项时，比特率为 TCLK1/RCLK1 时钟速率的 1/16。 所以在更换零件之前，我会先尝试这种最简化的配置： 同时按住 RESET 和 HALT 键。 将 PA7/启动 低电平拉下，并用足够强的下拉电阻来克服您的板上的任何阻力。 使用 PA5 选择所需的时钟模式： PA5 = 0 ：内部启动时钟模式。 PA5 = 1 ：外部时钟位于 TCLK1/RCLK1 倍波特率。 将 PA12/MODCLK0 与时钟源保持一致；手动在硬复位期间对其进行采样，以区分标称 EXTAL 频率。 CD1 低。 保持 RXD1 、 TXD1 、 RCLK1 和 TCLK1 接线与 SCC1 一致，而不是与 SCC2 一致。LC302 描述中的 SCC1 启动功能。 发送完整的 576 字节测试流，而不是只发送一个字符，尽管一旦接收正常工作，回显应该逐个字符地出现。 来自 PA7 的 3–4 mA 电流很可疑。根据数据手册，输入漏电流值最大仅为 20 µA，远低于毫安级。由于 PA7 也是一个双向多功能引脚，如果其他东西正在驱动它，或者该器件已经离开复位采样状态，则可能会发生争用，但在复位作为启动期间，读取低电平不应该需要灌入几毫安的电流。我会检查 PA7 上是否存在板级上拉/驱动器/焊接桥，验证封装引脚方向，并在 RESET 和 HALT 同时主动钳位时测量电流。 还有一点需要注意：你尝试的 4 MHz 内部时钟并不等同于 4.192 MHz。如果调整另一侧，对于某些 UART 来说可能足够接近，但文档中记录的内部引导模式假定标称 LC302 时钟值，因此为了消除变量，我会使用 4.192 MHz 和文档中记录的波特率，或者使用外部时钟模式并提供干净的 TCLK1/RCLK1 = 16 × baud 。   此致问候

68LC302 and serial bootstrap feature Hi all. Hopefully there is still someone around in 2026 that has some knowledge tucked away in the back of their brains regarding the LC302. I've been working on a little project involving an LC302 and I am interested in using the serial bootstrap feature. I just cant seem to get it to work and I wondered if there is anything particularly special that needs to be done to make it work. I've tried everything I can think of, and I'm currently looking at replacing the LC302 that I currently have in case it is somehow faulty, but thought I'd ask the question before I go to that effort. FWIW the markings on the package are (with Motorola logo): MC68LC302PU25CT 2J29A QQDJ0316 I am powering it with 5V. Basically I cannot get it to echo back anything that I am sending to it. I came across the following post which seemed to describe the same problem, but I dont seem to have the same issue: https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/We-have-been-using-the-68LC302-for-decades-without-major/m-p/612300 Things I've tried/I can observe with my scope/logic analyser: I've tried using both PLL mode and not. In PLL mode I used a 4MHz oscillator (4.192 is hard to come across). In this mode I used 9174 baud (4MHz*4, /109, /16). Without the PLL I used a 20MHz oscillator with baud 11467. I've used my signal generator to feed 4.192MHz in and used the baud rate quoted in the datasheet also to no avail. If I pull PA7 high to disable bootstrap mode, I can observe some brief activity on the AS pin, presumably as the CPU tries to read its reset vector from external memory. If I pull PA7 low to enable bootstrap mode I don't observe this activity any more, presumably as the CPU is held in reset. I did early on discover that PA7 seems to have some kind of current source on it, and was sourcing approx 3-4mA of current (measured with my multimeter in current mode), overpowering my external pull down resistor and resulting in a logic high. This feels like an extremely high amount of current to me, and does anyone have an explanation for that? It seems vaguely related to the above thread causing PA7 to be pulled too high unexpectedly. Maybe my part is faulty? Reset and HALT are being asserted simultaneously (I've got lots of 68k experience from hobby projects over the past several years). 🙂 I've double and triple checked all of my wiring including the polarity of the TX/RX signals, and even pulled the flow control inputs for SCC1 to their negated state just in case. I've measured with my oscilloscope that my USB-serial adapter does indeed generate the baud rate that I am requesting, and looping TX to RX allows me to echo back the characters that I send in putty, so I am fairly confident there is nothing odd going on there. I havent wired up any of the memory busses, because for now I am just interested to see if I can load some code in via serial and make an LED blink, but the BUSW pin has been strapped for 16-bit bus operation, if that matters? Does anyone have any other suggestions before I go desoldering stuff? Thanks! Re: 68LC302 and serial bootstrap feature Hi, thanks for the message. I have made sure that I am using SCC1 related pins. My setup is on a perfboard with wire wrap, so there are no other influences on any of the pins other than what I have wire wrapped. I've verified with a multimeter that reset and halt are asserted together and that they reach 0V, and that all strap pins are seeing the required voltage levels with no floating pins. Also, as mentioned in my post, I have also tried using 4.192MHz supplied by my signal generator and the baud rate quoted in the datasheet, but this didn't help. Apologies when I said I had tied CD1 to its negated state, I've just mixed up my terminology and it is indeed tied to ground (asserted), along with CTS1 for good measure. I'll try sending 576 bytes as a test in case it is just not echoing them back for some reason, but is still receiving them correctly. Thanks Re: 68LC302 and serial bootstrap feature Hello, The first thing I would check is CD1 . For the LC302 serial bootstrap echo path, the manual says the SCC hardware echoes received characters back on TXD1 , but CD1 must be asserted; on SCC1 the external CD1 pin must be tied low . If you pulled the SCC1 modem-control inputs to their “negated” state, that may be exactly why you see no echo. Other important points from the LC302 boot description: Serial bootstrap is enabled by sampling PA7 = 0 during hard reset , where hard reset means both RESET and HALT asserted . PA7 must not float; it must be deliberately pulled high or low during reset. The first 576 bytes received on SCC1 are stored in dual-port RAM, and each received character is echoed back out of TXD1 ; the device will not leave boot mode until all 576 bytes are received. For internal-clock bootstrap, the documented nominal clock assumptions are 4.192 MHz or 32.768 kHz , with the SCC programmed to approximately 9600 baud. In asynchronous UART mode, the bit rate is 1/16 of the TCLK1/RCLK1 clock rate when using the external clock option. So before replacing the part, I would try this exact minimal setup: Hold RESET and HALT low together . Strap PA7/BOOT low with a strong enough pulldown to overcome whatever is on your board. Select the intended clock mode with PA5 : PA5 = 0 : internal boot clock mode. PA5 = 1 : external clock on TCLK1/RCLK1 , 16× baud. Strap PA12/MODCLK0 consistently with the clock source; the manual samples it during hard reset to distinguish the nominal EXTAL frequency. Tie CD1 low . Keep RXD1 , TXD1 , RCLK1 , and TCLK1 wiring consistent with SCC1, not SCC2. The boot feature is for SCC1 in the LC302 description. Send a full 576-byte test stream, not just one character, although the echo should appear character-by-character once receive is working. The 3–4 mA sourced from PA7 is suspicious . The datasheet-level input leakage value retrieved is only 20 µA max , far below milliamps. Since PA7 is also a bidirectional multi-function pin, it is possible to get contention if something else is driving it or if the part has already left the reset-sampling state, but during reset-as-boot-strap it should not require sinking several mA just to read a low. I would check for a board-level pullup/driver/solder bridge on PA7 , verify the package pin orientation, and measure the current while both RESET and HALT are actively asserted. One more practical note: your 4 MHz internal-clock attempt is not equivalent to 4.192 MHz . It may be close enough for some UARTs if the other side is adjusted, but the documented internal bootstrap mode assumes the nominal LC302 clock values, so for eliminating variables I would use 4.192 MHz with the documented baud , or use the external-clock mode and provide clean TCLK1/RCLK1 = 16 × baud .   regards

FreeMaster Over CAN on interrupt fail to compile in polling mode I try to change those 3 mico for enabling polling mode from code generated from  "FreeMaster over CAN" and "s32k3xx_fm_over_can_s32ct"  FMSTR_SHORT_INTR, FMSTR_POLL_DRIVEN, and FMSTR_DEBUG_TX but end with compiling failed, reason is that transfer feature freemaster over can from "s32k3xx_fm_over_can_s32ct"  reply on interrupt, but if motor control case using many irq like least 10khz fast task and bctu and hall , wagtch dog, freemaster received no response from controllewr k312, polling mode is necessary. how to enable those 3 micros and open polling mode for "s32k3xx_fm_over_can_s32ct"  Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Communication modes are mutually exclusive options. That's exactly what the error message means. FreeMASTER Driver routine may require a significative processing time and those 3 settings try to help developers to balance the execution depending on use case as follows: FMSTR_POLL_DRIVEN - FreeMASTER routine is executed entirely in the FMSTR_Poll function - developers decides when it is called but has to make sure that it is invoked at such frequency that allows FreeMASTER to keep up with the communication speed FMSTR_LONG_INTR - FreeMASTER routine is executed entirely in the FMSTR_CanIIsr function - deveopers forces the system to executed it by assigning a higher priority (I assume this one was used as it fits best in case of big number of interrupts) FMSTR_SHORT_INTR - is a mix of the previous two: the communication is happening in the interrupt handler (FMSTR_CanIsr), but the processing - in (FMSTR_Poll) I think what you want to try is the last one (combination of polling + interrupt). Still, while the interrupt may guarantee that the CAN frames will be read, the board may not reply on time if FMSTR_Poll is not invoked frequently enough (due to interrupts with higher priority). As a result - FreeMASTER desktop tool will show timeout errors. The developer has to make sure that the system can allocate sufficient time for FreeMASTER Driver routines in compute intensive applications. Hope it clarifies FreeMASTER's communication modes. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I did try before using same setting as you: for example,  I changed FMSTR_POLL_DRIVEN as 1 (was 0.as interrupt mode) // Select interrupt or poll-driven serial communication #define FMSTR_LONG_INTR 1 // Complete message processing in interrupt #define FMSTR_SHORT_INTR 0 // Queuing done in interrupt #define FMSTR_POLL_DRIVEN 1/*0 */ 7 error: mainly because of #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !(FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* mismatch in interrupt modes, only one can be selected */ #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN #endif  3 error happen above for compile ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ one is not enough, but two even all also failed. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, To enable Polling mode you need to update the following macros: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 only one out of those 3 should be set to 1, overwise the code won't compile. Regarding FMSTR_DEBUG_TX - this is a debug macro that is meant to verify the TX line. Combined with previous definitions this one: #define FMSTR_DEBUG_TX 1 will instruct FreeMASTER Driver to continuously send a debug frame (note: this helps you inspecting the TX line and you won't be able to connect to the board using FreeMASTER tool while this functionality is enabled). Could you share your compilation error logs ? As far as I know, s32k3xx_fm_over_can_s32ct example is implemented by Model-Based Design Toolbox (MBDT) team. If you develop your application using Simulink, it may require updating block configuration instead of manual code changes. In this case, MBDT developers can provide better assistance for your use case through the dedicated MBDT community. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, I would try to troubleshoot the FMSTR_LONG_INTR mode, considering it is the only mode that works, even if only for a short time. The things I would look into are: Can you inspect the CAN bus with a logic analyzer and check whether the CAN messages are no longer being sent from the board, or if they are being sent but become corrupted? How many variables are you reading on the PC side? The number of variables is directly proportional to the amount of data exchanged between the PC tool and the board. If possible, I would start with a few variables and gradually increase the number to see when it breaks. Is the CAN instance used by any routines other than the FreeMASTER Driver? Did you start with a MATLAB/Simulink model or an S32 Design Studio example application? Depending on the original source, the FreeMASTER CAN driver implementation may differ. If possible, please attach the source files (they should be named freemaster_s32_flexcan.h and freemaster_s32_flexcan.c). Re: FreeMaster Over CAN on interrupt fail to compile in polling mode thanks for clarification, yes, combination of polling + interrupt is my target. restate issue: target k312 fail to send response after freeamster running a while. now feedback is following: interrupt mode: freemaster working, issue shown above, FMSTR_LONG_INTR only polling mode: compile,, freemaster not working ,  FMSTR_POLL_DRIVEN even if remove error message on freemaster_private.h:326:2: mixed: freemaster working, can compile  but traffic issue remain , all three of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN set as 1 and removing error message on freemaster_private.h:326:2: now I justify :Could be my CAN driver issue. which information do you need if your can provide further support? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1, I used peakcan view to monitor message flow, yes, CAN messages are no longer being sent from the board when freeamster smoothly working, message flashing very fast; when freeamaster freeze, CAN message sent from S32k312minEVB stopped apparently  but message read from freemaster still visible and slow; 2, totally less 20 variables, but amount is much smaller than demon fm project s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3.CAN instance solely used by freemaster; you are right,  our BSW use RTD ,to implement FM over CAN,  flexcan_43 and flexcan_ipw  layer from DEMON s32k3xx_fm_over_can_s32ct MCAL driver are integrated. but still working with issue above. by the way, due to CAN IP layer limit, our can driver can accept standard msg ID, so freeamster configue setting : send standard, receeive extension. please find atatched 4 files I have, which are close to you. do you need all CAN IP configure files? actually all 43/ipw configure same as demon s32k3xx_fm_over_can_s32ct. You can also directly email me.

UG10215 lists imx708 as supported — which kernel driver should be used? Hi, I'm working on integrating a Raspberry Pi Sony IMX708 camera on an i.MX 95 based board, following UG10215 (i.MX 95 Camera Porting Guide). The document's "List of camera sensors modules supported" table lists the Raspberry Pi Sony imx708 as a supported reference camera module. However, I couldn't find a corresponding driver (e.g. imx708.c) in the linux-imx repository (branch lf-6.18.y😞 https://github.com/nxp-imx/linux-imx/commits/lf-6.18.y/drivers/media/i2c Could you clarify which kernel driver is expected to be used for the imx708 sensor on the i.MX 95? Is the IMX708 driver included in the public BSP? Thanks in advance. Re: UG10215 lists imx708 as supported — which kernel driver should be used? Hello, We do not have it officially supported yet in our standard BSP, you can take the driver from raspberry sources and use it: https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/media/i2c/imx708.c Best regards/Saludos, Aldo. Re: UG10215 lists imx708 as supported — which kernel driver should be used? Hi Aldo, thanks for your reply. We do not have it officially supported yet in our standard BSP Will it be supported in the future? Why is the IMX708 camera listed in UG10215 if support is not included in the standard BSP? Thanks again Diego

UG10215 将 imx708 列为支持的内核驱动程序——应该使用哪个内核驱动程序？ 您好， 我正在按照 UG10215（i.MX 95 摄像头移植指南）将 Raspberry Pi Sony IMX708 摄像头集成到基于 i.MX 95 的板上。 文档中的“支持的相机传感器模块列表”表格将 Raspberry Pi Sony imx708 列为支持的参考相机模块。但是，我在linux-imx仓库（ lf-6.18.y分支）中找不到对应的驱动程序（例如imx708.c）。😞 https://github.com/nxp-imx/linux-imx/commits/lf-6.18.y/drivers/media/i2c 请问i.MX 95上的imx708传感器应该使用哪个内核驱动程序？IMX708 驱动程序是否包含在公开的 BSP 中？ 先行致谢。 Re: UG10215 lists imx708 as supported — which kernel driver should be used? 你好， 我们的标准 电路板支持包 中尚未正式支持此功能，您可以从树莓派源代码中获取驱动程序并使用它： https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/media/i2c/imx708.c 此致敬礼/Saludos， 阿尔多。 Re: UG10215 lists imx708 as supported — which kernel driver should be used? 嗨，阿尔多， 感谢您的回复。 我们的标准 BSP 尚未正式支持此功能。 未来还会支持吗？如果标准 电路板支持包 中不包含对 IMX708 摄像头的支持，为什么 UG10215 中会列出 IMX708 摄像头？ 再次感谢 迭戈

From Simulation to Vehicle Control: Real-Time Decision Making on the S32N55 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Modern vehicle development increasingly relies on digital validation before physical prototypes are available. Simulation enables rapid testing and iteration, but engineering teams also need to demonstrate how virtual behavior maps to real hardware. In the Hello World demonstrator, this connection is handled by the Main Node application running on the NXP S32N55. The Main Node acts as the central execution point of the demonstrator, transforming vehicle information generated inside MATLAB ® and Simulink ® into decisions and actions that can be observed on physical hardware. By combining Model-Based Design, CAN communication, and centralized decision making, the system creates a bidirectional link between the virtual vehicle and the physical demonstrator. This article explains how the Main Node converts simulation inputs into coordinated vehicle behavior while maintaining synchronization between the digital and physical domains. 3 Overview As introduced in the previous article, the S32N55 functions as the communication hub of the demonstrator, aggregating information from distributed modules and distributing commands throughout the system. Beyond communication, however, the Main Node also serves as the decision-making layer responsible for interpreting vehicle state and translating it into actionable control signals. Developed using the NXP Model-Based Design Toolbox (MBDT), the application is entirely modeled in Simulink and deployed directly onto the target hardware. This workflow enables engineers to focus on vehicle functionality and system behavior while leveraging automated code generation and integrated CAN communication support. The Main Node receives data from simulated and physical sources, maintains a coherent vehicle-state view, runs vehicle-level control logic, and sends commands to the actuator nodes that make up the demonstrator. This centralized architecture reflects the direction of modern software-defined vehicle platforms, where coordination moves from isolated ECUs toward higher-level compute nodes. Figure 1. Main Node overview showing how the S32N55 coordinates simulation inputs, vehicle-state processing, and commands to distributed hardware modules. 4 Context The Main Node is positioned between the virtual vehicle environment and the physical hardware modules that form the demonstrator. Driver inputs generated through the Driver-in-the-Loop simulation environment are transmitted over CAN and received by the S32N55, where they are processed alongside feedback arriving from multiple distributed nodes. Commands such as vehicle speed, steering angle, gear selection, braking requests, and lighting controls enter the Main Node from the simulation environment. These inputs are then evaluated by the application and translated into CAN messages that drive the corresponding hardware modules. This architecture enables the physical demonstrator to mirror the behavior of the virtual vehicle. When the simulated vehicle accelerates, the speed command is interpreted by the Main Node and forwarded to the motor control subsystem. Steering-wheel movements are translated into steering-angle commands for the steering module, while lighting commands activate headlights, fog lights, hazard lights, and turn indicators on the physical hardware. Figure 2. System context illustrating the Main Node as the bridge between the virtual vehicle environment and the physical demonstrator hardware. The Main Node can be driven either by the Driver-in-the-Loop simulation or by the External Control model. In both cases, the command source publishes the same DBC-defined CAN frames, so the S32N55 receives speed, steering, brake, gear, and lighting commands through the same interface. This allows the same deployed application to be exercised from two sources without changing the Main Node software. This approach is especially useful during integration, demonstrations, and incremental validation. Engineers can exercise the Main Node and the downstream actuator modules even when the complete virtual environment is not active, while still preserving the exact communication contract used by the full system. As a result, the application can be validated against two different input sources without changing the deployed software on the board. Rather than acting as a simple gateway, the Main Node continuously evaluates received information and executes vehicle-level decisions. One example is the processing of motor feedback data, where information from multiple motors is combined to derive a representative vehicle speed used throughout the system. Centralizing this functionality simplifies system coordination while ensuring consistency across all connected modules. Gear selection is handled as part of this centralized decision layer. The incoming gear command is interpreted as a driving mode that affects how the requested speed is applied: Park and Neutral block motion commands, Reverse changes the sign of the velocity reference, and Drive or Sport propagate the requested speed as a forward-driving command. This keeps speed-control behavior aligned with the selected driving mode while preserving the same driver-input signal set. The target-speed command is computed from the requested speed reference, the selected gear mode, the reported vehicle speed, and the effective brake command. Motor feedback is fused into a representative reported speed, which provides the actual-speed reference used during braking decisions. Under normal driving conditions, the requested target speed passes through the gearbox-aware logic and is converted into the motor-speed command sent over CAN. When braking is active, the Main Node bases the outgoing command on the detected speed and brake value, reducing the command until the vehicle is considered stopped. The Main Node also hosts the demonstrator's automated emergency braking functionality. Parking sensor nodes continuously report obstacle distances over CAN. The application evaluates these measurements and determines whether an object has entered a predefined safety zone. When this condition is met, the braking command issued by the driver can be overridden and replaced with an emergency braking request generated by the system. Figure 3. Parking sensors in action detecting nearby obstacles and providing distance feedback used by the Main Node to support emergency braking decisions. An important aspect of this implementation is that the braking behavior is reflected across both domains. The physical hardware responds to the braking request, while the simulation environment can receive corresponding vehicle-state updates through the same CAN-based loop. This closed-loop behavior demonstrates bidirectional interaction between simulation and embedded execution, allowing safety-related functionality to be validated in a realistic environment before a full vehicle prototype is available. Figure 4. Closed-loop emergency braking flow showing how parking sensor feedback can trigger an automated braking request across both the physical and simulated domains. CAN communication is the key enabler of this architecture. Every subsystem communicates through DBC-defined interfaces, allowing functionality to be distributed across multiple independent nodes while preserving a consistent and scalable communication framework. The shared DBC approach ensures that signal definitions remain synchronized across all parts of the demonstrator. To support this workflow, MathWorks Vehicle Network Toolbox ™ provides direct integration between MATLAB ® , Simulink ® , and CAN communication interfaces. DBC files can be used directly throughout the development process, simplifying signal management and ensuring consistency across the virtual vehicle, the Main Node, and all peripheral modules. As the demonstrator grows to include additional functionality, the same network definition can be reused across all participating systems, reducing integration effort and helping accelerate development. Note: The combination of NXP Model-Based Design Toolbox and MathWorks Vehicle Network Toolbox creates a workflow in which vehicle behavior, communication interfaces, and deployed software remain aligned from modeling through system integration. Figure 5. CAN and DBC workflow showing how shared signal definitions keep the virtual vehicle, Main Node, and distributed hardware modules synchronized. 5 References NXP Model-Based Design Toolbox (MBDT) NXP S32N Vehicle Super-Integration Processors Vehicle Network Toolbox ™ NXP Model-Based Design Toolbox Community 6 Conclusion The Main Node demonstrates how a centralized compute platform can act as more than a communication gateway. Running on the NXP S32N55, it combines signal aggregation, decision making, and command distribution into a single application that coordinates the entire demonstrator. By transforming simulation-generated inputs into physical vehicle behavior and feeding real-world information back into the virtual environment, the Main Node creates a practical closed-loop development platform. Together, NXP Model-Based Design Toolbox, MathWorks Vehicle Network Toolbox, and CAN-based communication enable rapid iteration, simplified integration, and efficient validation of vehicle functionality across simulated and physical domains.

iMX95 DRAM speed Hi, The current iMX95 can only support up to 6.4Gbps.  Will NXP release any processor that can support LPDDR5X with speed up to 8.5Gbps? Thanks. Re: iMX95 DRAM speed Hi @pengyong_zhang , Can you provide the model name? What will be the preliminary spec available? Thanks. Re: iMX95 DRAM speed Hi @simonng  Chips after version imx95 will support LPDDR5X 8533MT/s B.R

i.MX8MP_EVK: YOCTOコンパイルエラー do_package() (問題:tar & *at()) こんにちは、 これが私のヨクトビルドのパラメータです: リリース: imx-linux-walnascar BSPバージョン: imx-6.12.49-2.2.0 マシン: imx8mpevk ディストリビューション: fsl-imx-xwayland 私はこのビルド環境をここ数ヶ月間、問題なく使用しています。しかし、突然添付のエラーが発生するようになりました。 トラブルシューティングのため、ビルド環境を完全にクリーンアップし、リポジトリを再初期化（ repo init ）し、すべてを再度同期してから、新規ビルドを実行しました。しかし、残念ながら、依然として同じ問題が発生しています。 ご参考までに、添付のログファイルをご確認ください。根本原因の特定と解決策のご提案にご協力いただければ幸いです。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) bitbake imx-image-core Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) どの「bitbakeコマンド」を使用していますか？ 確認作業を行います。 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) ご返信ありがとうございます。 ビルド環境を確認したところ、既に推奨された構成と一致していました。 ホストOS: Ubuntu 22.04.5 LTS (Jammy) GNU tar バージョン: GNU tar 1.34 $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.5 LTS" ... $ tar --version tar (GNU tar) 1.34 しかし、私は依然として同じ失敗に遭遇します Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) ホストOSがUbuntu 24.04でtarのバージョンが1.35の場合は、tarのバージョンを確認してください。 コンテナまたは仮想マシン内でビルドするには、以下を使用します。 Ubuntu 22.04 LTS GNU tar 1.34 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 下記にファイルがあります。 ここにエラーメッセージの一部を貼り付けます DEBUG:python関数の実行extend_recipe_sysroot 注意:直接依存関係は['/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/gcc/gcc-cross_14.3.bb:do_populate_sysroot','/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.68.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-core/coreutils/coreutils_9.6.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/rpm/rpm_4.20.0.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-extended/bc/bc_1.08.1.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kmod/kmod_34.1.bb:do_populate_sysroot'] 注意:sysrootにインストールされています: [] 注意:sysrootで既に存在しているようにスキップしています: ['gettext-minimal-native', 'binutils-cross-aarch64', 'cmake-native', 'gcc-cross-aarch64', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'kern-tools-native', 'linux-libc-headers', 'file-native', 'openssl-native', 'coreutils-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'zlib-native', 'bison-native', 'dwarfsrcfiles-native', 'elfutils-native', 'flex-native', 'git-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'lua-native', 'make-native', 'patch-native', 'perl-native', 'pkgconfig-native', 'pseudo-native', 'python3-native', 'rpm-native', 'bc-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'lzlib-native', 'xz-native', 'zstd-native', 'kmod-native', 'acl-native', 'attr-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libmpc-native', 'libunistring-native', 'mpfr-native', 'nettle-native', 'p11-kit-native', 'popt-native', 'sqlite3-native'] DEBUG: Python関数extend_recipe_sysroot完了しました DEBUG:python関数の実行sstate_task_prefunc DEBUG: Python関数sstate_task_prefunc完了しました DEBUG:python関数の実行do_package DEBUG:python関数の実行package_setup_pkgv DEBUG:Python関数package_setup_pkgv 終わった DEBUG:python関数の実行package_convert_pr_autoinc DEBUG: Python関数package_convert_pr_autoinc完了しました DEBUG:python関数の実行package_prepare_pkgdata 注意:pkgdata-sysrootにインストールされています: [] DEBUG: Python関数package_prepare_pkgdata完成しました DEBUG:python関数の実行perform_packagecopy ERROR: exec_func_python()でPython関数を実行する際にエラーが生成されました: この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/home/vvdn/LWT_Build/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[パッケージ] = "${PKGD}" *** 0363: 0364:Python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 421、関数: check_output 0417: それ以外の場合: 0418: 空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 526、関数: 実行 0522: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0523: 上げる 0524: retcode = process.poll() 0525: チェックして戻りコードを取得する場合: *** 0526: raise CalledProcessError(retcode, process.args, 0527: 出力=標準出力、標準エラー=標準エラー) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /ホーム/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/Linux-imx/6.12.34+git/image -p -S .|tar -xf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/package' は非ゼロの退出ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パス lib 'lib' の絶対パスを割り当てられませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス TAR: ./USR/lib/modules:Cannot mkdir:そのようなファイルやディレクトリは存在しません Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 添付ファイルをダウンロードする権限がないようです。 もう一度送っていただけますか？ Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) こんにちは@yipingwang  さらなるデバッグのサポートをお待ちしています。 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Ubuntu PCで、「sudo apt install tar=1.34+dfsg-1build3」コマンドを使用してください。

i.MX95でCPU/GPU/VPUを無効にして消費電力を減らす方法 こんにちは、NXPさん。 当社は、i.MX95ベースのシステム全体の消費電力を削減する方法を模索しています。 以下の質問について、教えていただけますか? 不要なときに個々のCPUコアを完全にシャットダウンすることは可能ですか？ アプリケーションがGPUやVPUを使わない場合、完全に電源を切ることは可能でしょうか? CPU/GPU/VPUが不要なら、起動後にデフォルトで無効にしてさらに消費電力を減らすことは可能でしょうか?（デバイスツリーによる？） 最低限の電力消費を実現するための推奨ソフトウェア構成や参考資料はありますか? 私たちのBSPはYocto 5.2 / Linux 6.12.xをベースにしています。 ありがとうございます。 よろしくお願いいたします。 ショーン Linux

FS26 低压差线性稳压器(LDO) 关闭问题 Hello 我使用的是 FS26 和 S32K358。 我使用 FS26 的 VLDO2 作为 MCU 的电源，使用 FS26 的 VLDO1 作为 CAN 收发器的电源。 当 MCU 处于 CAN 通信状态时，FS26 的 VLDO 会关闭，从而切断 MCU 的电源。 （这种情况随机发生，大约每 1 至 8 小时发生一次。） 只有当 FS26 的电源被切断再恢复后，VLDO 才能恢复正常工作。 这个问题出现在所有电路板上，而不仅仅是单个电路板上，而且当 CAN 通信未进行时不会出现此问题。 问题发生时的状态如下： Vpre 6V O VDIG 1.6VO VBOS 5V O VLDO2 X VLDO1 X VCORE X DFS已通过OTP禁用。 我想了解 FS26 目前的状况以及导致这种情况发生的原因。 Re: FS26 LDO Off Issue 你好kjy106906 再会！ 监视程序是否已启用？ 以下各项的值是多少： FS_STATES FS_GRL_FLAGS FS_OVUV_REG_STATUS M_REG_FLG 故障发生后立即出现 M_STATUS 吗？ 你检查过FS26是否显示任何UV或OV标志吗？ 另外，能否分享一下您的 M_STATUS？ 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: FS26 LDO Off Issue @RafaR 感谢您的回复。 遗憾的是，MCU 已从 SBC 获得电源，但由于 VLDO 已关闭，因此无法进行通信。 必须切断并重新接通电路板电源，MCU才能正常工作。 监视窗口是无限的。

MCXW72のデバッグ認証応答 MCXW72のデバッグポートのロックを解除しようとしています。MCUXpressoのSecure Provisioning Toolでロック解除は正常に動作しますが、Debug Credential(DC)、DCK秘密鍵、デバイスから受け取ったDACに基づいて自分のアプリケーションを使ってポートのロック解除を試みています。 この分野のドキュメントは非常に不明瞭で(場合によっては誤りもあります)。 私の理解では、DARは以下の要素で構成されています。 DAR = DC + AB + UUID (DACより) + 署名 (リファレンス・マニュアルの図50ではUUIDとABフィールドの順序が誤っています。) OpenSSLを使って署名を計算したいのですが、どのデータを署名すべきか正確には判断できません。 a) DC + CV（DACから） b) DC + AB + CV (DACから) c) DC + AB + UUID (DACから) + CV (DACから) それとも全く別の何か？ ドキュメントには署名がDARをチャレンジベクトル(CV)に結合すると記載されていますが、ハッシュ化と署名すべき正確なバイトシーケンスは明確に指定されていません。DAR署名を生成するために使われる正確なデータを教えていただけますか? MCXA セキュリティ（EdgeLock | セキュアブート | OTP） Re: Debug authentication Response for MCXW72 こんにちは、 @Surdej Secure Provisioning ToolはSecure Provisioning SDKの上に構築されています。詳細は https://spsdk.readthedocs.io/en/latest/ これはオープンソースなので、そこで答えが見つかります。

iMX95 DRAM速度 こんにちは、 現在のiMX95は最大6.4Gbpsまでしかサポートできません。 NXPは最大8.5Gbpsの速度でLPDDR5Xをサポートできるプロセッサをリリースするのでしょうか? ありがとうございます。 Re: iMX95 DRAM speed こんにちは@pengyong_zhangさん モデル名を教えてもらえますか?入手可能な暫定仕様書はどのようなものですか？ ありがとうございます。 Re: iMX95 DRAM speed こんにちは、 @simonngさん バージョンIMX95以降のチップはLPDDR5X 8533MT/sをサポートします BR

[S32K3] [RTD 7.0.1]BCTUモジュールにおける3つの課題 RTDコードバージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206のBCTUモジュールに3つの問題が見つかりました。詳細な問題点は以下のとおりです。   問題 1:ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの 1558 行目で、現在のコードではビットごとの OR 代入を使用しています: BctuBasePtr->FIFOERR |= FifoWatermarkMask;これを直接代入に変更する必要があります: BctuBasePtr->FIFOERR = FifoWatermarkMask;   問題2：ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの567行目と568行目に、既存のコードに誤ったビットシフト演算が含まれています。元のコードは以下のとおりです。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << インデックス) : 0U; これらの2行は、以下のように正しいシフトロジックに修正する必要があります。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (インデックス * 2u)) : 0U;   問題3: MCAL/SDKコード生成ツールとBCTUモジュールの静的ソースコードの間に型の整合性の問題があります。MCAL で生成されたコード ( Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m 、2397行目）では、ヘッダーファイルとCファイルの両方で定義されている配列は、一律にuint32型を採用しています。SDK生成コードでは、ヘッダーファイルとCファイルの型定義が一貫していません。eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.hの配列型は(249行目)は、BctuFifoDmaRawDataオプションが有効になっているかどうかに応じてuint16とuint32を切り替え、対応する配列はeclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.cの対応する配列です（317行目）はuint32型に固定されています。静的コード ( Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 、1629行目）では、送信長（2バイトまたは4バイト）はBctuFifoDmaRawData構成に基づいて動的に決定されます。BctuFifoDmaRawDataオプションのチェックを外すと、以下の異常な問題がすべて発生します。 1.SDKプロジェクトの場合:ヘッダーファイルとCファイルの配列型が不一致で、直接コン パイル失敗を引き起こします。 2. MCALプロジェクトの場合:コンパイルは成功しますが、固定されたuint32配列定義のため メモリ容量の半分が無駄になります。さらに、各uint32データユニットには2つのADC結果が含まれているため、データ解析時にuint16の高値と低値を手動で分割する必要があります。 上記の3つのバグは、公式バージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206に存在します。NXPのソフトウェアエンジニアが次回RTDリリースでこれらのBCTUモジュールの欠陥を修正できることを期待しています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft あなたの質問は社内フォーラムにエスカレーションされており、設計チームからの確認を待っています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft ご意見ありがとうございます。 ソフトウェアチームと私はこれらの問題を確認しましたが、確かにバグです。 これらの問題は社内でエスカレーションしており、今後のアップデートで修正する予定です。

[S32K3] [RTD 7.0.1]BCTU模块中的三个问题 我在 RTD 代码版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206中发现了 BCTU 模块的三个问题。具体问题如下：   问题 1：在文件Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 的第 1558 行，当前代码使用按位或赋值： BctuBasePtr->FIFOERR |= FifoWatermarkMask;应修改为直接赋值： BctuBasePtr->FIFOERR = FifoWatermarkMask;   问题 2：在文件Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c的第 567 行和第 568 行中，现有代码包含不正确的位移操作。原始代码如下所示： ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?（BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index） : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << 索引) : 0U; 这两行代码应按如下方式修改为正确的换行逻辑： ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?（BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << （索引 * 2u）） : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (索引 * 2u)) : 0U;   问题 3： MCAL/SDK 代码生成工具与 BCTU 模块的静态源代码之间存在类型不一致对齐问题。在 MCAL 生成的代码（ Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m中，第 2397 行），头文件和 C 文件中定义的数组统一采用uint32类型。在 SDK 生成的代码中，头文件和 C 文件中的类型定义不一致： eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.h中的数组类型（第 249 行）根据BctuFifoDmaRawData选项是否启用，在uint16和uint32之间切换，而eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.c中的相应数组（第 317 行）固定为uint32类型。在静态代码（ Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c中，第 1629 行），传输长度（2 字节或 4 字节）是根据BctuFifoDmaRawData配置动态确定的。当取消选中BctuFifoDmaRawData选项时，会出现以下所有异常问题： 1.对于 SDK 项目：头文件和 C 文件之间数组类型不匹配会导致直接编译失败。 2. 对于 MCAL 项目：虽然编译可以成功，但固定的 uint32 数组定义导致一半的内存空间被浪费。此外，每个 uint32 数据单元包含两个 ADC 结果，需要在数据解析期间手动拆分高 uint16 值和低 uint16 值。 以上三个错误存在于官方版本S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206中。我们希望恩智浦软件工程师能在下一个 RTD 版本中修复这些 BCTU 模块缺陷。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module 您好@chenwilsoft 您的问题已提交至内部论坛，正在等待设计团队的确认。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module 您好@chenwilsoft 感谢您的反馈。 软件团队和我已经确认了这些问题，它们确实是软件漏洞。 我们已将这些问题上报内部，并将在未来的更新中修复它们。

i.MX8M Plus - Dedicated I2C for Display and Camera Hi Team, Just wanted to confirm if there is any Dedicated I2C for Display and Camera. (like I2C2 for Display and I2C4 for Camera) or there is no restriction on configuring can i use any I2C for Display and camera interfaces? Re: i.MX8M Plus - Dedicated I2C for Display and Camera You can use any available I2C controller for display-related or camera-related devices on i.MX8M Plus. There is no dedicated "camera I2C" or "display I2C" inside the SoC. The choice is determined by your hardware design and device-tree configuration.

i.MX8MP_EVK：YOCTO 编译错误 do_package()（问题：tar & *at()） 您好， 以下是我的 Yocto 构建参数： 发布版本： imx-linux-walnascar 电路板支持包 版本： imx-6.12.49-2.2.0 机器： imx8mpevk 发行版： fsl-imx-xwayland 过去几个月我一直成功地使用这个版本环境。然而，我突然开始遇到附件中的错误。 为了排查问题，我彻底清理了构建环境，重新初始化了代码仓库（ repo init ），再次同步了所有内容，并执行了一次全新的构建。但遗憾的是，问题依旧存在。 请查阅附件中的日志文件。我希望您能帮忙找出根本原因并提出解决方案。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) bitbake imx-image-core Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 你使用的是哪个“bitbake 命令”？ 我会进行核实。 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 感谢您的反馈， 我已检查过我的构建环境，它已经与您推荐的配置相符。 主机操作系统： Ubuntu 22.04.5 LTS (Jammy) GNU tar 版本： GNU tar 1.34 $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.5 LTS" ... $ tar --version tar（GNU tar）1.34 然而，我仍然遇到同样的故障。 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 请检查 tar 版本，如果主机是 Ubuntu 24.04，而 tar 版本是 1.35。 在容器或虚拟机内构建： Ubuntu 22.04 LTS GNU tar 1.34 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 请查收以下文件， 这里我粘贴一些错误信息。 调试：正在执行 Python 配方 extend_recipe_sysroot 注意：直接依赖项为 ['/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/gcc/gcc-cross_14.3.bb:do_populate_sysroot','/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.68.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-core/coreutils/coreutils_9.6.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/rpm/rpm_4.20.0.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-extended/bc/bc_1.08.1.bb:do_populate_sysroot','virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kmod/kmod_34.1.bb:do_populate_sysroot'] 注意：已安装到系统根目录：[] 注意：由于 sysroot 中已存在以下软件包，因此跳过：['gettext-minimal-native', 'binutils-cross-aarch64', 'cmake-native', 'gcc-cross-aarch64', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'kern-tools-native', 'linux-libc-headers', 'file-native', 'openssl-native', 'coreutils-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'zlib-native', 'bison-native', 'dwarfsrcfiles-native', 'elfutils-native', 'flex-native', 'git-native'、'gnu-config-native'、'json-c-native'、'libedit-native'、'lua-native'、'make-native'、'patch-native'、'perl-native'、'pkgconfig-native'、'pseudo-native'、'python3-native'、'rpm-native'、'bc-native'、'bzip2-native'、'libarchive-native'、'libidn2-native'、'lzlib-native'、'xz-native'、'zstd-native'、'kmod-native'、'acl-native'、'attr-native'、'curl-native'、'gdbm-native'、'gmp-native'、'gnutls-native' 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libmpc-native', 'libunistring-native', 'mpfr-native', 'nettle-native', 'p11-kit-native', 'popt-native', 'sqlite3-native'] 调试：Python 函数 extend_recipe_sysroot 已完成 调试：正在执行 Python 函数 sstate_task_prefunc 调试：Python 函数 sstate_task_prefunc 已完成 调试：正在执行 Python 函数 do_package 调试：正在执行 Python 函数 package_setup_pkgv 调试：Python 函数 package_setup_pkgv 已完成 调试：正在执行 Python 函数 package_convert_pr_autoinc 调试：Python 函数 package_convert_pr_autoinc 已完成 调试：正在执行 Python 函数 package_prepare_pkgdata 注意：已安装到 pkgdata-sysroot：[] 调试：Python 函数 package_prepare_pkgdata 已完成 调试：正在执行 Python 函数 perform_packagecopy 错误：执行 exec_func_python() 自动生成的 Python 函数时出错： 导致此异常/失败的 Python 调用堆栈跟踪如下： 文件：'exec_func_python() autogenerated'，行号：2，函数： 0001： *** 0002:perform_packagecopy(d) 0003： 文件：'/home/vvdn/LWT_Build/sources/poky/meta/classes-global/package.bbclass'，行号：363，函数：perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD} " 0362:perform_packagecopy[dirs] = "${PKGD} " *** 0363： 0364:python populate_packages() { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " 文件：'/usr/lib/python3.10/subprocess.py'行号：421，函数：check_output 0417：否则： 0418：空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: 返回 run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423： 0424： 0425:class CompletedProcess(object): 文件：'/usr/lib/python3.10/subprocess.py'lineno: 526, function: run 0522: # 我们不调用 process.wait()作为。 __exit__它能帮我们做到这一点。 0523：提高 0524: retcode = process.poll() 0525：如果检查并返回代码： *** 0526: 引发 CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: 返回 CompletedProcess(process.args, retcode, stdout, stderr) 0529： 0530: 异常：subprocess.CalledProcessError：命令“tar --exclude=./sysroot-only”-cf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/image -p -S .| tar -xf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/package' 返回非零退出状态 2。 子进程输出： 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./usr/lib：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./usr/lib：无法创建目录：地址错误 tar：./usr/lib/modules：无法创建目录：没有该文件或目录 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 我似乎没有权限下载该附件。 请您再发送一次好吗？ Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 嗨@yipingwang 期待您能尽快提供调试方面的支持。 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) 在你的 Ubuntu 电脑上，使用命令“sudo apt install tar=1.34+dfsg-1build3”

MFS2323BMBA5EP OTP構成の競合:SPIとI2Cモードの識別 NXPのエンジニアおよびコミュニティの専門家の皆様へ 現在、以下の方法で開発中です MFS2323BMBA5EP セーフティ SBCで、設定ファイルとデータシートレポートの間でOTPの工場出荷時設定に関する大きな矛盾に直面しました。この点についてご説明いただけると大変ありがたいです。 設定の競合： 1. 証拠 .cfg ファイル： 私の FS2320_BA5_CONFIG_Rev_A.cfg ファイルには、直接レジスタ値があります。 0x30 : 0x00 FS23データシート（表229）によると、 OTP_MAIN_SYS_I2C_CFG😞 ビット4（ SPI_EN_OTP ） ： 0 手段 I2Cは有効、SPIは無効です。 1 SPIが有効になっていることを意味します。 ビット3~0 ( I2CDEVADDR_OTP ) : 0000 意味する I2Cスレーブアドレスは 0x20 。 これは明らかに、このチップが工場出荷時に構成されていることを示唆しています。 I2Cモード。 2. 構成レポートPDFからの証拠： しかし、私の R_MFS2323BMBA5_Rev_A_test.pdf 文書、 表2. デバイスのOTP設定、レポートには明示的に記載されています。 SPI有効化：SPIピンが有効になっています。 これはハードウェアピンがロックされていることを示唆しています SPIモード。 私の実際のハードウェアテスト結果： MCU(S32K344)をSPIマスターとして設定し、このPMICと通信させたとき: MISOピンは一定のままです 0.3V （内部プルダウン抵抗が弱い高インピーダンス状態を示しており、スレーブ側がラインを駆動していないことを意味します。） PMIC側のSCKピンは、実際には独自にクロック信号を出力していた。 チップがOTPエミュレーションモードに固定されているか、I2Cスレーブとして設定されている可能性があり、それが原因でSPI通信が完全に失敗しているのではないかと考えています。 私の具体的な質問： 確認いただけますか MFS2323BMBA5EPの実際の工場出荷時OTP設定ですか?それはSPIですか、それともI2Cですか?  の間に対立が生じたとき。cfg registerファイル(0x30 : 0x00)とPDF設定レポート、どちらが絶対的なハードウェアの真実と考えられるべきでしょうか?PDFレポートにドキュメントの誤りが含まれている可能性はありますか? （添付しました） FS2320_BA5_CONFIG_Rev_A.cfg そして R_MFS2323BMBA5_Rev_A_test.pdf （参考としてこの投稿を参照してください）。 ご協力ありがとうございます！ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification はい、ありがとうございます。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification どちらの会社にお勤めですか？現在、お客様はご自身のメールアドレスを使用されていますが、これは優先度の低い（経営幹部レベルの）顧客とみなされます。 これには、回路図とCRCドライバに関連する一連の事項を確認する必要があります。 会社のメールアドレスを使ってチケットを送信することをお勧めします。 家 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 現状では不可能です。デバッグモードで通信しています。344ピンのSCK波形とMOSI波形を個別にテストしたところ、書き込んだデータは送信できました。しかし、FS23のSCKピンも信号を送信しているため、この2つを接続すると、MCUから送信されたSCK信号がFS23によってローにプルダウンされてしまいます。FS23に送信する応答はすべて0です。CRCも設定済みです。 紫色の線は、上部の信号以降のSCK信号を表しています。 黄色はデータ信号を示します。 定格電圧は5Vです。 送信されたデータは {0x02, 0x00, 0x00, CRC} です SCK波形を通常の波形として無理やり解釈すると、データが正しいことがわかります。最初のビットは2で、その後に00とCRCが続きます。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification SPIを使用して正常に通信できますか？ Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification FS23とS32K344がSPIで通信している際に、FS23のSCK信号も送信されている可能性はありますか？というのも、FS23とのSPI通信を設定しない場合、FS23のSCKピンをキャプチャしようとしても波形が取得できないからです。S32K344と通信している場合にのみ、FS23とS32K344の両方のSCKピンから信号が送信され、SCKピンとCSピンの波形が全く同じになります。 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification GUI経由で.cfgファイルをMirrorにアップロードしました。このレジスタはSPIモードを示します。

FS26 LDO Off Issue Hello I am using the FS26 and S32K358. I am using the FS26's VLDO2 as the power supply for the MCU and the FS26's VLDO1 as the power supply for the CAN transceiver. When the MCU is left in a state of CAN communication, the FS26's VLDO turns OFF, cutting off the MCU's power. (This occurs randomly, approximately every 1 to 8 hours.) The VLDO is restored only after the FS26's power supply is cut off and then restored. This issue occurs on all boards, not just a single one, and does not occur when CAN communication is not in progress. The status when the issue occurs is as follows: Vpre 6V O VDIG 1.6V O VBOS 5V O VLDO2 X VLDO1 X VCORE X DFS is disabled via OTP. I would like to know the current state of the FS26 and what causes this to happen. Re: FS26 LDO Off Issue Hello kjy106906  Good day! Is the watchdog enabled? What are the values of: FS_STATES FS_GRL_FLAGS FS_OVUV_REG_STATUS M_REG_FLG M_STATUS immediately after failure? Have you checked if FS26 is not displaying any UV or OV flags? Also could you share your M_STATUS? I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck. Re: FS26 LDO Off Issue @RafaR  Thank you for the reply. Unfortunately, the MCU is receiving power from the SBC, but communication is not possible because the VLDO is OFF. You must cut off and resupplied the board power for the MCU to function. The watchdog window is infinite.

システムマネージャーのドライバーコードPCAL6524 システムマネージャーのドライバーコードを教えていただけますかPCAL6524HEAZ fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 ビンソン様、 公式のMCUXpresso SDKsやSystem マネージャ ドライバは知りません。 fsl_pcal6524.cfsl_pcal6524.h fやPCAL6524HEAZ。NXP Linux BSPは、標準のLinux GPIOエクスパンダードライバーを通じて、PCA6524デバイスツリー互換文字列を使ってデバイスをサポートしています。i.MX95 19x19 EVK は、I²C GPIO エキスパンダーとして PCAL6524 を使用する公開サンプルです。https ://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   敬具、 ヨゼフ