Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
Kinetis MCX Wxx(MCX W71/72 和 MCX W23)工业物联网电源我的工具 本页面专用于 Kinetis MCX Wx(MCX W71/72 和 MCX W23)工业物联网电源我的工具。 它将帮助您估算应用(汽车、工业物联网、追踪器/标签和连续血糖监测 [CGM])中的功耗,并评估解决方案的电池寿命。 此页面包含 4 个专用的电源配置文件工具,分别用于: MCX W71/MCX W72 产品独立组网 \(SA\)蓝牙低功耗 (Bluetooth LE) 功能。 MCX W23 产品独立组网 (SA)的蓝牙低功耗 (Bluetooth LE)。 802.15.4 Matter ICD SIT & LIT 和 ZED 用于 MCX W71 & W72 产品的独立组网 \(SA\)。 Aliro 门锁应用(BLE MCX W72/UWB/NFC/电机) 1. MCX W71 / MCX W72 蓝牙低功耗功率配置文件: AN14389 MCX W71 蓝牙低功耗功耗分析 AN14739 MCX W72 蓝牙低功耗功率我的分析.pdf 2. MCX W23 蓝牙低功耗功率配置文件 AN14659:MCX W23 低功耗蓝牙功耗分析 | 恩智浦半导体 3. 802.15.4 Matter ICD SIT & LIT 和 ZED MCX W71/W72 功率分析 AN14841 MCX W72 802.15.4 物质和 Zigbee 功率我的分析.pdf 4.门锁应用(BLE/UWB/NFC/Motor)
記事全体を表示
TDA8954TH no sound output Hello! I have several speakers (Mackie Thump12) with no bass output. I changed the output IC TDA8954TH and the 10R resistors. No sound at all. Does anybody else have problems with this IC? I ordered 3 ICs from different sellers on ALI Express. Best regards, Johannes Re: TDA8954TH no sound output Hello Johannes, The TDA8954TH is a legacy product that is no longer in production and we no longer provide technical support for this device. Perhaps someone else who uses it could help.   BRs, Tomas
記事全体を表示
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. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, Unfortunately, I did not find any attachments on the this thread, but I got those files from MBDT and it indeed differs from the our team's implementation. Could you try replacing MBDT implementation with our version (see attachments - those correspond to freemaster_s32k3xx_can.c and freemaster_s32k3xx_can.h). One inconsistency I noticed is the CAN interrupt handler signature: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); vs void FMSTR_CanIsr(void); Assuming CAN details (such as buffer IDs) are defined in freemaster_cfg.h we do not need them in the handler. We also use RTD (low hardware layer) and  your configuration should not change. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I fail to upload files request, how to upload files into this thread Re: FreeMaster Over CAN on interrupt fail to compile in polling mode except request help to find any function to reset CAN read buffer, I  also suspect one change made for MBD CAN driver code Can_43_FLEXCAN_Ipw.c where, function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer are forced to memcpy to transfer when I integrate MBD MCAL CAN driver into RTD NON-MCAL driver. if no manual transfer, Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer fail to read all can information when using RTD NON-MCAL CAN driver. original MBD DEMON s32k3xx_fm_over_can_s32ct dont need manual transfer, because demon use MCAL CAN 43 driver. is any way to avoid manual trasnfer in function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() if it cause Freemaster issue? or manual reset buffer via some function you know? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig->Can_u8ControllerID][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode feedback: thanks for supply rtd version freemaster driver code, I did replace MBD version function FMSTR_CanIsr(*,*,*..*) in mcal driver freemaster_s32k3xx_can  by FMSTR_CanIsr() in rtd driver  freemaster_can_flexcan. integration and run, Freemaster fail to connect with s32k312MINEVB. I start to debug when freemaster freeze when S32K312N=MINEVB fail to send out message, I found out sw in status of busy to read, which cause unfinished CAN read ,indirectly cause can sent delay unlimited; is any functions to manually clear buffer for read like reset if buffer are full?
記事全体を表示
FreeMaster Over CAN on interrupt on 轮询模式 编译失败 我尝试修改“FreeMaster over CAN”和“s32k3xx_fm_over_can_s32ct”生成的代码,以启用轮询模式。 FMSTR_SHORT_INTR 、 FMSTR_POLL_DRIVEN和FMSTR_DEBUG_TX 但最终编译失败,原因是传输功能 freemaster 通过 can 从“s32k3xx_fm_over_can_s32ct”响应中断,但如果电机控制情况使用许多 irq,例如至少 10khz 的快速任务以及 bctu 和 hall、wagtch dog,freemaster 没有收到来自控制器 k312 的响应,因此需要轮询模式。 如何启用这 3 个微控制器并为“s32k3xx_fm_over_can_s32ct”打开轮询模式? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 沟通方式是互斥的选项。错误信息的意思正是如此。 FreeMASTER 驱动程序例程可能需要较长的处理时间,以下 3 个设置旨在帮助开发人员根据不同的使用场景平衡执行时间: FMSTR_POLL_DRIVEN - FreeMASTER 例程完全在 FMSTR_Poll 函数中执行 - 开发人员可以决定何时调用该例程,但必须确保其调用频率足以使 FreeMASTER 跟上通信速度。 FMSTR_LONG_INTR - FreeMASTER 例程完全在 FMSTR_CanIIsr 函数中执行 - 开发人员通过分配更高的优先级强制系统执行它(我假设之所以使用这个优先级,是因为它最适合处理大量中断的情况)。 FMSTR_SHORT_INTR 是前两者的混合体:通信发生在中断处理程序 (FMSTR_CanIsr) 中,但处理发生在 (FMSTR_Poll) 中。 我认为你想尝试的是最后一种方法(轮询+中断的组合)。虽然中断可以保证读取 CAN 帧,但如果 FMSTR_Poll 没有被足够频繁地调用(由于优先级更高的中断),则电路板可能无法及时响应。因此,FreeMASTER桌面工具将显示超时错误。 开发人员必须确保系统能够为计算密集型应用程序中的 FreeMASTER 驱动程序例程分配足够的时间。 希望这能帮助大家了解 FreeMASTER 的通信模式。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我之前也尝试过使用和你一样的设置: 例如,我将FMSTR_POLL_DRIVEN 改为 1(之前为 0,表示中断模式)。 // 选择中断驱动或轮询驱动的串行通信 #define FMSTR_LONG_INTR 1 // 在中断中完成消息处理 #define FMSTR_SHORT_INTR 0 //中断中完成排队 #define FMSTR_POLL_DRIVEN 1 /*0 */ 7. 错误:主要原因是 #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) /* 中断模式不匹配,只能选择一种 */ #错误您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 #endif 上述编译过程中出现了 3 个错误。 ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ 一个不够,两个也都失败了。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 要启用轮询模式,您需要更新以下宏: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 这 3 个参数中只能有一个设置为 1,否则代码将无法编译。 关于FMSTR_DEBUG_TX - 这是一个用于验证 TX 线的调试宏。结合之前的定义,得出以下定义: #define FMSTR_DEBUG_TX 1 将指示 FreeMASTER 驱动程序持续发送调试帧(注意:这有助于您检查 TX 线,但启用此功能后,您将无法使用 FreeMASTER 工具连接到电路板)。 能否分享一下编译错误日志? 据我所知, s32k3xx_fm_over_can_s32ct 示例是由基于模型的设计工具箱 (MBDT)团队实现的。如果您使用 Simulink 开发应用程序,则可能需要更新模块配置,而不是手动修改代码。在这种情况下,MBDT 开发人员可以通过专用的 MBDT社区为您的用例提供更好的帮助。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 我会尝试排查FMSTR_LONG_INTR模式的问题,因为它是唯一有效的模式,即使只能维持很短的时间。我会调查以下几个方面: 您能否使用逻辑分析仪检查 CAN 总线,并确认 CAN 消息是否不再从电路板发送,或者是否正在发送但已损坏? 在PC端,你读取了多少个变量?变量的数量与PC工具和板之间交换的数据量成正比。如果可能的话,我会先从几个变量开始,然后逐渐增加变量的数量,看看什么时候会出问题。 除了 FreeMASTER 驱动程序之外,还有其他程序使用 CAN 实例吗? 您是从 MATLAB/Simulink 模型还是 S32 Design Studio 示例应用程序开始的?根据原始来源的不同,FreeMASTER CAN 驱动程序的实现方式可能会有所不同。 如果可以,请附上源文件(它们应该命名为freemaster_s32_flexcan.h和freemaster_s32_flexcan.c )。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 感谢你的澄清,是的,我的目标是轮询+中断相结合。 重述问题:目标 k312 在 FreeAmster 运行一段时间后无法发送响应。 以下是反馈意见: 中断模式:freemaster 工作正常,问题如上所述,仅限 FMSTR_LONG_INTR 轮询模式:编译,freemaster 无法工作,即使移除 freemaster_private.h:326:2 中的 FMSTR_POLL_DRIVEN 错误消息: 混合:freemaster 可以运行,可以编译,但流量问题仍然存在,FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 这三个值都设置为 1,并移除 freemaster_private.h:326:2 处的错误消息: 现在我推断:可能是我的 CAN 驱动程序问题。 如果您可以提供进一步的支持,您需要哪些信息? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1、我使用 PeakCan View 来监控消息流, 是的,板不再发送CAN消息了。 Freemaster 运行正常时,消息闪烁非常快;Freemaster 死机时,从 S32k312minEVB 发送的 CAN 消息明显停止,但从 Freemaster 读取的消息仍然可见且速度很慢; 2,总共少于 20 个变量,但数量远小于 demon fm 项目 s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3. CAN 实例仅供 freemaster 使用; 您说得对,我们的 BSW 使用 RTD 来实现 CAN 上的 FM,集成了 DEMON s32k3xx_fm_over_can_s32ct MCAL 驱动程序中的 flexcan_43 和 flexcan_ipw 层。但上述问题仍在解决中。 顺便说一下,由于 CAN IP 层限制,我们的 can 驱动程序可以接受标准消息 ID,所以 freeamster 配置设置:发送标准,接收扩展。 请查收附件中的 4 个文件,它们与您关系密切。 您需要所有 CAN IP 配置文件吗?实际上所有 43/ipw 配置都与 demon s32k3xx_fm_over_can_s32ct 相同。 您也可以直接给我发邮件。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 很遗憾,我没有在这个帖子里找到任何附件,但我从 MBDT 获取了这些文件,它确实与我们团队的实现方式不同。 您能否尝试将 MBDT 实现替换为我们的版本(请参阅附件 - 这些文件对应于freemaster_s32k3xx_can.c和freemaster_s32k3xx_can.h )? 我注意到的一个不一致之处在于 CAN 中断处理程序的签名: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); 对比 void FMSTR_CanIsr(void); 假设 CAN 详细信息(例如缓冲区 ID)已在freemaster_cfg.h中定义我们不需要在处理程序中使用它们。我们也使用 RTD(底层硬件层),您的配置不应更改。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我上传文件请求失败,请问如何将文件上传到这个帖子? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 除了请求帮助查找重置 CAN 读取缓冲区的任何功能之外, 我还怀疑MBD CAN驱动程序代码Can_43_FLEXCAN_Ipw.c中做了一处修改。 其中,函数 当我将 MBD MCAL CAN 驱动程序形容功能时作“内置”,形容器件时作“集成”到 RTD NON-MCAL 驱动程序中时,Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 被强制使用 memcpy 进行传输。 如果没有手动传输,使用 RTD NON-MCAL CAN 驱动程序时,Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 将无法读取所有 CAN 信息。 原版 MBD DEMON s32k3xx_fm_over_can_s32ct 不需要手动传输,因为 demon 使用的是 MCAL CAN 43 驱动程序。 如果手动传输会导致 Freemaster 问题,有没有办法避免在函数 Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() 中进行手动传输? 或者通过你知道的某个功能手动RESET缓冲区? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig-> Can_u8ControllerID ][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 反馈:感谢您提供RTD版本的FreeMaster驱动程序代码, 我用 rtd 驱动程序 freemaster_can_flexcan 中的 FMSTR_CanIsr() 替换了 mcal 驱动程序 freemaster_s32k3xx_can 中的 MBD 版本函数 FMSTR_CanIsr(*,*,*..*)。 集成和运行,Freemaster 无法连接到 s32k312MINEVB。 当 S32K312N=MINEVB 无法发送消息时,freemaster 冻结,我开始调试,发现软件处于忙于读取状态,导致 CAN 读取未完成,间接导致 CAN 发送延迟无限长; 是否有类似缓冲区满时RESET读取操作的手动清除缓冲区的功能?
記事全体を表示
CONFIG_FIT_CIPHER=y のみで hab_status が発生します サポートの皆さん、こんにちは。 CONFIG_FIT_CIPHER=yのみを設定すると、i.MX8M Plus EVK (OPENモード) でhab_statusがHAB_INV_SIGNATURE/HAB_INV_ASSERTIONを報告する。 ボード:i.MX8MP LPDDR4 EVK、オープン/非フューズ(HAB構成:0xf0、HAB状態:0x66) U-Boot: 2024.04 (lf_v2024.04_6.6.52_2.2.x), NXP fork HAB署名:それ以外は正しく動作する — CST署名imx-boot(SPL CSF + FIT CSF)、両方の埋め込みオフセットでCSFタグバイトを検証し、不一致があればビルド失敗(必ず合格)するカスタムビルドタイムタスク 通常のHAB署名済みimx-bootでhab_status「HABイベント情報 Found!」と報告するというクリーンなベースラインがあります。最近、カーネルFITイメージ署名+AES-256暗号化を追加しました(HABとは別の仕組みで、U-Boot独自のbootmが署名済みカーネルFITの検証・復号を行い、鍵はu-boot.dtbに埋め込まれています)。SRKヒューズとは無関係です。これを有効にした後、hab_status毎回の起動で4つのイベント情報を報告し始めました: HAB 構成:0xf0、HAB 状態:0x66 HABイベント情報1:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報2:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報3:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HABイベント情報4:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY 私は、実際のハードウェアで確認しながら、一度に1つの変数ずつ、独立した再構築+再フラッシュテストを実施して、この問題を体系的に二分しました。 1. ベースライン(既存のHAB署名imx-boot、カーネルFIT作業なし):イベント情報0 2. 完全なカーネルFIT機能を有効にし(FIT pubkey/AESキーDTB埋め込み+私自身のcmd/bootm.cパッチ + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000):4つのイベント情報 3. FIT pubkey/AESキーDTB埋め込みのみ無効化:イベント情報が依然存在し、同一 4. また、私のコマンド/bootm.cも削除しましたパッチ:イベント情報は依然として存在し、同一です 5. CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000を完全に除去(真のプレカーネルFITベースライン):イベント情報0、クリーン 6. 復活は CONFIG_SYS_BOOTM_LEN=0x8000000(CONFIG_FIT_CIPHERなし):0イベント情報、クリーン 問題は正確には CONFIG_FIT_CIPHER=y に限定されており、他の要因は関係ありません (私の bootm.c)パッチ、FIT pubkey/AESキーのDTB埋め込み、CONFIG_SYS_BOOTM_LEN)単独または組み合わせでマター;CONFIG_FIT_CIPHER=yだけが0イベント情報からこの4 hab_statusに切り替わります。 私自身の CSF 計算に問題がないことを二重に確認しました。私のビルド時の署名タスクは、署名直後に両方の埋め込みオフセットの CSF タグバイトを検証し、不一致があればビルドを失敗させます。CONFIG_FIT_CIPHER の有無にかかわらず、すべてのビルドは正常にパスし、この構成に関係なく、計算された SLD hab ブロック アドレス/FIT CSF オフセットはすべてのテストビルドでバイト単位で同一です。 私の推測ではCAAMジョブリングの競合が原因です。CONFIG_FIT_CIPHER CONFIG_AESを引く(このU-Bootバージョンでは別のバックエンドシンボルは不要です)、このSoCのランタイムDMESGはCAAMが他のAES/SHAで実際に使われていることを確認しています。私が見つけた最も関連性の高いドキュメントは、doc/imx/habv4/guides/mx8m_secure_boot.txtですv4.4.0以前のHABがクローズド設定でジョブリング/DECOマスターIDレジスタをロックする点に注意が必要ですが、これはこのオープンモードのCONFIG_FIT_CIPHER特有のケースを直接説明しているわけではありません。 質問: 1.i.MX8M Plus上のCONFIG_FIT_CIPHERとHABv4のCSF認証の間に既知のやり取りがあるのでしょうか?これはCAAMリソースに関連する問題でしょうか、それとも別の問題でしょうか(例えば、コンパイルされたバイナリのサイズやレイアウトによってFIT CSFコンポーネントの境界がずれてしまい、私の自己チェックでは検出できないようなずれが生じているなど。自己チェックはROMが独自に導出したオフセットではなく、私が計算したオフセットに対して検証を行うため)。 2. このSoC上では、CONFIG_FIT_CIPHERをHABv4 CSF署名と組み合わせても安全性が確認できるのでしょうか、それともこれは実際の制限事項なのでしょうか? 3. もしそれが根本原因だった場合、正しいCAAMジョブリングの割り当て/ロック解除手順を示すヒントはありますか? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status 解決済みとして投稿します。誰かが二分を省く助けになるCASEからです。実際の修正は[https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/m-p/2344924/highlight/true#M244756]に感謝します。私が見つけた直後に直接適用されました。 症状:通常のHAB署名済みimxブートで、hab_status "HABイベント情報なし!"と報告するベースラインはクリーンです。CONFIG_FIT_CIPHER=yを有効にして(AES-256で暗号化されたカーネルFITイメージをU-Bootで復号するU-Bootをサポートするためで、HABとは別の仕組みでSRKヒューズとは無関係)、hab_statusは毎回のブートで4つのイベント情報(2× HAB_INV_ASSERTION、2× HAB_INV_SIGNATURE)を報告し始めました。 二分割:変更した変数を一つずつ分離し、実際のハードウェアで毎回リビルド+リフラッシュ+hab_statusを行いCONFIG_FIT_CIPHERました。(FIT pubkey/AESキーのDTB埋め込みを無効にし、無関係なcmd/bootm.cを削除)まで変更しましたパッチや保持・落CONFIG_SYS_BOOTM_LEN――どれもマターではありませんでした。CONFIG_FIT_CIPHERだけがそうした)。 根本原因+修正:手動HAB署名ワークフローを移植したカスタムYoctoタスクでimx-bootを構築しました(SPL IVTを解析し、print_fit_hab.shでFITコンポーネントブロックを計算します。CSTで署名して自動ビルドステップに組み込む。そのタスクは、mkimage_imx8 自身のビルドによってビルドステージング ディレクトリに残された DTB コピーが既に正しく 16 バイト境界にアラインされていることを前提としていましたが、すべての構成で保証されているわけではありません。CONFIG_FIT_CIPHER U-Boot本体のコンパイルされたDTBサイズを変更し、私たちの場合は非アラインサイズに設定します。ずれたDTBは計算print_fit_hab.shすべてのFITコンポーネント境界を静かにシフトするため、CSTは誤ったバイト範囲に符号化します。我々が独自に構築時に行う自己チェック(計算したオフセットにCSFタグバイトが存在するかどうかの確認)は毎回問題なく合格していた。これはROMが独自に正しく定義する境界値と照合していたわけではなかった。本物のハードウェアだけがそれを捉えた。 修正:他のThreadでうまくいったことをミラーリングします。つまり、FITコンポーネントブロックを計算する直前にDTB上で明示的にpad_image.sh(imx-mkimage独自のスクリプト)を実行し、ステージングディレクトリの既存状態を信頼するのではなく、実際にパディングされていたこと(何もしない操作ではなかったこと)が確認され、hab_statusは再びクリーンな状態になり、フル機能が有効になりました。
記事全体を表示
TDA8954TH 无声音输出 您好! 我有几个音箱(Mackie Thump12),但它们没有低音输出。我更换了输出集成电路 TDA8954TH 和 10R 电阻。完全没有声音。还有其他人遇到过这款集成电路的问题吗? 我在速卖通上从不同的卖家那里订购了3个集成电路。 顺祝商祺! 约翰内斯 Re: TDA8954TH no sound output 你好,约翰内斯, TDA8954TH是一款已停产的旧产品,我们不再为此设备提供技术支持。或许其他使用者可以提供帮助。   BRs,托马斯
記事全体を表示
Kinetis (KW3x/4x) Power Profile Tools for Automotive This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47) Power Profile Tools for Automotive. It will help you to estimate the power consumption in your Automotive application (keyfob/smartfob & anchor) and evaluate the battery life time of your solution. This page contains 3 dedicated power profile tools for: Bluetooth LE for the KW35/36 products in standalone. Bluetooth LE for the KW37/38/39 products in standalone. Bluetooth LE for the KW45/KW47 products in standalone. SmartFob application (BLE/KW45; UWB Ranger4; SE; motion sensor) SmartFob application (BLE/KW47; UWB Ranger5; SE; motion sensor)    1. KW35/36 Bluetooth LE power profiling standalone:  christophe_menard_0-1785491668653.png 2. KW37/38/39 Bluetooth LE power profiling standalone:  christophe_menard_1-1785491723947.png This tool includes 3 different use cases to get a rough estimation of the Anchor and Keyfob/Smartphone power consumptions:    1- CCC mobile phone connected to the car and exchange packets to unlock the door of the car    2- SCA Keyfob connected to the car and exchange packets continuously    3- CCC Smartphone connected to the car and exchange packets continuously : 2 row modes 3. KW45/KW47 Bluetooth LE power profiling standalone: AN13230 Kinetis KW45 Bluetooth LE Power Consumption Analysis AN14554 Kinetis KW47 Bluetooth LE Power profile analysis release.pdf 4. SmartFob application (BLE/KW45; UWB Ranger4; SE; motion sensor) power profiling 5. SmartFob application (BLE/KW47; UWB Ranger5; SE; motion sensor) power profiling christophe_menard_2-1785493894936.png id:wireless-connectivity [start:July 31 2026]
記事全体を表示
Kinetis (KW3x/4x) 汽车用电动我的工具 本页面专用于介绍 Kinetis(KW35/KW38/KW45/KW47)用动力我的工具 汽车。 它将帮助您估算汽车应用(钥匙扣/智能钥匙扣和锚点)中的功耗,并评估解决方案的电池寿命。 本页面包含 3 个专用的电源配置文件工具,分别用于: KW35/36 产品独立组网 (SA)的蓝牙低功耗功能。 KW37/38/39 产品独立组网 (SA)的蓝牙低功耗功能。 KW45/KW47 产品独立组网 \(SA\)的蓝牙低功耗功能。 SmartFob 应用(BLE/KW45;UWB Ranger4;SE;运动传感器) SmartFob 应用(BLE/KW47;UWB Ranger5;SE;运动传感器)    1. KW35/36 蓝牙低功耗独立组网 \(SA\)功率配置文件:  christophe_menard_0-1785491668653.png 2. KW37/38/39 蓝牙低功耗独立组网 (SA)功率配置文件:  christophe_menard_1-1785491723947.png 该工具包含 3 种不同的使用场景,用于粗略估算锚点和钥匙扣/智能手机的功耗: 1. CCC手机与汽车连接并交换数据包以解锁车门 2. SCA遥控钥匙与汽车连接并持续交换数据包 3- CCC智能手机连接到汽车并持续交换数据包:2行模式 3. KW45/KW47 蓝牙低功耗独立组网 \(SA\)功率我的: AN13230 Kinetis KW45 蓝牙低功耗功耗分析 AN14554 Kinetis KW47 蓝牙低功耗功率我的分析版本.pdf 4. SmartFob 应用(BLE/KW45;UWB Ranger4;SE;运动传感器)功率曲线分析 5. SmartFob 应用(BLE/KW47;UWB Ranger5;SE;运动传感器)功率曲线分析 christophe_menard_2-1785493894936.png id:无线连接 [开始日期:2026年7月31日]
記事全体を表示
FreeMaster Over CANは割り込み時にポーリングモードでコンパイルできません 「FreeMaster over CAN」と「s32k3xx_fm_over_can_s32ct」から生成されたコードから、ポーリングモードを有効にするために3 micoを変更しようとしています。 FMSTR_SHORT_INTR 、 FMSTR_POLL_DRIVEN 、およびFMSTR_DEBUG_TX しかしコンパイルに失敗しました。理由は、転送機能のフリーマスターオーバーが割り込み時に「s32k3xx_fm_over_can_s32ct」応答から可能になるためです。しかし、モータ制御の場合、少なくとも10kHzの高速タスクやBCTU、ホール、ワッチドッグ、フリーマスターはControllewr K312からの応答を受け取れず、ポーリングモードが必要です。 これら3つのマイクロコントローラを有効にして、「s32k3xx_fm_over_can_s32ct」のポーリングモードを開く方法 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 通信手段は相互に排他的な選択肢である。エラーメッセージはまさにそのことを意味しています。 FreeMASTERドライバールーチンはかなりの処理時間を必要とする場合があり、これら3つの設定は利用ケースに応じて実行のバランスを取るのに役立ちます。 FMSTR_POLL_DRIVEN - FreeMASTERルーチンはFMSTR_Poll関数内で完全に実行されます。開発者は呼び出しタイミングを決定しますが、FreeMASTERが通信速度に追いつけるような頻度で呼び出されるようにする必要があります。 FMSTR_LONG_INTR - FreeMASTERルーチンは完全にFMSTR_CanIIsr関数内で実行されます。デベオパーはシステムに高い優先度を割り当てることで実行を強制します(これは多数の割り込み時に最適だったため使われたと思います)。 FMSTR_SHORT_INTR - は前述の2つの混合であり、通信は割り込みハンドラー(FMSTR_CanIsr)で行われ、プロセッシングは(FMSTR_Poll)で行われます あなたが試すべきなのは、最後の方法(ポーリングと割り込みの組み合わせ)だと思います。それでも割り込みはCANフレームの読み取りを保証するかもしれませんが、FMSTR_Poll呼び出す頻度が十分でない場合(より高い優先度の割り込みによる)、ボードが時間通りに応答しないことがあります。その結果、FreeMASTERデスクトップツールでタイムアウトエラーが表示されます。 開発者は、計算集約型アプリケーションにおいてFreeMASTERドライバーのルーチンに十分な時間を割り当てられるかを確実にしなければなりません。 これでFreeMASTERの通信モードが明確になったことを願います。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 以前、あなたと同じ設定で試してみました。 例えば、 FMSTR_POLL_DRIVENを1に変更しました(以前は割り込みモードとして0でした)。 // 割り込み駆動またはポーリング駆動のシリアル通信を選択します #define FMSTR_LONG_INTR 1 割り込みにおけるメッセージプロセッシングの完了 #define FMSTR_SHORT_INTR 0 //割り込みでキューイングが完了 #define FMSTR_POLL_DRIVEN 1 /*0 */ 7 エラー: 主に #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) 割り込みモードでは1つだけ選択可能です */ #エラーFMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります #endif コンパイル時に上記で3つのエラーが発生しました ../FMsrc/freemaster_private.h:326:2: エラー: #error FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります 326 | #エラー FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: エラー: #error FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります 326 | #エラー FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: エラー: #error FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります 326 | #エラー FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります。 | ^~~~~ 1つでは不十分だが、2つでもすべて失敗に終わった。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode こんにちは、 @millerhughes さん。 ポーリングモードを有効にするには、以下のマクロを更新する必要があります。 #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 3つのうち1つだけを1に設定する必要があります。そうしないと、コードはコンパイルされません。 FMSTR_DEBUG_TXについてですが、これはTXラインを検証するためのデバッグマクロです。これまでの定義と合わせて、次の定義も考えられます。 #define FMSTR_DEBUG_TX 1 FreeMASTERドライバーに継続的にデバッグフレームを送信するよう指示します(注:これはTXラインの検査に役立ちますが、この機能が有効になっている間はFreeMASTERツールでボードに接続できません)。 コンパイルエラーログを共有してもらえますか? 私の知る限り、s32k3xx_fm_over_can_s32ct例はモデルベースデザインツールボックス(MBDT)チームによって実装されています 。Simulinkでアプリケーションを開発する場合、手動のコード変更ではなくブロック設定の更新が必要になるかもしれません。この場合、MBDT開発者は専用のMBDTコミュニティを通じて、あなたのユースケースにより適切な支援を提供できます 。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode ご説明ありがとうございます。はい、ポーリングと割り込みの組み合わせが私の目標です。 問題の要約:ターゲットk312は、freeamsterをしばらく実行した後、応答を送信できません。 フィードバックは以下のとおりです。 割り込みモード:フリーマスター動作中、上記の問題発生、FMSTR_LONG_INTRのみ ポーリングモード: コンパイル、freemaster が動作しない、freemaster_private.h:326:2 のエラーメッセージを削除しても FMSTR_POLL_DRIVEN: 混合:FreeMasterは動作し、コンパイルは可能ですがトラフィックの問題は残ります。FMSTR_LONG_INTRまたはFMSTR_SHORT_INTRまたはFMSTR_POLL_DRIVENの3つすべてが1に設定され、freemaster_private.h:326:2のエラーメッセージが削除されます: 今は正当化します:おそらくCANドライバーの問題かもしれません。 もし追加のサポートができるなら、どのような情報が必要ですか? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode こんにちは、 @millerhughes さん。 FMSTR_LONG_INTRモードは、たとえ短時間しか動作しないとしても、唯一動作するモードなので、このモードのトラブルシューティングを試みるつもりです。私が調査するであろう事項は以下のとおりです。 ロジックアナライザでCANバスを点検して、CANメッセージがボードから送信されていないのか、送信されているものの破損しているのかを確認できますか? PC側で読み込んでいる変数はいくつありますか?変数の数は、PCツールとボード間でやり取りされるデータ量に正比例する。可能であれば、まずは少数の変数から始めて、徐々に数を増やしていき、どこで問題が発生するかを確認したいです。 CANインスタンスはFreeMASTERドライバー以外のルーチンで使われていますか? MATLAB/Simulinkモデルから始めましたか?それともS32 Design Studioのサンプルアプリケーションから始めましたか?元のソースによって、FreeMASTER CANドライバの実装は異なる場合があります。 可能であれば、ソースファイル( freemaster_s32_flexcan.hとfreemaster_s32_flexcan.cという名前である必要があります)を添付してください。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1. Peakcan Viewを使用してメッセージフローを監視しました。 はい、CANメッセージはもうボードから送信されていません フリーアムスターがスムーズに動作しているとき、メッセージが非常に速く点滅します。freeamasterがフリーズすると、S32k312minEVBから送信されたCANメッセージは停止したようですが、Freemasterからのメッセージは依然として表示され、動作が遅くなっています。 2、合計で20個の変数が少ないですが、その数はdemon fmプロジェクトs32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct"よりもはるかに少ないです。 3.フリーマスター専用のCANインスタンス; おっしゃる通り、私たちのBSWはRTDを使ってCANを使ったFMを実装し、DEMON s32k3xx_fm_over_can_s32ct MCALドライバーのflexcan_43とflexcan_ipwレイヤーを統合しています。しかし、上記の問題にはまだ取り組んでいます。 ちなみに、CANのIP層制限により、私たちのCANドライバは標準のmsg IDを受け入れることができるので、freeamsterの設定設定:標準送信、受信拡張。 添付ファイルに、あなたに近いと思われる4つのファイルがありますのでご確認ください。 すべてのCAN IP設定ファイルが必要ですか?実際、43/ipw はすべて demon s32k3xx_fm_over_can_s32ct と同じように構成されます。 直接メールで連絡することもできます。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode こんにちは、 @millerhughes さん。 残念ながらこのThreadには添付ファイルは見つかりませんでしたが、MBDTから入手したファイルでは、確かに私たちのチームの実装とは異なっていました。 MBDTの実装を私たちのバージョン(添付ファイル参照 - freemaster_s32k3xx_can.c とfreemaster_s32k3xx_can.hに対応しています)に置き換えてみてはどうでしょうか。 私が気づいた一つの矛盾点は、CAN割り込みハンドラのシグネチャです: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); 対 void FMSTR_CanIsr(void); CANの詳細(バッファIDなど)がfreemaster_cfg.hで定義されていると仮定しますハンドラー内でそれらは必要ありません。当社もRTD(低ハードウェア層)を使用しており、お客様の設定を変更する必要はありません。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode ファイルのアップロードリクエストに失敗しました。このThreadにファイルをアップロードする方法 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode ただし、CAN readバッファをリセットする関数を探す助けを求めてください。 また、MBD CANドライバーコードCan_43_FLEXCAN_Ipw.cに変更が加わったのではないかと疑っています MBD MCAL CANドライバーをRTD非MCALドライバーに統合すると、機能Can_43_FLEXCAN_Ipw_ProcessRxMesgBufferが強制的にMEMCPYに転送されます。 手動転送がなければ、RTD非MCALのCANドライバーを使うCan_43_FLEXCAN_Ipw_ProcessRxMesgBufferすべてのCAN情報を読み取れません。 オリジナルのMBD DEMON s32k3xx_fm_over_can_s32ct手動転送は不要です。なぜなら、demonはMCAL CAN 43ドライバを使用しているからです。 Freemasterの問題を引き起こす場合、関数Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer()での手動転送を回避する方法はありますか? あるいは、あなたが知っている何らかの機能を使ってバッファを手動でリセットすることもできますか? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig、 const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig、 uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig-> Can_u8ControllerID ][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode フィードバック:RTD版Freemasterドライバーコードの提供ありがとうございます。 MBDのバージョン機能はFMSTR_CanIsr(*,*,*..*)はMCALドライバ freemaster_s32k3xx_canで、RTDドライバ freemaster_can_flexcanではFMSTR_CanIsr()によって使われています。 統合と実行時に、Freemasterがs32k312MINEVBとの接続に失敗しました。 フリーマスターがフリーズしたときにデバッグを始めました。S32K312N=MINEVBがメッセージを送信失敗したとき、SWが「読み取れる」状態になり、これが未完了のCAN読み取りを引き起こし、間接的には送信遅延が無制限になることがわかりました。 バッファがいっぱいになった場合にリセットするなど、読み取り用のバッファを手動でクリアする機能はありますか?
記事全体を表示
MC_RGM DES/FESレジスタを使用しないコールド/ウォーム電源投入検出 SCB FS26搭載のS32K312ソフトを使っていて、コールド/ウォームの電源アップを検知するはずです。ハードウェアレイアウトのため、DES /FESレジスタは使用できません。したがって、スタンバイRAMにはメモリマッピング変数が使用され、ウォームパワーアップの場合はマジックナンバー、コールドパワーアップの場合は未定義の値が含まれる。マジックナンバーを保持するため、このメモリ領域は起動時に初期化されません(初期化すると情報が失われるため)。しかし、この変数の読み取りアクセスはハードフォールを引き起こします。 DES/FESが使えない場合、nxpの公式なコールド/ホットパワーアップ検出方法は何ですか? ハードフォルトが発生した場合、初期化されていない変数を読み取る関数に安全に戻り、コードの実行を継続するには、どのような処理が必要でしょうか? Re: Cold/warm PowerUp Detection without MC_RGM DES/FES registers こんにちは、 DES/FESが使えない場合、nxpの公式なコールド/ホットパワーアップ検出方法は何ですか? 公式な方法は常にDES/FESです。これらが分析に利用できない状況は想像できません。 なぜDES/FESが使えないのか説明してもらえますか?レジスタはアクセス不能ですか?アプリケーションが読み取る前にクリアされているのか、それともリセットソースとは別のものを特定しようとしているのですか? よろしくお願いいたします。 ピーター Re: Cold/warm PowerUp Detection without MC_RGM DES/FES registers こんにちは、ピーターさん。お返事ありがとうございます。 MCUの機能リセットはRSTB信号を主張し、それがMCU外の回路をトリガーします。すると回路はリセット状態をより長い時間保持する。残念ながら、これは破壊的なリセットを引き起こし、DES=1となります。だからDES/FESは使えません。 よろしくお願いします、 クリストファー
記事全体を表示
单独设置 CONFIG_FIT_CIPHER=y 会导致 hab_status 您好,客服人员, 单独设置 CONFIG_FIT_CIPHER=y 会导致 i.MX8M Plus EVK (开放模式) 上的 hab_status 报告 HAB_INV_SIGNATURE/HAB_INV_ASSERTION。 板:i.MX8MP LPDDR4 EVK,开放/未熔断(HAB 配置:0xf0,HAB 状态:0x66) U-Boot:2024.04 (lf_v2024.04_6.6.52_2.2.x),NXP 分支 HAB 签名:其他方面均正常工作 — CST 签名 imx-启动(SPL CSF + FIT CSF),自定义版本时任务,用于验证嵌入偏移量处的 CSF 标签字节,并在任何不匹配时使版本失败(始终通过) 我有一个干净的基线,在这个板上,hab_status 报告“未找到 HAB 事件!”,使用的是我正常的 HAB 签名 imx-启动。我最近添加了内核 FIT 镜像签名 + AES-256 加密(与 HAB 不同的机制——U-Boot 自身的 bootm 验证/解密已签名的内核 FIT,密钥嵌入在 u-boot.dtb 中,与SRK熔丝无关)。启用此功能后,hab_status 每次启动都会报告 4 个事件: HAB配置:0xf0,HAB状态:0x66 HAB 事件 1:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HAB 事件 2:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HAB 事件 3:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HAB 事件 4:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY 我采用逐个变量进行单独重建+重新刷写测试的方法,有条不紊地排查了这个问题,并在真实硬件上进行了验证: 1. 基线(现有 HAB 签名 imx-boot,无 kernel-FIT 工作):0 个事件 2. 已启用完整的内核 FIT 功能(FIT 公钥/AES 密钥 DTB 嵌入 + 我自己的 cmd/bootm.c)。补丁 + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000): 4 个事件 3. 仅禁用 FIT 公钥/AES 密钥 DTB 嵌入:事件仍然存在,且相同 4. 还删除了我的 cmd/bootm.c 文件。补丁:事件仍然存在,完全相同 5. 完全移除 CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000(真正的内核 FIT 基线):0 个事件,干净 6. 仅重新添加了 CONFIG_SYS_BOOTM_LEN=0x8000000(未添加 CONFIG_FIT_CIPHER):0 个事件,干净 问题仅限于 CONFIG_FIT_CIPHER=y 的情况,其他任何因素都无效(我的 bootm.c 文件)。patch、FIT 公钥/AES 密钥 DTB 嵌入、CONFIG_SYS_BOOTM_LEN)单独或组合都很重要;只有 CONFIG_FIT_CIPHER=y 会将 hab_status 从 0 个事件翻转为这 4 个事件。 我仔细检查过,我自己的 CSF 计算没有问题:我的版本时签名任务会在签名后立即验证两个嵌入偏移处的 CSF 标签字节,如果存在任何不匹配,版本就会失败——无论是否使用 CONFIG_FIT_CIPHER,每个版本都能顺利通过,并且计算出的 SLD hab 块地址/FIT CSF 偏移量在所有测试版本中都是字节相同的,与此配置无关。 我最好的猜测是 CAAM 作业环争用——CONFIG_FIT_CIPHER 引入了 CONFIG_AES(在这个 U-Boot 版本上不需要单独的后端符号),并且该 SoC 的运行时 dmesg 证实 CAAM 确实在其他地方用于 AES/安全散列算法\(SHA\)。我找到的最相关的文档是 doc/imx/habv4/guides/mx8m_secure_boot.txt 的有关 HAB v4.4.0 之前的版本在封闭配置中锁定作业环/DECO 主 ID 寄存器的说明,但这并没有直接描述这种开放模式、CONFIG_FIT_CIPHER 特有的情况。 问题: 1.这是 i.MX8M Plus 上 CONFIG_FIT_CIPHER 和 HABv4 CSF 认证之间已知的交互吗?是 CAAM 资源相关问题,还是其他问题(例如,编译后的二进制文件大小/布局以某种方式移动了 FIT CSF 元器件边界,而我自己的自检无法发现这个问题,因为它验证的是我计算的偏移量,而不是 ROM 独立推导出的偏移量)? 2. CONFIG_FIT_CIPHER 是否能够安全地与此 SoC 上的 HABv4 CSF 签名结合使用,或者这是一个真正的限制? 3. 如果这是根本原因,是否有任何关于正确的 CAAM 作业环分配/解锁顺序的指示? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status 将此问题标记为已解决,以防其他人需要进行二分查找——感谢 [ https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/mp/2344924/highlight/true#M244756 ] 提供的真正修复方法,我找到后立即应用了该方法。 症状:使用我们正常的 HAB 签名 imx-启动 进行清洁基线(hab_status 报告“未发现 HAB 事件!”)。启用 CONFIG_FIT_CIPHER=y 后(为了支持 U-Boot 解密 AES-256 加密的内核 FIT 映像——一种与 HAB 不同的机制,与 SRK 熔丝无关),hab_status 开始在每次启动时报告 4 个事件:2× HAB_INV_ASSERTION,2× HAB_INV_SIGNATURE。 二分法:逐一隔离我们修改过的每个变量,每次都在真实硬件上执行重建+刷新+hab_status操作——最终只隔离了CONFIG_FIT_CIPHER=y(禁用FIT公钥/AES密钥DTB嵌入,并移除一个无关的cmd/bootm.c文件)。打补丁、保留/删除 CONFIG_SYS_BOOTM_LEN — 这些都不重要;只有 CONFIG_FIT_CIPHER 重要)。 根本原因 + 修复:我们通过自定义 Yocto 任务版本化 imx-启动,该任务移植了手动 HAB 签名工作流程(解析 SPL IVT,通过 print_fit_hab.sh 计算 FIT 元器件块,(使用 CST 签名)进入自动版本步骤。该任务假设 mkimage_imx8 自身版本留在版本暂存目录中的 DTB 副本已经正确地进行了 16 字节对齐——但这并不能保证每个配置都是如此。CONFIG_FIT_CIPHER 会改变 U-启动 本身的编译 DTB 大小,在我们的例子中,导致其大小不对齐。未对齐的 DTB 会悄悄地移动 print_fit_hab.sh 计算的每个后续 FIT 元器件边界,因此 CST 会对错误的字节范围进行签名。我们自己的版本时自检(在我们计算出的偏移量处是否存在 CSF 标签字节)每次都顺利通过——它并没有检查 ROM 独立正确的边界概念。只有真正的硬件才能捕获它。 修复方法与另一个帖子中的方法类似:在计算 FIT 元器件块之前,立即在 DTB 上显式运行 pad_image.sh(imx-mkimage 自己的脚本),而不是信任暂存目录的现有状态。已确认确实填充了数据(不是空操作),并且启用完整功能后,hab_status 再次变为干净状态。
記事全体を表示
i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hardware: - i.MX8MQ (REV A0), custom board based on EVK design - QSPI NOR: Micron MT25QL256A (32MB, 3.3V, Quad connected) - BSP: Yocto Scarthgap, NXP BSP, U-Boot 2024.04 (u-boot-imx) Goal: Boot the bootloader (SPL + ATF + U-Boot) from FlexSPI NOR flash. Kernel and rootfs remain on eMMC. What works: - U-Boot (loaded to RAM via uuu SDP/SDPV) runs fine - "sf probe" detects the flash correctly: mt25ql256a, 32 MiB - U-Boot can read and write the flash reliably (verified with read-back tests after "sf protect unlock") - Image is built with IMXBOOT_TARGETS = "flash_evk_flexspi" Flash layout (verified by reading back from the chip): 0x000000: FCFB header - "qspihdr check" reports "Found boot config header in Q(F)SPI" tag = 42464346, version = 56010000 0x001000: IVT - d1 00 20 41, entry = 0x007E1000, boot_data = 0x007E0FE0, self = 0x007E0FC0 0x060000: U-Boot proper FIT (d00dfeed), matches CONFIG_SYS_SPI_U_BOOT_OFFS=0x60000 Problem: With boot switches set to QSPI/FlexSPI boot and the USB cable physically disconnected, the board does not boot. Nothing is printed on the serial console (SPL banner never appears), and the ROM falls back to serial download mode: uuu -lsusb 2:1 MX8MQ SDP: 0x1FC9 0x012B NXP FLASH BT_FUSE_SEL is not blown; boot configuration is done via GPIO boot pins. What I have already tried: - Both header formats: scripts/qspi_header (c0ffee01 tag) and scripts/fspi_header (FCFB tag). Fixed soc.mak so that flash_evk_flexspi uses fspi_header with offset 0. - Varying FCFB parameters: sflashA1Size, serialClkFreq (50MHz -> 20MHz), dataSetupTime/dataHoldTime, sflashPadType - "uuu -b qspi" (the official built-in script) - "qspihdr update safe" and "qspihdr init safe" - Erasing the flash completely vs. writing the full image: boot behaviour is essentially identical (SDP appears after ~1.6s vs ~1.8s), which suggests the ROM may not be reading the flash at all. Questions: 1. Does the i.MX8MQ Boot ROM support booting from serial NOR flash over FlexSPI at all? The Reference Manual section I have lists NAND flash and SD/MMC as boot devices, but I could not find FlexSPI/QSPI NOR listed. i.MX8MM/8MN documentation seems to describe it, but I am unsure about 8MQ. 2. If it is supported, what is the exact expected flash layout? Should the IVT be at offset 0x400 or 0x1000 when an FCFB is present at 0x0? 3. What is the correct BOOT_MODE / BOOT_CFG combination to select FlexSPI NOR boot on i.MX8MQ? 4. Are there any known errata for REV A0 silicon regarding FlexSPI boot? Thank you.
記事全体を表示
i.MX 8M Plus LPDDR4 EVK - eMMC boot0/boot1 の有効化 ボード:i.MX 8M Plus LPDDR4 EVK(MIMX8ML8DVNLZAA年)、IMX8MPEVKHUG rev 0 HAB:融合オープン(SRKは意図的に燃焼せず、まだ評価中) 私はRAUCベースのA/B更新システム向けにブートローダーと更新の冗長性を実装しており、eMMCのハードウェアboot0/boot1パーティション(BOOT_PARTITION_ENABLE)を多くのi.MX8M設計のように使いたいと考えています。つまり、新しいブートローダーを非アクティブなブートパーティションに書き込み、どちらがアクティブかを反転させ、新たにアクティブなブートローダーが故障した場合はROMがもう一方にフォールバックする形です。私は特に、このためにBOOT_CFG/efuseを焼却することを避けたいのです。 EVK上で、poky/oe-core mmc-utilsレシピからビルドしたmmc-utilsを使用して観察した結果は以下のとおりです。 - mmc extcsd read /dev/mmcblk2 は PARTITION_CONFIG を報告し、BOOT_PARTITION_ENABLE は既に boot0 (値 0x08) に設定されています。 - boot0 (/dev/mmcblk2boot0) には有効なイメージ (オフセット 0 に正しい IVT タグ) が含まれていますが、現在デプロイされているブートローダーと一致しません。 - boot1 (/dev/mmcblk2boot1) は完全に空です (すべてゼロ)。 - バイト単位の正確な比較により、ボードは実際には標準の32 KiBオフセットで生のeMMCユーザーエリアから起動していることが確認できます(コンテンツは現在デプロイしているimx-bootと完全に一致します)。boot0から起動しているわけではありません。boot0が有効であることを示すPARTITION_CONFIGもあります。 このボードでは、EXT_CSDのBOOT_PARTITION_ENABLEはROMの実際のブートソースに影響を与えていないようです。IMX8MPEVKHUG 2.2節によると、EVKのSW4スイッチは粗いブートデバイスクラス(eMMC、SD、QSPI、NAND、ヒューズ、USBシリアルダウンロード)のみを選択し、eMMCブートパーティションサブモードのスイッチ位置は存在しません。 質問: 1. LPDDR4 EVK上で「eMMC boot0/boot1ハードウェアパーティションからのROMブート」を特に選択する方法は、BT_FUSE_SEL=1設定やBOOT_CFGエフューズの焼却なしに選択できるサポート方法はありますか?例えば、ジャンパー、抵抗オプション、またはrev 0に記載されていない代替のSW4/SW1101の組み合わせなどIMX8MPEVKHUG?それとも、このボードのPCBにハードストラップされていて、状態に関係なく常にeMMCユーザーエリアから起動するようにEXT_CSD? 2. BOOT_CFG efuseがeMMCブートパーティションモードを有効にする唯一の方法である場合、これを制御するBOOT_CFGヒューズバンクは、HABに使用されるSRKハッシュヒューズとは独立していますか?ヒューズを介してeMMCブートパーティションの冗長性を有効にすると、同時にHAB(SRK書き込み)を終了する必要が生じるのか、それともこれらは別々の決定事項なのかを理解したい。 3. i.MX 8M PlusとeMMCを使ったカスタムボード設計(EVKではありません)の場合、eMMCのboot0/boot1冗長性を最初の起動時から利用可能にする推奨方法は何でしょうか?つまり、BOOT_CFG GPIOのストラップやPCB設計において、後でヒューズのコミットメントを必要としないよう、初日の選択肢として何が真であるべきか? また、eMMCブートパーティション選択のBOOT_CFGビット定義(IMX8MPEVKHUGで既に扱われているSW4デバイスクラスビット以外)を扱ったリファレンスマニュアルのセクションへの指し印も教えていただけると助かります。 ご回答をお待ちしています。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 i.Mx8 UMに関する参考までに、第5章の第5.8.2.2.1章「高レベルeMMCブートフロー」 SCU ROMは4つのeMMCブートシナリオをサポートします: 1.このシナリオでは、「eMMC高速ブート」ヒューズが切れています。一次および二次 イメージコンテナセットは両方ともブートパーティション内にあり、BOOT_PARTITION_ENABLE = 1 または 2 です。 2. このシナリオでは、「eMMC 高速ブート」ヒューズが切れています。小学校と中学校 イメージコンテナセットはどちらもユーザーエリアにあり、BOOT_PARTITION_ENABLE=7です。 3.このシナリオでは、「eMMC高速ブート」ヒューズは切れません。起動モードはノーマルです Bootとプライマリおよびセカンダリイメージコンテナセットはどちらもユーザーエリアにあります。 4. この場合、「eMMCファストブート」ヒューズは 切れていません。起動モードは通常です ブート、プライマリおよびセカンダリイメージコンテナセットは両方ともブート内にあります パーティション、および BOOT_PARTITION_ENABLE = 1 または 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 アドバイスありがとうございます。ただ、第5.8.2.2.1章で別のチップファミリが説明されていると思います。「SCU ROM」eMMCブートフローは、専用のシステムコントローラユニット(Cortex-M4ブートサブシステム)を持つi.MX8QuadMax/QuadXPlus/DualXPlus専用です。i.MX8M PlusにはSCUがなく、起動ROMはCortex-A53上で直接動作するため、その章の BOOT_PARTITION_ENABLE=1/2/7 シナリオはここでは当てはまりません。 i.MX8M Plusの場合、冗長性はi.MX8M Plusリファレンスマニュアル(図6-1)のプライマリ/セカンダリイメージ機構で処理されているようです。ROMはBT_FUSE_SEL/BOOT_CFGで選択したデバイスから起動し、故障時には同じブートデバイス上でIMG_CNTN_SET1_OFFSETヒューズオフセットのセカンダリイメージにフォールバックします。 別々のboot0/boot1パーティションではありません。これはLPDDR4 EVKで見ているものと一致します。BOOT_PARTITION_ENABLE=1はEXT_CSDに設定されていますが、ROMはそれを無視し、生のユーザーエリアのオフセットから起動します。 そこで、私の質問はi.MX8M Plusに限定されました: 1. LPDDR4のEVK(ジャンパー、抵抗、または非公式のSW1101/SW4位置)でeMMC boot0/boot1をブートソースとして選択する方法はありますか?それとも純粋にストラップやBT_FUSE_SELの判断BOOT_CFGに過ぎませんか? 2. BOOT_CFGヒューズバンクはHABのSRKハッシュヒューズとは独立しているのか、それともBOOT_CFGヒューズ経由のコミットもHABのクロージングを強制するのか? 3.カスタムボード設計の場合、レイアウト時にハードウェアのブートパーティション冗長性を後でヒューズに縛り付けずに維持するために、どのようなBOOT_CFGものが必要ですか? もし私が第5.8.2.2.1章のどの部分に適用されるのかを誤解しているようでしたら、ご指摘いただければ幸いです。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Boot CFGとSRKハッシュ間のヒューズビットは分離可能です。SRKハッシュが書き込まれた場合、ブートイメージのハッシュ値と書き込まれたヒューズビットの値を比較するという追加のブート手順が必要になるようです。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 情報ありがとうございます。 8M Mini LPDDR4 EVKBボードハードウェアユーザーガイドIMX8MMEVKBHUG i.MX、ブートモードやブートデバイス構成の章などに役立つ情報はありますか? Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 以下を参照してください。 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-secondary-boot-collection/ta-p/1916915 i.MX8MP eMMC セカンダリブート.zip これらのデモや記事では、より高度なセカンダリブートのシナリオを取り上げていますが、ブートローダーをブート1またはブート2に書き込む方法や、ブート1またはブート2を有効にする方法といった基本事項も含まれています。これらはまさにあなたが必要としている情報でしょう。 i.MX8MP_emmc_boot_part_secondary_boot.uuu FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} ${part} 0 ブート1 FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 ブート2 FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 2 0 i.MX8MP_emmc_boot_part_secondary_boot.uuu uuu_version 1.2.39 SDPS: boot -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 SDPV: delay 1000 SDPV: write -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 -skipspl SDPV: jump #FB: ucmd setenv emmc_dev 1 FB: ucmd setenv part 1 FB: ucmd setenv boot_offset 0x0 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd if test ${part} != 7; then mmc dev ${emmc_dev} ${part}; else mmc dev ${emmc_dev}; fi FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v5.15.71-2.2.0 #FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 FB: ucmd echo ${fastboot_bytes} FB: ucmd setexpr blks ${fastboot_bytes} / 0x200; setexpr blks ${blks} + 1 FB: ucmd mmc write ${loadaddr} ${boot_offset} ${blks} # Secondary boot FB: ucmd setenv part 2 FB: ucmd if test ${part} != 7; then mmc dev ${emmc_dev} ${part}; else mmc dev ${emmc_dev}; fi #FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v5.15.71-2.2.0 FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 FB: ucmd echo ${fastboot_bytes} FB: ucmd setexpr blks ${fastboot_bytes} / 0x200; setexpr blks ${blks} + 1 FB: ucmd mmc write ${loadaddr} ${boot_offset} ${blks} FB: ucmd setenv part 1 FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} ${part} 0 FB: done
記事全体を表示
i.MX 8M Plus LPDDR4 EVK - 启用 eMMC boot0/boot1 主板:i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB:熔断 OPEN(SRK 未烧毁,故意,仍在评估中) 我正在为基于 RAUC 的 A/B 更新系统实现启动加载程序更新冗余,并希望像许多 i.MX8M 设计那样使用 eMMC 的硬件 启动0/启动1 分区(BOOT_PARTITION_ENABLE)——将新的启动加载程序写入非活动启动分区,切换哪个分区处于活动状态,并依靠 ROM 在新激活的分区发生故障时回退到另一个分区。我特别想避免为此烧毁任何 BOOT_CFG/efuse。 我在 EVK 上使用基于 poky/oe-core mmc-utils 配方构建的 mmc-utils 时观察到以下情况: - mmc extcsd 读取 /dev/mmcblk2 报告 PARTITION_CONFIG 中 BOOT_PARTITION_ENABLE 已设置为 boot0(值为 0x08)。 - boot0 (/dev/mmcblk2boot0) 包含一个看起来有效的映像(偏移量 0 处有正确的 IVT 标签),但它与我当前部署的引导加载程序不匹配。 - boot1 (/dev/mmcblk2boot1) 完全为空(全部为零)。 - 逐字节比较证实,该板实际上是从标准的 32 KiB 偏移处的原始 eMMC 用户区启动(内容与我当前部署的 imx-boot 完全匹配)——而不是从 boot0 启动,尽管 PARTITION_CONFIG 指示 boot0 已启用。 因此,在这个板上,EXT_CSD 的 BOOT_PARTITION_ENABLE 似乎对 ROM 的实际启动源没有影响。根据 IMX8MPEVKHUG 第 2.2 节,EVK 的 SW4 开关仅用于选择粗略的启动设备类别(eMMC vs SD vs QSPI vs NAND vs 熔丝 vs USB 串行下载)——没有用于 eMMC 启动分区子模式的开关位置。 问题: 1. 在LPDDR4 EVK上,是否有支持的方法可以选择“ROM从eMMC boot0/boot1硬件分区启动”,而无需设置BT_FUSE_SEL=1或烧录BOOT_CFG熔丝?例如,是否可以通过跳线、电阻或IMX8MPEVKHUG rev 0中未记录的SW4/SW1101组合来实现?或者,该板的PCB是否已硬性规定始终从eMMC用户区启动,而不管EXT_CSD状态如何? 2. 如果 BOOT_CFG 熔丝是启用 eMMC 启动分区模式的唯一方法:控制此模式的 BOOT_CFG 熔丝组是否独立于用于 HAB 的 SRK 哈希熔丝?我想了解通过熔丝启用 eMMC 启动分区冗余是否会迫使我同时关闭 HAB(SRK 烧录),或者这些是否是可分离的决定。 3. 对于使用 i.MX 8M Plus 和 eMMC 的定制板设计(非 EVK),推荐的方法是如何在首次启动时就使 eMMC boot0/boot1 冗余可用?也就是说,BOOT_CFG GPIO 跳线/PCB 设计中需要满足哪些条件,才能使其成为第一天就能使用的功能,而不是需要稍后进行熔丝位绑定? 如果能提供一些关于 eMMC 启动分区选择的 BOOT_CFG 位定义的具体参考手册章节的链接(除了 IMX8MPEVKHUG 中已经涵盖的 SW4 设备类位之外),我们将不胜感激。 谢谢! Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 供参考,请参阅 i.Mx8 UM 第 5.8.2.2.1 节“高级 eMMC 启动流程”。 SCU ROM 支持 4 种 eMMC 启动方案: 1.在这种情况下,“eMMC 快速启动”熔丝被烧断。小学和中学 镜像容器集均位于启动分区中,且 BOOT_PARTITION_ENABLE = 1 或 2。 2. 在这种情况下,“eMMC 快速启动”熔丝烧断了。小学和中学 镜像容器集均位于用户区域,且 BOOT_PARTITION_ENABLE =7。 3.在这种情况下,“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动、主镜像容器集和辅助镜像容器集都在用户区域。 4. 在这种情况下,“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动时,主镜像容器集和辅助镜像容器集都在启动过程中。 分区,并且 BOOT_PARTITION_ENABLE = 1 或 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 谢谢你的指点——不过我认为第 5.8.2.2.1 章描述的是不同的芯片系列。“SCU ROM” eMMC 启动流程是 i.MX8QuadMax/QuadXPlus/DualXPlus 特有的,它们具有专用的系统控制器单元(独立的 Cortex-M4 启动子系统)。i.MX8M Plus 没有 SCU – 其启动 ROM 直接在 Cortex-A53 上运行 – 因此该章节中的 BOOT_PARTITION_ENABLE=1/2/7 场景不适用于这里。 对于 i.MX8M Plus,冗余似乎是通过 i.MX8M Plus 参考手册中的主/辅助映像机制来处理的(图 6-1):ROM 从 BT_FUSE_SEL/BOOT_CFG 选择的设备启动,如果失败,则回退到 IMG_CNTN_SET1_OFFSET 熔丝偏移处的辅助映像——在同一引导设备上,而不是单独的 boot0/boot1 分区。这与我在 LPDDR4 EVK 上看到的情况一致:EXT_CSD 中设置了 BOOT_PARTITION_ENABLE=1,但 ROM 忽略了它,仍然从原始用户区偏移量启动。 所以我的问题仍然是,仅限于 i.MX8M Plus: 1. 在 LPDDR4 EVK 上,是否有任何非熔丝方法(跳线、电阻或未记录的 SW1101/SW4 位置)来选择 eMMC boot0/boot1 作为启动源,还是这完全取决于 BOOT_CFG 跳线/BT_FUSE_SEL 的决定? 2. BOOT_CFG 熔丝组是否独立于 HAB 的 SRK 哈希熔丝,或者通过熔丝提交 BOOT_CFG 是否也会强制关闭 HAB? 3.对于定制板设计,在布局时需要进行哪些 BOOT_CFG 绑定才能在不进行后续熔丝分配的情况下保持硬件启动分区冗余? 如果我误解了第 5.8.2.2.1 章实际适用的部分,请指正。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 启动 CFG 和 SRK Hash 之间的熔丝位是可分离的。如果 SRK 哈希值被烧录,则似乎需要额外的启动步骤,即比较启动映像和烧录的熔丝位的哈希值。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 谢谢你提供的信息。 IMX8MMEVKBHUG i.MX 8M Mini LPDDR4 EVKB 板硬件用户指南是否提供了任何有用的信息,例如启动模式和引导设备配置章节? Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 您可以参考 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-secondary-boot-collection/ta-p/1916915 i.MX8MP eMMC 辅助启动.zip 这些演示和文章涵盖了更高级的辅助启动场景,但也包括一些基础知识,例如如何将引导加载程序写入启动 1 或启动 2,以及如何启用启动 1 或启动 2。这些内容应该正是您所需要的。 i.MX8MP_emmc_boot_part_secondary_boot.uuu FB:ucmd mmc partconf ${emmc_dev} ${emmc_ack} ${part} 0 启动 1 FB:ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 启动 2 FB:ucmd mmc partconf ${emmc_dev} ${emmc_ack} 2 0 i.MX8MP_emmc_boot_part_secondary_boot.uuu uuu_version 1.2.39 SDPS: boot -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 SDPV: delay 1000 SDPV: write -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 -skipspl SDPV: jump #FB: ucmd setenv emmc_dev 1 FB: ucmd setenv part 1 FB: ucmd setenv boot_offset 0x0 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd if test ${part} != 7; then mmc dev ${emmc_dev} ${part}; else mmc dev ${emmc_dev}; fi FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v5.15.71-2.2.0 #FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 FB: ucmd echo ${fastboot_bytes} FB: ucmd setexpr blks ${fastboot_bytes} / 0x200; setexpr blks ${blks} + 1 FB: ucmd mmc write ${loadaddr} ${boot_offset} ${blks} # Secondary boot FB: ucmd setenv part 2 FB: ucmd if test ${part} != 7; then mmc dev ${emmc_dev} ${part}; else mmc dev ${emmc_dev}; fi #FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v5.15.71-2.2.0 FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 FB: ucmd echo ${fastboot_bytes} FB: ucmd setexpr blks ${fastboot_bytes} / 0x200; setexpr blks ${blks} + 1 FB: ucmd mmc write ${loadaddr} ${boot_offset} ${blks} FB: ucmd setenv part 1 FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} ${part} 0 FB: done
記事全体を表示
Kinetis MCX Wxx(MCX W71/72 および MCX W23)IIoT用パワープロファイルツール このページは、Kinetis MCX Wx(MCX W71/72およびMCX W23)のPower Profile Tools for IIoTに特化しています。 これにより、あなたのアプリケーション(オートモーティブ、IIoT、トラッカー/タグ、連続血糖モニタリング[CGM])の消費電力を推定し、ソリューションのバッテリー寿命を評価するのに役立ちます。 このページには、以下の用途に特化した4つの電源プロファイルツールが含まれています。 Bluetooth LEは単体でMCX W71/MCX W72製品用です。 MCX W23製品のBluetooth LEをスタンドアロンで提供します。 802.15.4 マター ICD SIT & LIT および ZED(単独で MCX W71 および W72 製品用)。 Aliroドアロックアプリケーション(BLE MCX W72/UWB/NFC/モーター) 1. MCX W71 / MCX W72 Bluetooth LEの電力プロファイリング: AN14389 MCX W71 Bluetooth LE 消費電力分析 AN14739 MCX W72 Bluetooth LE 電力プロファイル分析.pdf 2. MCX W23 Bluetooth LEの電力プロファイリング AN14659:MCX W23 Bluetooth Low Energy Power Consumption Analysis |NXP Semiconductors 3. 802.15.4 マター ICD SIT & LIT および ZED MCX W71/W72 パワープロファイリング AN14841 MCX W72 802.15.4 マターおよびZigBee電源プロファイルanalysis.pdf 4. ドアロックの適用(BLE/UWB/NFC/モーター)
記事全体を表示
i.MX8MQ: Boot ROMはFlexSPI/QSPI NOR FLASHからの起動をサポートしていますか? ハードウェア: - i.MX8MQ(REV A0)、EVKデザインに基づくカスタムボード - QSPI NOR:マイクロンMT25QL256A(32MB、3.3V、クアッドコネクテッド) - BSP: Yocto Scarthgap、NXP BSP、U-BOOT 2024.04(u-BOOT-IMX) 目標:FlexSPI NORフラッシュからブートローダー(SPL + ATF + U-Boot)を起動する。 カーネルとルートファイルシステムはeMMC上に残ります。 効果的な点: - U-Boot(uuu SDP/SDPV経由でRAMにロード)は問題なく動作します - 「SFプローブ」がフラッシュを正しく検出します:MT25QL256A、32 MiB - U-Bootはフラッシュの読み書きが安定してできる(検証 「SF Protect Unlock」後の読み返しテスト) - 画像はIMXBOOT_TARGETS = 「flash_evk_flexspi」で構築されます フラッシュメモリのレイアウト(チップからの読み出しで検証済み): 0x000000: FCFB ヘッダー - 「qspihdr check」レポート 「Q(F)SPIにブート構成ヘッダーが見つかりました」 タグ = 42464346、バージョン = 56010000 0x001000: IVT - d1 00 20 41、エントリ = 0x007E1000、 boot_data = 0x007E0FE0、self = 0x007E0FC0 0x060000: U-Boot の適切な FIT (d00dfeed) が一致します CONFIG_SYS_SPI_U_BOOT_OFFS=0x60000 問題点: ブートスイッチをQSPI/FlexSPIに設定し、USBケーブルで起動した場合 物理的に切断されたため、ボードは起動しません。何もない シリアルコンソールに印刷され(SPLバナーは表示されません)、 ROMはシリアルダウンロードモードに切り替わります。 uuu -lsusb 2:1 MX8MQ SDP: 0x1FC9 0x012B NXP FLASH BT_FUSE_SELは焼損していません。ブート設定はGPIO経由で行われます。 ブートピン。 私が既に試したこと: - 両方のヘッダー形式: scripts/qspi_header (c0ffee01 タグ) および scripts/fspi_header (FCFBタグ)。soc.mak をSO修正した flash_evk_flexspiオフセット0のfspi_headerを使用します。 - 変動するFCFBパラメータ:sflashA1Size、serialClkFreq(50MHz -> 20MHz)、 dataSetupTime/dataHoldTime, sflashPadType - 「Uuu -B QSPI」(公式組み込みスクリプト) - 「Qspihdr Update Safe」および「Qspihdr init safe」 - フラッシュを完全に消去するのと、完全な画像を書き込むこと: 起動動作は基本的に同一です(SDPはその後に現れます) ~1.6秒対~1.8秒)を比較し、ROMが読み取っていない可能性を示唆しています フラッシュ自体が。 質問: 1.i.MX8MQブートROMはシリアルNORからの起動をサポートしていますか? FlexSPIでフラッシュを使うべきでしょうか?リファレンス・マニュアルのセクションは持っています NANDフラッシュとSD/MMCをブートデバイスとしてリストアップしていますが、できませんでした FlexSPI/QSPI NORのリストは見つかりません。i.MX8MM/8MNのドキュメントのようです 説明は難しいですが、8MQについてはよくわかりません。 2. もし対応しているなら、フラッシュの正確な予想レイアウトはどうなりますか? FCFB の場合、IVT はオフセット 0x400 または 0x1000 にあるべきでしょうか 0x0に存在しますか? 3. 選択すべき正しいBOOT_MODE / BOOT_CFGの組み合わせは何ですか? i.MX8MQでFlexSPI NORブートは可能ですか? 4. REV A0シリコンに関して既知の正誤表はありますか? FlexSPIブート? よろしくお願いします。
記事全体を表示
Cold/warm PowerUp Detection without MC_RGM DES/FES registers I have a S32K312 (with SCB FS26) software, which should detect a cold/warm powerup. Due to HW layouts, the DES /FES registers cannot be used. Therefore, a memory mapped variable in the standby ram is used, which contains a magic number in case of warm powerups and undefined values in case of cold powerups. To preserve the magic number, this memory area isn’t initialized during startup (otherwise the information would be lost). But a read access on this variable leads to a HardFault. What is the official nxp way to detect cold/hot powerups, if DES/FES cannot be used? What needs to be done to handle the hardfault in that way, that there is a safe return to the function, which reads the uninitialized variable, and continue code execution? Re: Cold/warm PowerUp Detection without MC_RGM DES/FES registers Hello, What is the official nxp way to detect cold/hot powerups, if DES/FES cannot be used? Official way is always DES/FES. I cannot imagine the situation where these are not available for analyzes. Can you explain why DES/FES cannot be used? Are the registers inaccessible, cleared before the application can read them, or are you trying to determine something different than the reset source? Best regards, Peter Re: Cold/warm PowerUp Detection without MC_RGM DES/FES registers Hello Peter, thank you for reply. A functional reset of the MCU asserts the RSTB signal, which triggers the circuit outside of the MCU. The circuit then holds the reset for a longer time. Unfortunately this causes a destructive reset and DES=1. That's why DES/FES cannot be used. Best regards, Christopher
記事全体を表示
i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Board: i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB: fused OPEN (SRK not burned, deliberately, still evaluating) I am implementing bootloader-update redundancy for a RAUC-based A/B update system and want to use the eMMC's hardware boot0/boot1 partitions (BOOT_PARTITION_ENABLE) the way many i.MX8M designs do — write the new bootloader to the inactive boot partition, flip which one is active, and rely on the ROM to fall back to the other if the newly-active one fails. I specifically want to avoid burning any BOOT_CFG/efuses for this. What I have observed on the EVK, using mmc-utils built from the poky/oe-core mmc-utils recipe: - mmc extcsd read /dev/mmcblk2 reports PARTITION_CONFIG with BOOT_PARTITION_ENABLE already set to boot0 (value 0x08). - boot0 (/dev/mmcblk2boot0) contains a valid-looking image (correct IVT tag at offset 0), but it does not match my currently deployed bootloader. - boot1 (/dev/mmcblk2boot1) is completely empty (all zero). - A byte-exact comparison confirms the board is actually booting from the raw eMMC user area at the standard 32 KiB offset (content matches my currently deployed imx-boot exactly) — not from boot0, despite PARTITION_CONFIG indicating boot0 is enabled. So on this board, EXT_CSD's BOOT_PARTITION_ENABLE appears to have no effect on the ROM's actual boot source. Per IMX8MPEVKHUG section 2.2, the EVK's SW4 switch only selects the coarse boot device class (eMMC vs SD vs QSPI vs NAND vs fuses vs USB serial download) — there is no switch position for the eMMC boot-partition sub-mode. Questions: 1. Is there a supported way to select "ROM boots from eMMC boot0/boot1 hardware partition" on the LPDDR4 EVK specifically, without setting BT_FUSE_SEL=1 / burning BOOT_CFG efuses — e.g. a jumper, resistor option, or alternate SW4/SW1101 combination not documented in IMX8MPEVKHUG rev 0? Or is this hard-strapped on this board's PCB to always boot from the eMMC user area regardless of EXT_CSD state? 2. If BOOT_CFG efuses are the only way to enable eMMC boot-partition mode: are the BOOT_CFG fuse banks that control this independent of the SRK-hash fuses used for HAB? I want to understand whether enabling eMMC boot-partition redundancy via fuses would force me to also commit to closing HAB (SRK burn) at the same time, or whether these are separable decisions. 3. For a custom board design (not the EVK) using the i.MX 8M Plus with eMMC, what is the recommended way to make eMMC boot0/boot1 redundancy available from first bring-up — i.e., what needs to be true in the BOOT_CFG GPIO strapping / PCB design so this is a day-one option rather than something that requires a later fuse commitment? Any pointers to the specific Reference Manual section covering the BOOT_CFG bit definitions for eMMC boot-partition selection (beyond the SW4 device-class bits already covered in IMX8MPEVKHUG) would also be appreciated. Thank you! Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 FYI for i.Mx8 UM at chapter 5.8.2.2.1 High Level eMMC Boot Flow The SCU ROM supports 4 eMMC boot scenarios: 1. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. 2. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the User Area, and BOOT_PARTITION_ENABLE =7. 3. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the User Area. 4. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Thanks for the pointer — though I believe chapter 5.8.2.2.1 describes a different chip family. The "SCU ROM" eMMC boot flow is specific to the i.MX8QuadMax/QuadXPlus/DualXPlus, which have a dedicated System Controller Unit (separate Cortex-M4 boot subsystem). The i.MX8M Plus has no SCU — its boot ROM runs directly on a Cortex-A53 — so the BOOT_PARTITION_ENABLE=1/2/7 scenarios in that chapter don't apply here. For i.MX8M Plus, redundancy appears to be handled via the Primary/Secondary Image mechanism in the i.MX8M Plus Reference Manual (Figure 6-1): the ROM boots from the device selected by BT_FUSE_SEL/BOOT_CFG, and on failure falls back to a Secondary Image at the IMG_CNTN_SET1_OFFSET fuse offset — on the same boot device, not a separate boot0/boot1 partition. This matches what I'm seeing on the LPDDR4 EVK: BOOT_PARTITION_ENABLE=1 is set in EXT_CSD, but the ROM ignores it and boots from the raw user-area offset regardless. So my questions remain, scoped to i.MX8M Plus: 1. Is there any non-efuse way on the LPDDR4 EVK (jumper, resistor, or undocumented SW1101/SW4 position) to select eMMC boot0/boot1 as the boot source, or is that purely a BOOT_CFG strap/BT_FUSE_SEL decision? 2. Are the BOOT_CFG fuse banks independent of the SRK-hash fuses for HAB, or does committing to BOOT_CFG-via-fuse also force HAB closure? 3. For a custom board design, what BOOT_CFG strapping is needed at layout time to keep hardware boot-partition redundancy available without a later fuse commitment? Happy to be corrected if I'm misreading which part chapter 5.8.2.2.1 actually applies to. Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 The fuses bits between Boot CFG and SRK Hash are separable. It seems there is the extra boot step needed if the SRK Hash burned, which is comparing the hash values from your boot image and fuse bits burned. Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Thanks for your information. Does IMX8MMEVKBHUG i.MX 8M Mini LPDDR4 EVKB Board Hardware User's Guide provide any useful information, Boot mode and Boot device configurations chapter? Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 You can refer to the  https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-secondary-boot-collection/ta-p/1916915 i.MX8MP eMMC Secondary Boot.zip These demos and articles cover more advanced secondary boot scenarios, but they also include the basics—such as how to write the bootloader to Boot 1 or Boot 2, and how to enable Boot 1 or Boot 2. These should be exactly what you need. i.MX8MP_emmc_boot_part_secondary_boot.uuu FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} ${part} 0 boot 1 FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 boot 2 FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 2 0 i.MX8MP_emmc_boot_part_secondary_boot.uuu uuu_version 1.2.39 SDPS: boot -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 SDPV: delay 1000 SDPV: write -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 -skipspl SDPV: jump #FB: ucmd setenv emmc_dev 1 FB: ucmd setenv part 1 FB: ucmd setenv boot_offset 0x0 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd if test ${part} != 7; then mmc dev ${emmc_dev} ${part}; else mmc dev ${emmc_dev}; fi FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v5.15.71-2.2.0 #FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 FB: ucmd echo ${fastboot_bytes} FB: ucmd setexpr blks ${fastboot_bytes} / 0x200; setexpr blks ${blks} + 1 FB: ucmd mmc write ${loadaddr} ${boot_offset} ${blks} # Secondary boot FB: ucmd setenv part 2 FB: ucmd if test ${part} != 7; then mmc dev ${emmc_dev} ${part}; else mmc dev ${emmc_dev}; fi #FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v5.15.71-2.2.0 FB: download -f imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk-LF_v6.6.3-1.0.0 FB: ucmd echo ${fastboot_bytes} FB: ucmd setexpr blks ${fastboot_bytes} / 0x200; setexpr blks ${blks} + 1 FB: ucmd mmc write ${loadaddr} ${boot_offset} ${blks} FB: ucmd setenv part 1 FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} ${part} 0 FB: done
記事全体を表示
无需 MC_RGM DES/FES 寄存器即可检测冷启动/热启动 我有一台 S32K312(配备 SCB FS26 软件),它应该能够检测到冷启动/热启动。由于硬件布局的原因,DES/FES寄存器无法使用。因此,备用内存中使用了一个内存映射变量,该变量在热启动时包含一个魔数,在冷启动时包含未定义的值。为了保留魔数,该内存区域在启动时不会初始化(否则信息将会丢失)。但是,对该变量进行读取操作会导致 HardFault 错误。 如果不能使用 DES/FES,NXP 官方检测冷启动/热启动的方法是什么? 为了处理这种硬故障,需要做些什么才能安全地返回到读取未初始化变量的函数,并继续执行代码? Re: Cold/warm PowerUp Detection without MC_RGM DES/FES registers 你好, 如果不能使用 DES/FES,NXP 官方检测冷启动/热启动的方法是什么? 官方方式始终是 DES/FES。我无法想象在什么情况下这些数据无法用于分析。 你能解释一下为什么不能使用DES/FES吗?寄存器是否无法访问、在应用程序读取之前被清除,或者您尝试确定的是复位源以外的其他内容? 顺祝商祺! Peter Re: Cold/warm PowerUp Detection without MC_RGM DES/FES registers 你好彼得,谢谢你的回复。 MCU 的功能 RESET 会使 RSTB 信号生效,从而向 MCU 外部的电路发送触发信号。电路随后会保持RESET更长时间。不幸的是,这会导致破坏性RESET,DES=1。这就是为什么不能使用DES/FES的原因。 此致, 克里斯托弗
記事全体を表示
SPC5745BFVHM2 我需要哪种型号的芯片? Re: SPC5745BFVHM2 你好, 您能把问题解释得更详细一些吗? 顺祝商祺! Peter Re: SPC5745BFVHM2 微信图片_20260731134000_19_9.jpg 您好,请问这款BGA100芯片的型号是什么?哪款型号可以替代它?我找了很久,但还是找不到原版模型。谢谢你的帮助。(Chip)已添加图表。)
記事全体を表示