Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
IMXRT LPUART non-blocking transfer API makes error handling difficult Hi, I've been looking at the "transfer" API for LPUART, for interrupt-based non-blocking transfers.  It seems to do a decent job of wrapping all the "happy case" handling of LPUART interrupts, etc, and providing a good high level API for just receiving data when it's ready (i.e. handling IDLE, RX ready, TX complete, etc).  However, it makes handling UART errors very difficult.  There is no error handling inside the LPUART_TransferHandleIRQ function, and just after that function in fsl_lpuart.c is a bogus empty LPUART_TransferHandleErrorIRQ containing a comment "To be implemented by the user".  This looks completely half-baked. The only way to actually handle UART errors seems to be to override the default LPUARTx_IRQHandler functions so that instead of calling LPUARTx_RX_DriverIRQHandler (or TX), you'd have to call your own function that handles errors and passes on "happy case" interrupts to the original LPUARTx_RX/TX_DriverIRQHandler so it can call into LPUART_TransferHandleErrorIRQ. In addition you'd have to enable those error interrupts yourself outside the transfer API by calling LPUART_EnableInterrupts, and in your error handling also call LPUART_DisableInterrupts and deal with clearing them, etc. This seems like a lot of extra hassle to handle errors.  Why is this not baked into the transfer API itself? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, Thank you for the detailed feedback. I understand that the SDK could be a little ambiguous since these are intended to provide a common use cases for each peripheral functionality. We are constantly working to improve our APIs thanks also of recommendations like this. Thank you for the recommendations, and we hope that LPUART's error handling will be implemented in future releases. On the other hand, could you please let me know which specific error conditions you are interested in handling and which device you are using? With that information, I can suggest documentation related to those error conditions that may help with your implementation. BR Habib
查看全文
IMXRT LPUARTの非ブロッキング転送APIはエラー処理を困難にする こんにちは、 私は、割り込みベースのノンブロッキング転送を行うためのLPUARTの「転送」APIについて調べています。LPUART割り込みなどの「ハッピーケース」処理をうまくラップし、準備ができたときにだけデータを受信できる良い高水準APIを提供しているようです。アイドル状態、受信準備完了、送信完了などの処理。しかし、これによってUARTエラーの処理が非常に困難になる。 LPUART_TransferHandleIRQ関数内にはエラー処理がなく、fsl_lpuart.cのその関数の直後には「ユーザーによって実装される」というコメントを含む偽の空LPUART_TransferHandleErrorIRQがあります。これは完全に未完成に見える。 UARTエラーを実際に処理する唯一の方法は、デフォルトのLPUARTx_IRQHandler関数を上書きし、LPUARTx_RX_DriverIRQHandler(またはTX)を呼び出す代わりに、自分でエラーを処理し、「ハッピーCASE」割り込みを元のLPUARTx_RX/TX_DriverIRQHandlerに渡してLPUART_TransferHandleErrorIRQに呼び出すようにすることのようです。 さらに、転送APIの外部でLPUART_EnableInterruptsを呼び出してエラー割り込みを自分で有効にし、エラー処理の中でLPUART_DisableInterruptsを呼び出してそれらをクリアするなどの処理を行う必要があります。 エラー処理にこれだけの手間をかけるのは、かなり面倒な作業のように思える。なぜこの機能が転送API自体に組み込まれていないのでしょうか? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 詳細なフィードバックをありがとうございます。SDKは各ペリフェラル機能の共通ユースケースを提供するためのものなので、少し曖昧な部分もあることは理解しています。このようなご意見も参考にしながら、私たちは常にAPIの改善に取り組んでいます。ご提案ありがとうございます。今後のリリースでもLPUARTのエラー処理が実装されることを願っています。 一方で、どのエラー条件を扱いたいのか、どのデバイスを使っているのか教えていただけますか?その情報をもとに、実装に役立つエラー条件に関するドキュメントを提案できます。 BR ハビブ
查看全文
MCXN547:SWD DP IDは読み取れるが、AP0/AP2アクセスはWIRE ACKフォルトを返す こんにちは、NXPサポートの皆さん、 カスタムボード上のMCXN547VKLTと外部のMCU-Linkプローブを使用しています。 デバッグセッションを開始する際にSWD接続が失敗する: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. SWD-DPは正しく検出できます: DPID = 0x6BA02477 しかし、CPU0 AHB-AP(AP0)へのアクセスは以下の場合に失敗します: WIRE ACK FAULT デバッグ用メールボックスのリクエストも失敗します。LinkServer のレポート: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 確認した内容: SWD周波数は1MHzから10kHzまでテスト済み。 SWDIOとSWCLKの波形はオシロスコープ上で良好に見える。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDCおよびI/O電源 = 3.3V RESET_Bは正しく動作します MCU-Linkファームウェア:CMSIS-DAP V3.172 LinkServer バージョン: 26.5.59 同じMCU-LinkはMCXN947開発ボードで動作します MCXN547は新しいチップに交換されたが、問題は解決していない。 USB ISPはVID/PID 1FC9:014Fで正しく動作します。blhostを使えば、以下ができます: 内部フラッシュを消す 内部フラッシュのプログラムと読み取り アプリケーションを正常に実行してください アプリケーションのUSBコンポジットデバイスを列挙します ROMの報告によると、 Security State = UNSECURE USB ISP経由でPFRも読み取りました。 CMPAは完全に消去されました(0xFF) CFPAはROMで生成されたCMACを除いて消去されます。 お客様向けのSOCUやデバッグ認証の設定は存在しません 何かアドバイスをいただけますか: AP0とAP2が利用可能になるには、どのような条件が必要ですか? DM-APステータス0x60F93638は、既知の電源、リセット、またはハードウェア構成の問題に関連していますか? SWDやDebug Mailboxへのアクセスに関する既知のMCXN547エラタはありますか? この症状を確認するには、どの電源信号とリセット信号をチェックすればよいでしょうか? MCX N
查看全文
当“禁用帧超时”未选中时,S32G3 LLCE LIN 主站缺少接收响应 各位NXP专家,大家好! 我目前正在使用 S32G3 上的 LLCE 元器件(作为 LIN 主控运行)进行 LIN 实现。我们正在使用 S32G_LLCE_1_0_10。 我们在 LLCE LIN 固件的帧超时配置方面遇到了奇怪的问题,我想了解一些关于固件黑盒逻辑的内部细节或说明。 问题描述: 配置 LIN 通道时,如果“禁用帧超时”未选中(即启用超时检测),并将响应超时值设置为 14: LLCE LIN 主站成功将报头(中断 + 同步 + PID)发送到总线。 从节点接收到头部信息后,立即返回正确的数据和校验和。 但是,LLCE LIN 主站会随机或持续地无法捕获/接收数据。表现得好像数据被 LLCE 固件丢失或丢弃了一样。 找到解决方法: 如果我们在配置工具中仅勾选“禁用帧超时”(禁用固件的内部超时逻辑),同时保持所有其他硬件和物理总线环境完全相同: 主设备从不丢失任何数据,并成功接收从设备的每一个响应。 我们的问题: 由于 LLCE_firmware_user_guide.pdf 提供的关于内部状态机的信息非常有限,我们对这种行为感到困惑: LLCE固件内部是如何精确计算超时值“14”的?值 14 代表的是绝对微秒、比特时间,还是与特定 GPT/定时器时钟源相关的周期? 为什么即使从设备立即回复,主设备也无法获取响应?超时计数器是否有可能启动过早(例如,在报头传输完成之前),或者由于某些内部硬件/固件执行延迟,“14”作为阈值是否太小? 如果我们想在不丢弃有效响应的情况下保持帧超时保护处于活动状态,那么正确计算和设置此超时值的推荐方法是什么? 任何有关 LLCE LIN 固件内部时序逻辑的文档、应用笔记或见解都将不胜感激。 提前感谢! 此致, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好, @cjq 谢谢你的解释。 1.如果选中“禁用帧超时”框,则 Lin 驱动程序将接受长度超过最大帧长度的帧。 2. 对于“LinResponseTimeout”,重置值为 0Eh = 14,对应于 T_Response_Maximum = 1.4 x T_Response_Nominal。这是 1 字节的响应超时持续时间(以比特时间为单位)。 BR 陈银   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 陈银你好, 感谢您的快速回复。以下是对您问题的解答,以及关于固件版本的更正: 硬件:我们使用的是基于 S32G3 的定制电路板,而不是 NXP 的官方参考电路板。 实现方式:我们没有直接运行官方示例。这是我们自行开发的,但它与 NXP 官方示例代码密切相关,并在此基础上进行了开发。 固件版本更正:我意识到我在最初的帖子中关于版本信息有误。我们实际使用的是S32G_LLCE_1_0_09 ,而不是S32G_LLCE_1_0_10。 请问您能否帮忙检查一下 1.0.09 版本中是否存在与 LIN 响应超时相关的已知错误,或者该特定固件版本是如何解释超时值“14”的? 此致敬礼,cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好, @cjq 感谢分享。 1. 请问您使用的是基于 S32G3 的定制板还是 NXP 的参考板? 2. 该问题是在您的自定义实现中发现的,还是在 NXP 配置的任何示例中发现的? BR 陈银
查看全文
S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi NXP Experts, I am currently working on the LIN implementation using the LLCE component on S32G3 (running as a LIN Master). We are using S32G_LLCE_1_0_10. We have encountered a strange behavior regarding the Frame Timeout configuration in the LLCE LIN firmware, and I would like to seek some internal details or clarifications about the firmware's black-box logic. Problem Description: When configuring the LIN channel with "Disable Frame Timeout" UNCHECKED (meaning timeout detection is enabled) and setting the Response Timeout value to 14: The LLCE LIN Master successfully transmits the Header (Break + Sync + PID) to the bus. The Slave node receives the Header and responds with the correct Data + Checksum immediately. However, the LLCE LIN Master randomly or constantly fails to capture/receive the data. It behaves as if the data is lost or dropped by the LLCE firmware. Workaround Found: If we simply CHECK "Disable Frame Timeout" (disabling the firmware's internal timeout logic) in the configuration tool while keeping all other hardware and physical bus environments exactly the same: The Master never drops any data and successfully receives every single response from the Slave. Our Questions: Since the LLCE_firmware_user_guide.pdf provides very limited information about the internal state machine, we are confused by this behavior: How is the timeout value "14" precisely calculated inside the LLCE firmware? Does a value of 14 represent absolute microseconds, bit times, or cycles related to a specific GPT/timer clock source? Why does the Master fail to grab the response even when the Slave replies immediately? Is it possible that the timeout counter starts too early (e.g., before the Header finishes transmitting), or is "14" too small a threshold due to some internal hardware/firmware execution latency? What is the recommended way to properly calculate and set this timeout value if we do want to keep the Frame Timeout protection active without dropping valid responses? Any documentation, application notes, or insights into the LLCE LIN firmware's internal timing logic would be highly appreciated. Thanks in advance! Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for your clarification. 1. If DisableFrameTimeout box is checked, then Lin driver will accept the frame that is longer than Maximal Frame Length. 2. For "LinResponseTimeout", the reset value is 0Eh = 14, corresponding to T_Response_Maximum = 1.4 x T_Response_Nominal. This is the response timeout duration (in bit time) for 1 byte. BR Chenyin   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi Chenyin, Thank you for your quick response. Here are the clarifications to your questions, along with a correction regarding the firmware version: Hardware: We are using a custom board based on S32G3, not the official NXP reference board. Implementation: We are not running the official example directly. It is our custom implementation, but it is closely referenced and developed based on the official NXP sample code. Correction on Firmware Version: I realized I made a mistake regarding the version in my initial post. We are actually using S32G_LLCE_1_0_09, not S32G_LLCE_1_0_10. Could you please help check if there are any known bugs related to the LIN response timeout in version 1.0.09, or how the timeout value "14" is interpreted by this specific firmware version? Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for the post. 1. May I know if you are working with a S32G3 based custom board or reference board from NXP? 2. Is the issue found in your custom implementation or from any samples provisioned by NXP? BR Chenyin
查看全文
Toolbox workflow 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article provides a high-level overview of the typical workflow for developing an application using the toolbox. It explains how the main development stages fit together, from preparing the environment and selecting the target hardware to configuring the project, generating code, building the application, programming the target, and validating the results. The purpose of this topic is to help users understand the overall process and to guide them toward the related articles that describe each stage in more detail. 3 Overview Workflow Scope The workflow described in this article covers the main steps typically followed when developing an application with the toolbox. After the toolbox and supporting environment are prepared, the user can create a new model or open an existing example, select the target hardware, configure the required software components, prepare the Simulink model, generate code, build the application, program the target device, and debug and validate the behavior on hardware. This article is intended as an overview topic and does not replace the more detailed setup, modeling, and debugging documentation. Target Audience This article is intended for users who want to understand the overall development flow supported by the toolbox. It is useful both for new users who start from supported examples and evaluation boards and for advanced users who need to adapt the workflow to a custom target or project configuration. 4 Context Prerequisites Before following the workflow described in this article, the development environment should already be prepared. The setup process, including toolbox installation and the basic steps required to run an application, is described in the previous article. Depending on the selected project and application requirements, additional tools such as S32 Configuration Tools or EB tresos may be needed, especially when the default project configuration must be modified or when a custom project is created. Toolbox Workflow The development flow typically starts with creating a new project or opening an existing example and then selecting the target hardware. Figure 1. Opening a Simulink project or toolbox example. The selected target determines the available peripherals, supported examples, software configuration options, and build settings. As part of this step, the user can start from the default project associated with the selected target. This default project provides a ready-to-use baseline configuration and is typically the recommended option for evaluation boards and quick start development. For more advanced use cases, the workflow can also use a custom project configuration adapted to the application requirements. Figure 2. Selecting a custom project configuration. If the user continues with the default project configuration, additional low-level software changes may be limited. However, when the default project needs to be modified or when a custom project is used, tools such as S32 Configuration Tools or EB tresos may be required. Figure 3. Low-level software configuration using EB tresos or S32 Configuration Tool.  Figure 4. S32 Configuration Tool Configuration Template. Once the software stack is prepared, the Simulink model must be configured. This includes adding and parameterizing the relevant toolbox blocks, defining the application behavior, setting the model parameters, and aligning the model with the selected target and software configuration. Figure 5. Embedded Coder. Figure 6. Build or Generate Code step. After the model configuration is complete, code can be generated from the Simulink model. This step transforms the model into source code suitable for the selected target platform. The generated output reflects both the model behavior and the configuration settings applied in the previous stages. The generated code is then built using a supported compiler toolchain. The build process compiles and links the generated code together with the required software components and libraries. Build settings may vary depending on the target, compiler version, and selected optimization or debug options. Figure 7. Generated code. After a successful build, the application can be programmed onto the target hardware and executed. At this stage, the user can debug the application using the supported debug tools, inspect signals and variables, and verify that the application behaves as expected on the real hardware platform. Figure 8. Programming and debugging the application on target hardware. The final step of the workflow is validation and iteration. If issues are found during testing or debugging, the user may need to update the model, adjust the low-level software configuration, or modify build settings. The workflow is therefore iterative, allowing repeated cycles of configuration, code generation, build, programming, and validation until the desired result is achieved. Related Topics Additional details for each workflow stage are available in related documentation topics. For environment preparation, toolbox setup, and the basic steps required to run an application, refer to the previous article. More detailed information about model creation and configuration is provided in the next article. Other related topics may include examples library, supported boards and derivatives, low-level software configuration, compiler versions and options, and debugger usage. 5 References For more detailed information, refer to the related toolbox documentation and associated setup, modeling, software configuration, compiler, and debugging articles. MathWorks Simulink MathWorks Embedded Coder Generate Code from Simulink Models 6 Conclusion The toolbox workflow provides a structured path from model-based development to execution on the target hardware. Users can start quickly from the default project associated with the selected target, while still having the flexibility to create and use a custom project configuration when required. By following this workflow and using the related detailed documentation, users can iteratively configure, build, program, debug, and validate their applications more efficiently.
查看全文
FRDM i.MX93 上的 AP1302 MIPI CSI 流问题 你好, 我使用的是FRDM i.MX93开发板和X-RPI-CAM-MIPI A1摄像头模块。 我遇到的问题是,我无法从此设置中捕获 MIPI CSI 流。 我已将固件二进制文件ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin放置在以下位置:“/lib/firmware” 启动过程中,我看到 AP1302 被成功检测到,但是当我尝试启动视频流时, VIDIOC_STREAMON出现“管道破裂”错误。 以下是相关日志。 内核日志: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected 流媒体测试: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) 请问您能否帮我理解一下为什么VIDIOC_STREAMON会出现“管道破裂”错误? 在成功开始流媒体传输之前,AP1302 固件、设备树、媒体管道或传感器初始化是否需要任何额外的配置? 此外,我目前使用的是“LF_v6.18.2-1.0.0_images_IMX93EVK”预构建镜像。 如果您需要任何其他日志或信息,请告诉我。 感谢您的支持。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 与AE团队讨论。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 你好@yipingwang 感谢您的反馈, 我的回答如下,供您参考。 1. 固件位置 我尝试了推荐的固件安装位置,也尝试了每个位置的单独安装。仅当使用ap1302_ar0144_single_fw.bin时,相机探测才会成功。 root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw 启动过程中成功检测到 AP1302。 root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected 但是,我在内核日志中没有看到任何与 AP1302 相关的固件加载消息。 2. 软件环境 我使用的是为FRDM i.MX93板提供的预构建镜像。 root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw AP1302 检测成功,CSI/ISI 设备也存在。我已附上完整的日志供您参考。 3. 媒体管道 媒体管道似乎已正确创建。 root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 media-ctl 的输出显示 AP1302、CSI 和 ISI 实体已启用。完整的 media-ctl 输出结果已附上,供您参考。 4. 补充信息 请参考附件fourth_point.txt文件以获取所需信息。 5. 流媒体播放失败 当流媒体命令失败时,我没有看到任何其他内核消息。 root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg 故障发生后,dmesg 输出仍然为空,因此没有额外的内核日志可以帮助确定根本原因。 由于 AP1302 已被成功检测到,媒体图也已正确创建,并且在 VIDIOC_STREAMON 期间没有报告任何内核错误,请问我应该执行哪些额外的检查或调试步骤来确定为什么流媒体播放失败并出现“管道破裂”错误? 感谢您的支持。 root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] 此致, 米拉夫 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AP1302 探测成功并不能保证整个摄像机管道已配置完毕并开始传输。在 i.MX93 上,VIDIOC_STREAMON 返回 -1(管道破裂)通常意味着媒体管道元器件之一(AP1302 → MIPI CSI-2 接收器 → ISI 捕获路径)未能启动或协商有效流。您的日志仅确认检测到了 AP1302 I²C 设备: ap1302 2-003c:检测到 AP1302 版本 0.2.6 但这并不能证实这一点: 固件加载成功。 使用了正确的DTB。 媒体关系图已创建完成。 CSI接收器锁定到传入的MIPI数据, AP1302 已配置为匹配的输出格式。 首先我会检查:固件位置/名称 关于 FRDM-i.MX93 AP1302 支持,NXP 文档指出: 下载 ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin 将其重命名为ap1302.fw 放入: /lib/firmware/imx/camera/ap1302.fw 不仅仅是 /lib/firmware。 请核实: ls -l /lib/firmware/imx/camera/ap1302.fw 并检查启动日志: dmesg | grep -i 固件 dmesg | grep -i ap1302 查找类似这样的消息: 请求固件 固件已加载 固件加载失败 第二步:你使用的是正确的DTB吗? 版本说明表明 AP1302 支持与 i.MX93 EVK 设备树支持相关。 检查: cat /proc/device-tree/model cat /proc/cmdline 并确定实际加载的 DTB。 另请查看: dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi 第三项检查:验证介质拓扑结构 在尝试使用 v4l2-ctl 之前,请先验证媒体图是否存在: shell media-ctl -p 显示更多行 您应该会看到类似以下的实体: ap1302 CSI 伊西 videoX 如果 /dev/media0 不存在,则相机管道创建不正确。一个非常相似的FRDM-i.MX93 AP1302案例显示: media-ctl -p 枚举 /dev/media0 失败 这表明媒体管道尚未实例化。 请检查: ls -l /dev/media* 第四项检查:检查协商好的格式 运行: v4l2-ctl --list-devices 以及 v4l2-ctl -d /dev/video0 --all 另外: media-ctl -p AP1302 固件通常输出处理后的 YUV 格式,而不是 RAW Bayer 格式。另一个常见的故障是: AP1302 输出格式 A ISI 配置为 B 格式 导致流媒体启动失败。格式不匹配通常表现为 STREAMON 故障或 CSI 管道错误。 第五项检查:在 STREAMON 期间检查 CSI 错误 打开另一个终端并进行监测: dmesg -w 然后运行: v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 查找类似这样的消息: CSI超时 帧开始超时 未收到任何数据 先进先出溢出 MIPI错误 链接未启用 这些信息通常会揭示管道破裂的真正原因。
查看全文
割り込みを有効にせずにDMAでLPI2Cペリフェラルを使うにはどうすればいいですか? こんにちは、 私は NXP S32K396 MCU を扱っており、 割り込みを有効にせずにeDMAを使ってLPI2Cマスタートランザクションを実行したいと考えています。私のプロジェクトでは LPI2C1ペリフェラルを使っています。 以下の割り込みが有効であれば、DMAを使ってLPI2Cの読み書きトランザクションを正常に実行できます: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn しかし、RTD LPI2C DMAの実装はこれらの割り込みに依存しているようです。 Lpi2c_Ip_MasterSendData()では、LPI2Cマスター割り込みは常にドライバによって有効化されます: さらに、Lpi2c_Ip_MasterTxDmaConfig() および Lpi2c_Ip_MasterRxDmaConfig() によって TX および RX 用に構成された DMA TCD は、常に DMA メジャーループ完了割り込みを有効にします。 Lpi2c_DmaTransferList[9u]. Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT ; Lpi2c_DmaTransferList[9u]。値= 1U; また、別の関数であるLpi2c_Ip_MasterSendDataBlocking()では、LPI2C転送用のDMA TCDが設定されていないようです。 DMAを使ってLPI2Cの送受信トランザクション全体を行い、DMAを無効にし、eDMAチャネル割り込みを無効にLPI2C1_IRQnしたいと考えています。   可能であれば、NXPが LPI2CとDMAの両方の割り込みを無効にした状態でDMAを使用するLPI2CマスターTX/RXの例を提供していただけますか?   MCU:NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   どんなご支援でも大変ありがたく思います。どうぞよろしくお願いいたします! 必要なら、プロジェクトを添付できます。 Re: How to use LPI2C peripheral with DMA without enabling any interrupts? こんにちは@rkhw 現在のドライバ実装では、「Lpi2c_Ip_MasterSendData()」は転送完了と状態処理のためにLPI2Cマスター割り込みとDMAメジャーループ完了割り込みの両方に依存しています。 したがって、割り込みを有効にしなければDMAを有効にすることはできません。RTDドライバーはこの使用をサポートしていません。
查看全文
フラッシュ消去時にRAM内でピット割り込みが実行されます フラッシュを消している間にタイマー割り込みに入れないことがわかりました。私の要件を満たすために、タイマー割り込みをRAM上で実行する予定です。linker_flash_s32k388.ld ファイルを修正して IntCtrl_Ip.o と Pit_Ip.o を RAM に配置するようにしましたが、フラッシュを消去すると、タイマー割り込みの発生により依然としてエラーが発生します。私が見落としている点があれば教えてください。#s32k388 Re: Pit interrupt runs in ram wen flash erase こんにちは、 IntCtrl_Ip.oとPit_Ip.oを配置するだけでRAMに書き込むだけでは通常は不十分です。PFLASH消去操作中は、CPUは影響を受けたフラッシュアレイへのアクセスを避けなければなりません。 割り込みベクタテーブル、PIT ISR、ISRによって呼び出されるすべての関数、およびISRで使用されるすべてのデータ/定数がSRAMに配置されていることを確認してください。さらに、VTORレジスタがRAMベースのベクタテーブルを指していることを確認してください。リンカーマップファイルは通常、残りのフラッシュアクセスを特定する最良の方法です。 S32K3リファレンスマニュアルには、フラッシュ操作が継続実行を必要とする場合はコード実行をSRAMに移す必要があると記載されています。 よろしくお願いいたします。 ピーター
查看全文
执行 fls_Erase() 操作期间断电后,数据闪存损坏和 ECC 错误 我们发现,当由于断电/RESET情况导致Fls_Erase()操作中断时,数据闪存会发生损坏。系统重启后,受影响的数据闪存区域似乎已损坏。 在随后尝试使用Fls_Erase()恢复扇区时,当 Flash 驱动程序在执行擦除操作之前尝试访问受影响的地址范围时,会生成 ECC 错误。因此,擦除操作无法成功进行。 我们希望了解闪存控制器在此场景下的预期行为,并请求就以下几点提供指导: 如果在Fls_Erase()操作进行期间断电,数据闪存是否会损坏? 在发生此类中断后,访问部分擦除/损坏的闪存扇区时,是否预期会出现 ECC 错误? 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查,以便擦除和恢复损坏的 Flash 扇区? 断电后,对于包含无法纠正的ECC错误的闪存扇区,推荐的恢复程序是什么? 目标设备: [MPC5746C] 软件栈: [AUTOSAR / 裸机] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation 你好, 如果在Fls_Erase()操作进行期间断电,数据闪存是否会损坏? 是的,这是正确的做法。由于编程/擦除过程中断电,闪存中的数据将与 ECC 纠错码不匹配。 在发生此类中断后,访问部分擦除/损坏的闪存扇区时,是否预期会出现 ECC 错误? 是的。 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查,以便擦除和恢复损坏的 Flash 扇区? 不,这是硬件的永久性功能。 断电后,对于包含无法纠正的ECC错误的闪存扇区,推荐的恢复程序是什么? 在这种情况下,您需要初始化(擦除)损坏的闪存块。一旦完成 ECC 纠错,闪存中的数据将与 ECC 纠错匹配,访问不会触发 ECC 错误。 有关闪存擦除步骤,请参阅参考手册: 顺祝商祺! Peter
查看全文
S32K396的ETPU的例子 您好,我需要一个S32K396的RTD5.0.0用于S32DS3.5中生成的ETPU的demo,然后我想将它用于喷油功能,可以给我一个软件包和代码例子吗 Re: S32K396的ETPU的例子 嗨@大概, 实时驱动程序 (RTD)中已有 ETPU 和 S32K396 的示例: 此外,您可以在S32K3 - eTPU软件包中找到各种示例。它独立于RTD,这意味着可以使用任何版本,但是,eTPU软件仅使用特定的RTD 7.0.0版本进行了验证。版本,且无法保证与其他版本的兼容性。 此致, 朱利安
查看全文
S32 Design Studio for ARM v2.2许可延期 あなたは好,S32 Design Studio for ARM v2.2提示許可馬上到期,Activation Code:FAF2-FCC2-8A8E-87AC,麻烦延期,谢谢!
查看全文
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。
查看全文
Example of an ETPU based on S32K396 Hello, I need a demo of RTD 5.0.0 for S32K396 used in an ETPU generated by S32DS3.5. I want to use it for fuel injection functionality. Could you provide a software package and code examples? Re: S32K396的ETPU的例子 Hi @大概, There is an existing example for ETPU & S32K396 inside the Real-Time Drivers (RTD): Additionally, you can find various examples inside the S32K3 - eTPU SW package. It is independent from RTDs, meaning any version can be used, however, the eTPU SW has been validated only with the specific RTD 7.0.0 version, and compatibility with other versions cannot be guaranteed. Best regards, Julián
查看全文
Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation We are observing Data Flash corruption when a Fls_Erase() operation is interrupted due to a power abort/reset condition. After the system restarts, the affected Data Flash region appears corrupted. During a subsequent attempt to recover the sector using Fls_Erase(), ECC errors are generated when the Flash driver tries to access the affected address range before performing the erase operation. As a result, the erase operation cannot proceed successfully. We would like to understand the expected behavior of the Flash controller in this scenario and request guidance on the following points: Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? Target Device: [MPC5746C] Software Stack: [AUTOSAR / Bare Metal] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation Hello, Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Yes, that is correct behavior. As data in flash will not match ECC syndromes in flash due to power loss during programming / erase process. Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Yes. Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? No. It is permanent HW feature. What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? You need to initialize (erase) the corrupted flash block in such case. Once done ECC syndrome will match the data in flash and access wont trigger ECC faults. For flash erase procedure please refer to reference manual: Best regards, Peter
查看全文
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.
查看全文
Fls_Erase() 操作中の電源中断後のデータフラッシュ破損および ECC エラー 電源の中断/リセットによってFls_Erase()操作が中断された場合、データフラッシュの破損が発生することを確認しています。システムを再起動すると、影響を受けたデータフラッシュ領域が破損しているように見える。 その後、セクターを Fls_Erase()で復旧しようとする際、フラッシュドライバが消去操作を行う前に影響を受けたアドレス範囲にアクセスしようとした際にECCエラーが発生します。その結果、消去作業は成功裏に進められません。 このシナリオにおけるフラッシュコントローラの期待される挙動を理解し、以下の点についての指針をお願いしたいと思います。 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか? このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか? ターゲット装置: [MPC5746C] ソフトウェアスタック: [AUTOSAR / ベアメタル] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation こんにちは、 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか? はい、それは正しい行動です。フラッシュメモリ内のデータは、プログラミング/消去処理中の電源喪失により、フラッシュメモリ内のECC症候群と一致しなくなります。 このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? はい。 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? いいえ。これは恒久的なハードウェア機能です。 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか? その場合は破損したフラッシュブロックを初期化(消去)する必要があります。一度実行すると、ECC症候群はフラッシュのデータと一致し、アクセスによってECCの故障が起きません。 フラッシュ消去の手順については、リファレンス・マニュアルをご参照ください: よろしくお願いいたします。 ピーター
查看全文
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。
查看全文
S32K396をベースとしたETPUの例 こんにちは。S32DS3.5で生成されたETPUで使用されるS32K396用のRTD 5.0.0のデモが必要です。燃料噴射機能に使用したいと考えています。ソフトウェアパッケージとコード例を提供していただけますでしょうか? Re: S32K396的ETPU的例子 こんにちは@大概さん リアルタイム・ドライバ内にETPUおよびS32K396の既存例があります: さらに、S32K3 - eTPU SWパッケージの中には様々な例も見つかります。RTDとは独立しており、どのバージョンでも使用可能ですが、eTPUのSWは特定のRTD 7.0.0でのみ検証されていますバージョンや他のバージョンとの互換性は保証できません。 よろしくお願いします、 ジュリアン
查看全文
中断在内存中运行,闪存擦除 我发现擦除闪存时无法进入定时器中断。为了满足我的需求,我计划在 RAM 中运行定时器中断。我修改了 linker_flash_s32k388.ld 文件,将 IntCtrl_Ip.o 和 Pit_Ip.o 放入 RAM 中,但是当我擦除闪存时,由于定时器中断的到来,我仍然会遇到错误。请告诉我我遗漏了哪些细节。#s32k388 Re: Pit interrupt runs in ram wen flash erase 你好, 只需放置 IntCtrl_Ip.o 和 Pit_Ip.o仅仅存入内存通常是不够的。在 PFLASH 擦除操作期间,CPU 必须避免对受影响的闪存阵列进行任何访问。 请确认中断向量表、PIT ISR、ISR 调用的所有函数以及 ISR 使用的任何数据/常量也位于 SRAM 中。此外,确保 VTOR 寄存器指向基于 RAM 的向量表。链接器映射文件通常是识别剩余闪存访问的最佳方法。 S32K3 参考手册还指出,当闪存操作需要持续执行时,代码执行必须移至 SRAM。 顺祝商祺! Peter
查看全文