从密码战士到硬件 我使用的是 CW_VSPA_v10.3.10。成功调试代码后，我不知道如何将其部署到硬件上。我正在使用的主板是 LA1224。我注意到，所有示例文件都包含 .eld和 .map文件，但只有 .eld文件已在我的项目中生成。 Re: From codewarrior to hardware 谢谢。但我仍然想知道我能否使用 codewarrior Tap 来部署我的代码以及如何使用它。我试着编写脚本，但失败了，有没有任何例子或说明可以告诉我如何编写脚本？ Re: From codewarrior to hardware 将您的代码部署到 LA1224 板上 有两种常见的部署路径，取决于你是想要 RAM 加载还是持久闪存加载。 选项 A：使用调试器直接加载到硬件（在开发过程中最常见） 这通常是您在调试时已经做过的。 步骤： 连接 LA1224 板（根据需要连接 JTAG/probe/USB） 在 CW_VSPA 中： Run → Debug Configurations 选择您的VSPA / LA1224 调试配置 确保 选择项目中的.eld 文件 点击 “Debug” ✅ 这已将代码部署到目标 RAM中 ❌ 它不是持久性的（电源循环会清除它） 选项 B：将代码编程到 Flash 中（独立组网 (SA) 操作） 如果你希望 LA1224 在RESET后自动启动应用程序： 典型流程 生成项目 → 获取 .eld 使用 LA1224 闪存编程工具（因主板支持包而异）： 通常从 CW_VSPA 启动： Tools → Flash Programmer 或 Run → External Tools 请选择： 目标： LA1224LA1224 输入文件：您的 .eld 编程至闪存 RESET主板或重新通电 ✅ 代码现在无需调试器即可运行 ✅ .map 文件与此处无关 Re: From codewarrior to hardware 您好，我也遇到了同样的问题。我使用的是 CodeWarrior for VSPA 10.3.10，但我没有在那里看到“工具 - 闪存编程器”选项。 在“目标任务”下，只有“导入/导出/填充内存”和“硬件诊断”这两个选项。 如何将VSPA镜像写入闪存？ 对于 E200，我使用 CWforARM 的 Flash Programmer。我已成功将偏移量为 0x0 的 *xspi.bin 文件刷入系统。

コマンド:v4l2-ctl --device /dev/video0 --all ですべての詳細を取得できません こんにちは、皆さん。 私はカメラセンサーOS02G10を使っています。センサーからRAW10のファイルは入手できますが、画像は正しくありません。位置ずれがあり、画像内の2つの部分が互いにずれています。こちらでご覧いただけます: https://community.nxp.com/t5/i-MX-Processors/Camera-sensor-os02g10-MIPI-CSI-for-IMX8MM-Image-issue/m-p/1512386#M194329 カメラセンサーやmipi-csiのDeviceTree設定を何度も試しましたが、画像に変化はありませんでした。 v4l2にも問題があります。下記で確認できます。なぜそれができないのか Driver Info: Driver name : mx6s-csi Card type : i.MX6S_CSI Bus info : platform:32e20000.csi_bridge Driver version : 5.10.72 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Priority: 0 Video input : 0 (Camera: ok) Format Video Capture: Width/Height : 1920/1080 Pixel Format : '' Field : None Bytes per Line : 0 Size Image : 4147200 Colorspace : Default Transfer Function : Default (maps to Rec. 709) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 0, Height 0 Default : Left 0, Top 0, Width 0, Height 0 Pixel Aspect: 1/1 Selection Video Capture: crop, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_padded, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: native_size, Left 0, Top 0, Width 0, Height 0, Flags: しかし、写真を見るともっと詳細がわかる。v4l2が画像がおかしい原因なのか、それとも別の原因なのかを特定しようとしています。何が問題なのでしょうか? v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 3840 Size Image : 4147200 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags : VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) cap dqbuf: 0 seq: 0 bytesused: 4147200 ts: 46.903731 delta: 46903.731 ms (ts-monotonic, ts-src-eof) i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all こんにちは、Linuxのアップストリームドライバーを使えます。 私たちはこれをi.mx8MPベースのDebixプラットフォームでテストしました。 こちらがドライバです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad こちらが当社のDTです https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- ルトヴィイ シリコンシグナルズ Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all mx6s_vidioc_g_fmt_vid_cap が不完全なようです。 mx6s_vidioc_s_fmt_vid_cap にはすべての詳細が記載されています btarnowski_0-1672393812102.pngbtarnowski_0-1672393812102.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all RAW10に関しては解決策があります https://community.nxp.com/t5/i-MX-Graphics/gst-launch-1-0-returns-Internal-data-stream-error/m-p/1536966 また、v4l2-ctl --device /dev/video0 --all に関して 何が問題なのかは判断が難しいですが、もしかするとカメラドライバーはV4L2でctrlioではなくctrl APIを使っているのかもしれません しかし今は問題ではないので、次にすべきことは露出やゲインなどのパラメータを設定することです Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all こんにちは、 @btarnowskiさん v4l2-ctl --all で表示させるには、mx6s_capture.c を編集するだけで済みます。関数 'mx6s_vidioc_s_fmt_vid_cap' では、幅/高さ/サイズ画像/フィールドだけでなく、pix 構造体全体をコピーしてください。 csi_dev->pix = f->fmt.pix; このようにすることで、内部構造体 csi_dev->pix には get_format を実行する際に必要なすべての情報が含まれます (関数 mx6s_vidioc_g_fmt_vid_cap を参照)。 mx6s_capture.cには細かいミスがたくさんあり、v4l2ツールとの互換性を向上させるためには多くの改善が必要だと感じています。 よろしくお願いします。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all こんにちは、 v4l2-ctl --device /dev/video0 --allとgstreamに関して進展がありません。 カメラセンサのドライバの問題のようです。 dev/media0 - 不要 カメラセンサーの取り扱いにはさまざまなアプローチがあります。 以下に、低レベルのAPI処理の違いを示します。 OV5640(カメラセンサー)は他のデバイスで動作します。 btarnowski_0-1663928001102.pngbtarnowski_0-1663928001102.png そしてもう一つの比較： btarnowski_1-1663928150167.pngbtarnowski_1-1663928150167.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 何か解決策は見つかりましたか？私も同じエラーが出ています。もし同じエラーが出たら、解決策を教えてください。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all また、正しくない課題も見られます。csi_bridgeはmedia0に割り当てる必要があります。 btarnowski_0-1662374734790.pngbtarnowski_0-1662374734790.png どうすればいいですか？何かアドバイスをいただけますか？ Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all その間に： root@qrnd:~# gst-inspect-1.0 -a > gst-inspect.txt 結果は添付ファイルに記載されています。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 次の問題:ビデオデバイスは見えますが、/dev/mediaデバイスはありません root@qrnd:~# v4l2-ctl --list-devices i.MX6S_CSI (platform:32e20000.csi_bridge): /dev/video0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video2 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video1 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Yocto ビルド用のパッケージリストを更新しなければなりませんでした: # カメラサポートツール IMAGE_INSTALL_append = "i2c-tools" IMAGE_INSTALL_append = "v4l-utils" IMAGE_INSTALL_append = "gstreamer1.0" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good" IMAGE_INSTALL_append = " gstreamer1.0-plugins-imx" IMAGE_INSTALL_append = " gstreamer1.0-plugins-base" IMAGE_INSTALL_append = " gst-player" IMAGE_INSTALL_append = " gstreamer1.0-meta-base" IMAGE_INSTALL_append = " gst-examples" IMAGE_INSTALL_append = " gstreamer1.0-rtsp-server" IMAGE_INSTALL_append = " gst1.0-fsl-plugin" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-video4linux2" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-png" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-jpeg" しかし、コマンドに問題が発生しました gst -ローンチ- 1.0v4l2srcデバイス= / dev / video0 num - buffers = 1 !ビデオ/ x - raw 、幅= 1920 、高さ= 1080 !pngenc !filesink location =/ tmp / test_1920x1080 . png 私は以下を受け取りました： Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline: pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: ../git/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming stopped, reason not-negotiated (-4) Execution ended after 0:00:00.057218529 Setting pipeline to NULL ... Freeing pipeline ... Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all どうやらYoctoがこの問題を作っているようです。カーネルイメージには必要なコンポーネントがすべて含まれているわけではありません。gstreamer-plugins-goodから v4lsrc が欠落しています。Yocto Buildに追加のパッケージを追加しましたが、効果はありませんでした。Yoctoビルドプロセスのデプロイ段階を調べる必要があります。

PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi, I have configured EMAC0 at 2500 MBPS with required SERDES channel configuration. The Eth communication is up and running during ECU run state.  After shutting down the applications accessing Eth communication, I trigger the ECU sleep request from ECUM with sets the MCU mode to SOC standby with HSE_CM7 selected as main core.  Post wakeup the ECU resumes the normal operation, the layers COM, SOAD, TCPIP, ETHIF are working as expected, In the Eth if layer during the API invocation of "Provide TX buffer" returns an error stating TX buffers are not free, followed by no transmission of Eth frames List of fixes tried resolve the issue: 1. Tried to Shutdown the PFE driver using "Eth_43_Pfe_Deinit" and starting the PFE driver by calling "Eth_43_Pfe_Init" but the CPU gets locked after the execution if Init API. 2. Tried to turndown the Eth controller using Eth_43_Pfe_SetController mode to down and bring it active by setting back the mode to "Active" which led to bus fault Please let me know the potential fix for this issue.  P.S> Configurator Used: EB tresos Eth PFE RTD version:  1.3.0  SDK: GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi @Joey_z  1. The PFEs are only being used in M-core 2. I'm using the development board: S32G-VNP-RDB3 Regards, Avinash V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Thank you for contacting us. 1.Are the PFEs only used in the M core? Have you used the A core together? 2.Are you using your customer board or our development board? BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Thank you for your reply. 1.When the SOC entry the mode of standby, about the PFE clock of partition2 will be disabled, you should check if you have reenabled the partition2 after wakeup. You can try to check the  PRTN2_STAT.PCS state before the PFE Init. 2. Check the SERDES if it is a normal function. BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi @Joey_z, The bitfield in Partition_2 status register remains 1 pre-sleep, it gets updated to 0 during sleep state and it is getting updated back to 1 post wakeup i.e, after the MCU mode is set to normal. The Serdes is working fine. Additionally I have tried with EMAC2 in RGMII mode where SERDES is not involved in between the ETH Phy connector (RJ45) and the controller (NXPS32G399A) even in this case the issue remained the same. If there is any restart sequence required for Partition_2 post wakeup, please let me know. Regards, Avinash V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Thank you for your reply. Could you tell me about your operation of standby and wakeup sequence?  1. How to you set the core and partition? 2.Do you use the bootloader and A core in your application? BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi @Joey_z, Please find the sleep-wakeup sequence below: 1. I'm requesting ECU sleep mode using API "EcuM_SelectShutdownTarget()"  which in turns sets the MCU mode to standby as per the ECUM implementation. 2. Once the ECUM enters sleep mode it polls for a wakeup event, the CAN transceiver detects the bus activity and set the wakeup event using EcuM_SetWakeupEvent() API then the ECU resumes normal operation. Regarding bootloader, we have the NXP bootloader (blob is flashed at 0x0) location of flash and the M-core application is flashed at location 0x400000.  A-core is not being used anywhere. Regards, Avinash V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi,Avinash_7373 Your problem is likely to be a PFE initialization issue after wakeup. Check the clock and the related PFE configuration, and ensure that it has been initialized to an ideal state. 1. Check that the PFE initialization is put into bootloader and properly reinitialized in the application after waking up. 2. Check the relevant configurations according to the Standby process. Refer to RM 32.5.5 "Run mode to Standby mode". BR Joey Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup Hi，Avinash_7373 Has there been any progress on your issue? If you need continued support, could you please upload your code to the following link so that we can better analyze the problem? https://support.nxp.com BR Joey

Motorola MCQ1C3L69JおよびMotorola MC908Q4CPのデータシート 上記2つの部品のデータシートを探しています。 Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets こんにちは、 ご不便をおかけし申し訳ありません。これは古い製品で情報が限られています。 MC908Q4CP: もしかして「908QC4」のことで、MC68HC908QC4をお探しでしょうか？もしそうなら、こちらがデータシートです[MC68HC908QC16、MC68HC908QC8、MC68HC908QC4 - データシート] C08Qファミリーに関するさらなるデータシートについては 、HC08Q|8ビットEEPROMエミュレーションQ MCUを参照してください。NXPセミコンダクターズ MCQ1C3L69J: 「3L69J」は、正誤表の情報によるとマスクを指しています。 デバイスを特定するための他の名前があるか確認していただけますか? よろしくお願いいたします。 Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello よろしくお願いします。 添付画像をご覧ください

S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays Hello, I am working with S9KEAZN16AM and would like some clarification regarding WDOG initialization timing. Configuration MCU: S9KEAZN16AM Bus Clock: 16.777216 MHz WDOG Clock Source: 1 kHz LPOCLK Reset Type: Software Reset (SYSRESETREQ) According to the KEA64 Reference Manual, after the watchdog unlock sequence: "On completing the unlock sequence, the user must reconfigure the watchdog within 128 bus clocks; otherwise, the watchdog forces a reset to the MCU." ppande19_1-1784788705383.pngppande19_1-1784788705383.png With a bus clock of 16.777216 MHz: 128 bus clocks ≈ 7.63 µs Observations Our current implementation requires the following delays for reliable operation: Software_Reset();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); We observe two issues: If the 2.5 ms delay after Software_Reset() is removed or reduced, the watchdog counter does not always start/run correctly. If the 80 µs delay after WDOG_Init() is removed, the watchdog configuration is not always applied correctly. Questions Is the 128 bus clock requirement only the configuration window after unlock, or does additional internal synchronization occur afterwards? Can the use of the 1 kHz LPO clock introduce additional synchronization delays? Is there any known startup timing requirement after a software reset that could explain the need for ~2.5 ms? Is there a recommended status bit or polling mechanism that should be used instead of fixed delays? The main point of confusion is that the observed delays (80 µs and 2.5 ms) are significantly larger than the timing implied by the documented 128 bus clock (~7.6 µs) requirement. Any guidance would be greatly appreciated. Thank you. Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays you try to initialize the watchdog or run tight timing loops before the ICS has completely locked, your actual bus clock frequency will be lower or unstable during that window. A lower actual bus clock means that 128 bus cycles will take significantly longer than 7.6 µs, or your initialization sequence executes before the hardware peripherals are fully out of their reset state. The ~2.5 ms delay gives the ICS ample time to achieve a full lock and stabilize the 16.777216 MHz bus frequency.   Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays Hello, Wait ~2.5 ms for the Internal Clock Source (ICS) to achieve a full lockand stabilize the bus clock (16.777216 MHz). Initializing the watchdogor running tight loops too early results in an unstable/lower clock,causing timing discrepancies or executing before peripherals leave reset.

PFE EMAC0 ECU唤醒后无效缓冲区访问 你好， 我已经将 EMAC0 配置为 2500 MBPS，并进行了所需的 SERDES 通道配置。ECU运行期间，以太网通信正常进行。 关闭所有访问以太网通信的应用程序后，我从ECUM触发ECU睡眠请求，将MCU模式设置为SOC待机模式，并选择HSE_CM7作为主核心。 ECU唤醒后恢复正常运行，COM、SOAD、TCPIP和ETHIF层工作正常。但在ETHIF层调用“提供TX缓冲区”API时，返回错误信息，提示TX缓冲区已满，导致无法发送以太网帧。 以下列出了尝试解决此问题的修复方法： 1. 尝试使用“Eth_43_Pfe_Deinit”关闭 PFE 驱动程序，并通过调用“Eth_43_Pfe_Init”启动 PFE 驱动程序，但如果执行 Init API，CPU 将在执行后锁定。 2. 尝试使用 Eth_43_Pfe_SetController 模式将以太网控制器关闭，然后通过将模式设置回“Active”来激活它，结果导致总线故障。 请告知此问题的潜在解决方案。 PS> 使用的配置器：EB tresos 以太坊 PFE RTD 版本：1.3.0 SDK：GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 感谢您的回复。 1.当 SOC 进入待机模式时，分区 2 的 PFE 时钟将被禁用，唤醒后应检查是否已重新启用分区 2。您可以尝试在 PFE 初始化之前检查 PRTN2_STAT.PCS 状态。 2. 检查 SERDES 是否正常工作。 BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 嗨@Joey_z 1.PFE 仅用于 M 型核心。 2. 我使用的是开发板： S32G-VNP-RDB3 问候， 阿维纳什·V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 感谢您与我们联系。 1. PFE 是否仅用于 M 核心？你们都用过A核心组件吗？ 2.您使用的是客户的开发板还是我们的开发板？ BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 嗨@Joey_z ， Partition_2 状态寄存器中的位域在睡眠前保持为1 ，在睡眠状态下更新为0 ，在唤醒后（即 MCU 模式设置为正常后）更新回1 。 SerDes 工作正常。此外，我还尝试了 EMAC2 的 RGMII 模式，其中 ETH Phy 连接器 (RJ45) 和控制器 (NXPS32G399A) 之间不涉及 SERDES，即使在这种情况下，问题仍然存在。 如果 Partition_2 在唤醒后需要任何重启顺序，请告知。 问候， 阿维纳什·V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 您的问题很可能是唤醒后 PFE 初始化问题。检查时钟和相关的 PFE 配置，并确保其已初始化到理想状态。 1. 检查 PFE 初始化是否已放入引导加载程序中，并在应用程序唤醒后正确重新初始化。 2. 根据备用流程检查相关配置。请参阅 RM 32.5.5“运行模式到待机模式”。 BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 嗨@Joey_z ， 请查看以下睡眠-觉醒顺序： 1. 我正在使用 API " EcuM_SelectShutdownTarget()"请求 ECU 进入睡眠模式，这反过来会根据 ECUM 的实现将 MCU 模式设置为待机模式。 2. 当ECU进入睡眠模式后，它会轮询唤醒事件，CAN收发器检测到总线活动并使用EcuM_SetWakeupEvent() API设置唤醒事件，然后ECU恢复正常运行。 关于引导加载程序，NXP引导加载程序（blob文件刷写在闪存的0x0地址）和M-core应用程序刷写在0x400000地址。A核心目前在任何地方都没有使用。 问候， 阿维纳什·V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好，Avinash_7373 感谢您的回复。 能否介绍一下你们的待机和唤醒顺序？ 1. 如何设置核心和分区？ 2.你的应用程序中是否使用了引导加载程序和A核心？ BR 乔伊 Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup 你好， Avinash_7373 你的问题有进展吗？如果您需要继续获得支持，请将您的代码上传到以下链接，以便我们更好地分析问题？ https://support.nxp.com BR 乔伊

Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets I am looking for the datasheets for the above 2 components Please Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello, I apologize for the inconveniences this might cause you, this are old product and the information is limited; MC908Q4CP: Is it possible that you meant "908QC4" and looking for the MC68HC908QC4? If so this is the Datasheet [MC68HC908QC16, MC68HC908QC8, MC68HC908QC4 - Data Sheet] For more datasheets on the C08Q family refer to HC08Q|8-bit EEPROM Emulation Q MCUs | NXP Semiconductors MCQ1C3L69J: The "3L69J" is referring to a mask according to the erratas information; Could you help us confirm if you have an additional name to identify the device? Best Regards Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello Thanks Please see attached picture

Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK Dear NXP Support Team, While reviewing the i.MX95 19x19 CPU EVK board schematic, I noticed that the SD2_VSEL and SD2_RST_B signals are connected to the FP09 GPIO1 and GPIO2 pins. Could you please explain the purpose of these connections in more detail? In particular, I would like to understand why these two signals are connected to the GPIO pins and how they are intended to be controlled or used in the system. Best regards, Walter Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK The intent is to let the i.MX95 uSDHC2 block control the SD-card power rails through the PF09 PMIC, rather than treating those nets as ordinary board GPIOs. SD2_VSEL → PF09 GPIO1 : this is for SD/SDIO voltage switching. The i.MX95 uSDHC VSELECT output is defined as a signal used to change the external power-supply voltage, and the controller supports voltage selection through VEND_SPEC[VSELECT] . In PF09, GPIO1 can be configured as a dedicated VSELECT input ; when enabled, GPIO1 selects LDO2 = 3.3 V when low and LDO2 = 1.8 V when high . This matches the SD3.0 requirement that the platform implement both 3.3 V and 1.8 V signaling. SD2_RST_B → PF09 GPIO2 : this is for card power/reset control. The i.MX95 RESET_B signal is described as optional, active-low, and for a removable card it can be used “instead of hardware reset to enable/disable Card power during warm reset.” PF09 GPIO2 can be configured as an LDO1EN input , where the pin enables or disables the LDO1 output by hardware. So the EVK connection gives the uSDHC2 reset/power-control signal a direct path to the PMIC-controlled SD-card supply. In practical terms, these PF09 pins are not being used as random expansion GPIOs on the EVK. They are multi-function PMIC pins wired so the SD host controller can request the correct SD-card rail behavior: Signal PF09 pin role System purpose SD2_VSEL PF09 GPIO1 in VSELECT mode Switch NVCC_SD2 /SD I/O supply between 3.3 V and 1.8 V for SD3.0 operation. SD2_RST_B PF09 GPIO2 in LDO1EN mode or equivalent card-power control role Enable/disable SD-card power, especially around reset/warm-reset behavior. So the control path is typically: uSDHC2 driver/U-Boot configures the SD host controller → uSDHC2 drives SD2_VSEL and/or SD2_RST_B → PF09 interprets those pins according to its OTP/configuration → PF09 changes the SD-related LDO state . PF09’s GPIO modes/default behavior are OTP-configurable, and its GPIO outputs can also be controlled in system-on states when configured as GPOs, but the EVK wiring is intended to use the PMIC’s dedicated SD power-management functions rather than manual bit-banging. Bottom line: SD2_VSEL and SD2_RST_B are routed to PF09 GPIO1/GPIO2 so the i.MX95 uSDHC2 interface can perform SD-card voltage switching and card power/reset control through the PMIC. Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK Hello, Yes. Those connections are intentional SD2_VSEL and SD2_RST_B are used to let the i.MX95 USDHC2 interface control the SD-card power/reset behavior through the PF09 PMIC, rather than being ordinary GPIO signals. SD2_VSEL → PF09 GPIO1: controls the SD-card I/O voltage switching, typically between 3.3 V and 1.8 V for SD 3.0 operation. SD2_RST_B → PF09 GPIO2: provides SD-card power/reset control, particularly useful during reset or power-cycle sequences. So the intended path is essentially: i.MX95 USDHC2 → SD2_VSEL / SD2_RST_B → PF09 → SD-card power rails The Linux device tree also shows SD2_VSELECT being used by USDHC2 and SD2_RESET_B being used for SD-card power control, which confirms these are part of the normal SD-card design rather than spare GPIOs.

无法使用命令 `v4l2-ctl --device /dev/video0 --all` 获取所有详细信息 大家好， 我正在使用相机传感器os02g10。我可以从传感器获取 RAW10 文件，但是图像不正确。图片错位了，两部分图像错位了。您可以在这里看到： https://community.nxp.com/t5/i-MX-Processors/Camera-sensor-os02g10-MIPI-CSI-for-IMX8MM-Image-issue/m-p/1512386#M194329 我测试了摄像头传感器和 mipi-csi 的许多设备树设置，但图像没有任何变化。 v4l2也存在问题，您可以在下方看到。为什么它无法获得 Driver Info: Driver name : mx6s-csi Card type : i.MX6S_CSI Bus info : platform:32e20000.csi_bridge Driver version : 5.10.72 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Priority: 0 Video input : 0 (Camera: ok) Format Video Capture: Width/Height : 1920/1080 Pixel Format : '' Field : None Bytes per Line : 0 Size Image : 4147200 Colorspace : Default Transfer Function : Default (maps to Rec. 709) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 0, Height 0 Default : Left 0, Top 0, Width 0, Height 0 Pixel Aspect: 1/1 Selection Video Capture: crop, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_padded, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: native_size, Left 0, Top 0, Width 0, Height 0, Flags: 但是当我拿到图片时，会发现更多细节。我试图确定 v4l2 是否是导致图片错误的原因，还是其他原因。到底出了什么问题？ v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 3840 Size Image : 4147200 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags : VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) cap dqbuf: 0 seq: 0 bytesused: 4147200 ts: 46.903731 delta: 46903.731 ms (ts-monotonic, ts-src-eof) i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 您好，您可以使用我们已向上游提交的 Linux 驱动程序。 我们已在基于 i.mx8mp 的 debix 平台上进行了测试。 这是我们的司机。 https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad 这是我们的DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- 鲁特维 SiliconSignals Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all mx6s_vidioc_g_fmt_vid_cap 似乎不完整。 mx6s_vidioc_s_fmt_vid_cap 包含所有详细信息 btarnowski_0-1672393812102.pngbtarnowski_0-1672393812102.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 关于 RAW10，有解决方案。 https://community.nxp.com/t5/i-MX-Graphics/gst-launch-1-0-returns-Internal-data-stream-error/m-p/1536966 关于：v4l2-ctl --设备 /dev/video0 --all 很难说哪里出了问题，可能是摄像头驱动程序对 V4L2 使用了 ctrl API 而不是 ctrlio。 但现在这不是问题了，接下来我要设置的参数是曝光或增益。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 嗨@btarnowski 对于使用 v4l2-ctl --all 显示的问题，你只需要编辑 mx6s_capture.c 文件即可。在函数“mx6s_vidioc_s_fmt_vid_cap”中：只需复制整个 pix 结构体，而不是仅复制宽度/高度/图像大小/字段。 csi_dev->pix = f->fmt.pix; 这样，内部结构体 csi_dev->pix 就包含了执行 get_format 时所需的所有信息（参见函数 mx6s_vidioc_g_fmt_vid_cap）。 我觉得 mx6s_capture.c 有很多小错误，需要进行很多改进才能更好地与 v4l2 工具兼容。 此致问候 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 你好， 使用v4l2-ctl --设备 /dev/video0 --all和gstream均未取得进展。 看起来像是摄像头传感器驱动程序的问题。 dev/media0 - 不需要 处理相机传感器有多种不同的方法。 下面您可以看到底层 API 处理方面的差异。 ov5640（摄像头传感器）在其他设备上可以正常工作。 btarnowski_0-1663928001102.pngbtarnowski_0-1663928001102.png 还有另一项比较： btarnowski_1-1663928150167.pngbtarnowski_1-1663928150167.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 你找到解决办法了吗？因为我也遇到了同样的错误，如果你也遇到了，请分享一下你的解决方法。 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 而且我发现有些作业分配不正确。csi_bridge 应该分配给 media0。 btarnowski_0-1662374734790.pngbtarnowski_0-1662374734790.png 具体该怎么做？求助！ Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 同时： root@qrnd:~# gst-inspect-1.0 -a > gst-inspect.txt 结果如下（见附件） Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 下一个问题：我可以看到视频设备，但是没有 /dev/media 设备。 root@qrnd:~# v4l2-ctl --list-devices i.MX6S_CSI (platform:32e20000.csi_bridge): /dev/video0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video2 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video1 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 我需要更新 Yocto 版本所需的软件包列表： # 相机支持工具 IMAGE_INSTALL_append = " i2c-tools" IMAGE_INSTALL_append = " v4l-utils" IMAGE_INSTALL_append = " gstreamer1.0" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good" IMAGE_INSTALL_append = " gstreamer1.0-plugins-imx" IMAGE_INSTALL_append = " gstreamer1.0-plugins-base" IMAGE_INSTALL_append = " gst-player" IMAGE_INSTALL_append = " gstreamer1.0-meta-base" IMAGE_INSTALL_append = " gst-examples" IMAGE_INSTALL_append = " gstreamer1.0-rtsp-server" IMAGE_INSTALL_append = " gst1.0-fsl-plugin" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-video4linux2" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-png" IMAGE_INSTALL_append = "gstreamer1.0-plugins-good-jpeg" 但我现在在使用命令时遇到了问题。 gst -发布- 1.0v4l2src 设备 = / dev / video0 缓冲区 数量 = 1 ！video / x - raw , width = 1920 , height = 1080 !pngenc ！filesink location = / tmp / test_1920x1080.png​ 我得到的是： Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline: pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: ../git/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming stopped, reason not-negotiated (-4) Execution ended after 0:00:00.057218529 Setting pipeline to NULL ... Freeing pipeline ... Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all 看来是 Yocto 造成了这个问题。内核镜像中并不包含所有必需的元器件。gstreamer-plugins-good缺少 v4lsrc。我向 Yocto 构建中添加了额外的软件包，但没有效果。需要调查 Yocto 版本过程的部署阶段。

S32K322 和 S32K312：关于 CMU 中断、RESET 响应和检测延迟的查询 请 提供 故障 事件 与 相应 CMU 实例 （ CMU0 、 CMU1 和 CMU2） 的 映射 关系 ？ 中断 文档 列出 了 总共 七个 中断 ， 但 并不 清楚 每个 CMU 实例 处理 哪些 故障 事件 以及 它们 相应 的 故障 操作 。 请查看附件图片 system clock monitoring.png系统时钟监控.png Interruptmapping.png中断映射.png What is the exact meaning of the "RESET Reaction Interrupt"? 该 中断 是否 会 在 破坏性 RESET 之前 产生 ， 从而允许 软件 在 RESET 发生 之前 进行干预 ？ 时钟 监控 延迟 可 配置 为 1 µs 至 1 ms 。 选择 较低 的 延迟 是否能 有效 减少 消 抖/滤波 时间 ， 并使 时钟 故障 检测 更加 灵敏 或 更快？ Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency 您好@WadkarY 1. 请问 能否 提供 故障 事件 与 相应 CMU 实例 （ CMU0、 CMU1 和 CMU2） 的 映射关系 ？ image.pngimage.png image.pngimage.png 从图中可以看出，只有 CMU_FC_0、CMU_FM_1、CMU_FM_2 可以配置为中断；其他中断默认应视为破坏性复位源，而不是标准 CMU 中断。 CMU_FC_0->CMU0 CMU_FM_1->CMU1 CMU_FM_2->CMU2 CMU_FC_3->CORE_CLK_FAIL CMU RESET 复位反应中断 CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU RESET 反应中断 CMU_FC_5->HSE_CLK_FAIL CMU 复位反应中断 CMU_FC_6->CM7_CORE_CLK_FAIL CMU 复位反应中断 2. 此 中断 是否 在 破坏性 RESET 之前 产生 ， 从而允许 在 RESET 发生 之前 进行 软件 干预 ？ 不，除非特意配置了 MC_RGM/DCM 破坏性 RESET 中断旁路，否则不会出现破坏性 RESET 行为。 例如： 1. CMU_FC_4 检测到 AIPS_PLAT_CLK 频率超过阈值 ↓ 破坏性复位已钳位 + 同时发出 IRQ 215 ↓ 几乎瞬间 MCU RESET → 从 RESET Vector 重启 ↓ 软件读取 MC_RGM.DES[AIPS_PLAT_CLK_FAIL] 以识别 RESET 原因 3.选择较低的延迟是否能有效减少消抖/滤波时间，并使时钟故障检测更加灵敏或更快？ 该参数与 REF_CNT 相关。 •RCCR[REF_CNT] 值越高，测量窗口越长，从而在监测的时钟检查中实现更高的精度。 • RCCR[REF_CNT] 值越低，测量窗口越短，导致 FHH 和 FLL 事件响应越快，但报告结果的准确性越低。

Advanced Mitochondrial Formula Reviews: A Complete Buyer’s Guide Last Updated: 5 September 2026 Advanced Mitochondrial Formula is a dietary supplement designed to support mitochondrial health and cellular energy production. Unlike many general energy supplements that focus mainly on stimulants, this formula is intended to provide nutritional support for the mitochondria, often referred to as the “powerhouses” of your cells. This is one of the things that makes Advanced Mitochondrial Formula stand out from other mitochondrial support supplements on the market. The main idea behind Advanced Mitochondrial Formula is simple: provide your body with nutrients that may help support healthy mitochondrial function and efficient cellular energy production. When your mitochondria are working properly, your cells can produce energy more efficiently. That may help support everyday energy levels, stamina, mental focus, and overall cellular performance. Re: Advanced Mitochondrial Formula Reviews: A Complete Buyer’s Guide Advanced Mitochondrial Formula is a dietary supplement formulated in the USA, Canada, UK, Australia and NZ to support mitochondrial function and healthy cellular energy production. Rather than relying primarily on stimulants like many conventional energy supplements, it focuses on supplying key nutrients that help nourish and support the mitochondria—the structures often described as the “powerhouses” of our cells. This nutritional approach is one of the features that distinguishes ORIGINAL Advanced Mitochondrial Formula from many other mitochondrial-support products. The concept behind Advanced Mitochondrial Formula is straightforward: provide the body with nutrients that may help maintain healthy mitochondrial activity and support efficient energy production at the cellular level. Well-functioning mitochondria play an important role in how cells generate energy. By supporting normal mitochondrial function, the formula may help promote everyday energy, stamina, mental alertness, and overall cellular performance.

MCIMX6D6AVT10ACの境界スキャン用BSDLファイルを探しています こんにちは、 デバイス「MCIMX6D6AVT10AC」のBSDLファイルをダウンロードできるチャネルはありますか?

i.MX95 19x19 EVKにおけるSD2_VSELおよびSD2_RST_B接続に関する質問 親愛なるNXPサポートチームへ、 i.MX95 19x19 CPU EVK基板の回路図を確認していると、SD2_VSEL信号とSD2_RST_B信号がFP09のGPIO1およびGPIO2ピンに接続されていることに気づきました。 これらの接続の目的をもう少し詳しく説明していただけますか? 特に、なぜこれら2つの信号がGPIOピンに接続されているのか、そしてそれらがシステム内でどのように制御または使用されるのかを理解したいです。 よろしくお願いいたします。 ウォルター Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK その目的は、i.MX95 uSDHC2ブロックがPF09 PMICを介してSDカードの電源レールを制御できるようにすることであり、これらのネットを通常のボードGPIOとして扱うことではありません。 SD2_VSEL → PF09 GPIO1 ：これはSD/SDIO電圧の切り替え用です。i.MX95 uSDHC VSELECT出力は外部電源電圧を変化させる信号として定義されており、コントローラはVEND_SPEC[VSELECT]による電圧選択をサポートしています。PF09では、GPIO1を専用のVSELECT入力として設定できます;有効化すると、低電圧時はLDO2 = 3.3 V、高電圧時はLDO2 = 1.8 Vを選択します。これは、プラットフォームが3.3Vと1.8Vの両方の信号を実装するSD3.0の要件と一致します。 SD2_RST_B → PF09 GPIO2 : これはカードの電源/リセット制御用です。i.MX95のRESET_B信号はオプションのアクティブローと説明されており、着脱式カードの場合は「ハードウェアリセットの代わりにウォームリセット時にカード電源を有効化・無効化するために使用できます」。PF09 GPIO2はLDO1EN入力として構成でき、ピンがハードウェアによってLDO1出力を有効または無効化します。したがって、EVK接続はuSDHC2のリセット/電源制御信号をPMIC制御のSDカード供給に直接送る経路を与えます。 実際には、これらのPF09ピンはEVK上でランダム拡張GPIOとしては使用されていません。これらは多機能PMICピンで、SDホストコントローラーが正しいSDカードレールの挙動を要求できるように配線されています。 信号 PF09ピンロール システムの目的 SD2_VSEL PF09 GPIO1 を VSELECT モードで使用する SD3.0動作用に3.3Vから1.8Vの間の/SD I/O電源をスイッチNVCC_SD2。 SD2_RST_B PF09 GPIO2をLDO1ENモードまたは同等のカード電源制御ロールで使用する SDカードの電源を有効/無効にします。特にリセット/ウォームリセット動作時に役立ちます。 したがって、制御経路は通常次の通りです:uSDHC2ドライバー/U-BootがSDホストコントローラ→uSDHC2ドライブをSD2_VSEL設定し、PF09がそれらのピンをOTPや設定に従って解釈SD2_RST_B →PF09がSD関連のLDO状態を変更し→PF09のGPIOモードやデフォルト動作はOTPで設定可能で、GPO出力もGPOとして設定した場合、システムオン状態で制御可能ですが、EVK配線は手動ビットバンではなく、PMIC専用のSD電源管理機能を使用することを意図しています。 結論として、SD2_VSELとSD2_RST_BはPF09 GPIO1/GPIO2にルーティングされているため、i.MX95 uSDHC2インターフェースはPMICを通じてSDカードの電圧切り替えやカードの電源・リセット制御を行えます。 Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK こんにちは、 はい。これらの接続は意図的なSD2_VSELであり、SD2_RST_Bはi.MX95 USDHC2インターフェースが通常のGPIO信号ではなく、PF09 PMICを通じてSDカードの電源/リセット動作を制御するために使われています。 SD2_VSEL → PF09 GPIO1: SDカードのI/O電圧の切り替えを制御します。SD 3.0動作の場合、通常は3.3Vと1.8Vの間で切り替わります。 SD2_RST_B → PF09 GPIO2: SDカードの電源/リセット制御を提供します。特にリセットまたは電源サイクルシーケンス中に役立ちます。 つまり、意図された経路は基本的に次の通りです: i.MX95 USDHC2 → SD2_VSEL / SD2_RST_B → PF09 → SDカード電源レール Linuxデバイスツリーでは、USDHC2でSD2_VSELECTが使用され、SD2_RESET_BがSDカードの電源制御に使われていることが示されており、これらは予備のGPIOではなく通常のSDカード設計の一部であることが確認されています。

先進ミトコンドリアフォーミュラのレビュー：完全購入ガイド 最終更新日:2026年9月5日 アドバンスト・ミトコンドリアフォーミュラは、ミトコンドリアの健康と細胞エネルギー生成をサポートするために設計された栄養補助食品です。多くの一般的なエネルギーサプリメントが主に刺激物に焦点を当てているのに対し、この処方はミトコンドリア、すなわち細胞の「パワーハウス」と呼ばれる部分に栄養をサポートすることを目的としています。これがAdvanced Mitochondrial Formulaが他のミトコンドリアサポートサプリメントと差別化されている理由の一つです。 The main アイデア behind Advanced Mitochondrial Formula is simple: provide your body with nutrients that may help support healthy mitochondrial function and efficient cellular energy production. When your mitochondria are working properly, your cells can produce energy more efficiently. That may help support everyday energy levels, stamina, mental focus, and overall cellular performance. Re: Advanced Mitochondrial Formula Reviews: A Complete Buyer’s Guide アドバンスト・ミトコンドリアフォーミュラは、アメリカ、カナダ、イギリス、オーストラリア、ニュージーランドで調合される栄養補助食品で、ミトコンドリアの機能と健康的な細胞エネルギー生成をサポートします。多くの従来のエネルギーサプリメントのように主に刺激物に依存するのではなく、ミトコンドリアを養いサポートするための重要な栄養素の供給に焦点を当てています。ミトコンドリアはしばしば細胞の「パワーハウス」と呼ばれる構造です。この栄養アプローチは、 オリジナル・アドバンスト・ミトコンドリアルフォーミュラ を多くの他のミトコンドリアサポート製品と区別する特徴の一つです。 Advanced Mitochondrial Formulaのコンセプトはシンプルです。健康なミトコンドリア活動を維持し、細胞レベルで効率的なエネルギー生産をサポートする栄養素を体に供給することです。正常に機能するミトコンドリアは、細胞がエネルギーを生成する上で重要な役割を果たしている。この処方は、ミトコンドリアの正常な機能をサポートすることで、日々のエネルギー、スタミナ、精神的な覚醒度、そして細胞全体のパフォーマンス向上に役立つ可能性があります。

Looking for boundary scan, BSDL file for MCIMX6D6AVT10AC Hi,  Is there any channel to download the BSDL file for device "MCIMX6D6AVT10AC"?

S32K322およびS32K312:CMU割り込み、リセット反応、検出レイテンシに関するクエリ 故障 イベント情報 を それぞれの CMU インスタンス(CMU0、 CMU1、 CMU2) に マッピング していただけますか? 割り込み ドキュメント には 合計 7回 の 割り込み が記載 されています が、 各 CMU インスタンス が どの 障害 イベント情報 と それに対応する 障害 アクション を 処理 しているかは 明確 ではありません 。 添付画像をご覧ください system clock monitoring.pngシステムクロックの監視.png Interruptmapping.pngInterruptmapping.png 「リセット 反応 割り込み 」 の 正確な 意味 は 何 ですか ？ この 割り込み は 破壊的な リセット の前に 生成 され、 リセット が 起こる 前に ソフトウェア が 介入 できるように なるのでしょうか? The clock monitoring レイテンシ can be configured from 1 µs to 1 ms. レイ テンシ を 低 くすることで 、 デバウンスやフィルタリング の時間を 短縮 し、 クロック 障害検出 の 感度 や速度 が 向上 するのでしょうか? Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@ WadkarY 1. 障害発生 イベント情報 と それぞれ の CMU インスタンス （CMU0、 CMU1、 CMU2 ） と の マッピング を 提供していただけ ます か ？ image.pngimage.png image.pngimage.png ご覧のとおり、CMU_FC_0、CMU_FM_1、CMU_FM_2のみが割り込みとして設定可能です。その他の割り込みは、標準のCMU割り込みとしてではなく、デフォルトでは破壊的なリセットの発生源として扱われるべきです。 CMU_FC_0->CMU0 CMU_FM_1->CMU1 CMU_FM_2->CMU2 CMU_FC_3->CORE_CLK_FAIL CMUリセット反応割り込み CMU_FC_4->AIPS_PLAT_CLK_FAIL CMUリセット反応割り込み CMU_FC_5->HSE_CLK_FAIL CMUリセット反応割り込み CMU_FC_6->CM7_CORE_CLK_FAIL CMUリセット反応割り込み 2. この 割り込み は 破壊的な リセット の前に 生成 され、 リセット が 起こる 前に ソフトウェア の 介入 を可能にする のか? いいえ、MC_RGM/DCM破壊リセット割り込みバイパスが意図的に構成されていない限り、破壊リセット動作が予想されます。 以下にその例をご紹介します。 1. CMU_FC_4 は、AIPS_PLAT_CLK 周波数がしきい値を超えていることを検出します。 ↓ 破壊的リセットが主張され、同時にIRQ 215が発行されました。 ↓ ほぼ瞬時に MCUのリセット → リセットベクターからの再起動 ↓ ソフトウェアはMC_RGMを読みます。DES[AIPS_PLAT_CLK_FAIL]でリセット原因を特定します 3. レイテンシを低く設定することで、デバウンス/フィルタリング時間を効果的に短縮し、クロック障害の検出感度や検出速度を向上させることができますか？ このパラメータはREF_CNTに関連しています。 •RCCR[REF_CNT]の値が高いほど測定ウィンドウが長くなり、監視対象のクロックチェックの精度が向上します。 ・RCCR[REF_CNT]の値が低いと測定ウィンドウが短くなり、FHHおよびFLLの反応が速くなりますが、報告結果の誤差が高まります。

正在查找 MCIMX6D6AVT10AC 的边界扫描 BSDL 文件 你好， 是否有渠道可以下载设备“ MCIMX6D6AVT10AC”的BSDL文件？

S9KEAZN16AM WDOGタイミングに関する補足説明：128バスクロックと観測された80µsおよび2.5msの遅延について こんにちは、 私はS9KEAZN16AMを扱っており、WDOGの初期化タイミングについていくつか確認したい点があります。 設定 MCU:S9KEAZN16AM バスクロック: 16.777216 MHz WDOGクロックソース：1kHz LPOCLK リセットタイプ:ソフトウェアリセット(SYSRESETREQ) KEA64リファレンスマニュアルによると、ウォッチドッグの解除シーケンスの後: 「アンロックシーケンスを完了した後、ユーザーは128のバスクロック内でウォッチドッグを再構成しなければなりません;そうでなければ、監視役はMCUのリセットを強制します。」 ppande19_1-1784788705383.pngppande19_1-1784788705383.png バスクロック周波数は16.777216MHzです。 128バスクロック ≈ 7.63マイクロ秒 補足事項 現在の実装では、安定した動作のために以下の遅延が必要となります。 ソフトウェアリセット();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); 我々は2つの問題点を指摘する。 Software_Reset() の後の 2.5 ms の遅延を削除または短縮すると、ウォッチドッグ カウンタが正しく起動/実行されない場合があります。 WDOG_Init() の後の 80 µs の遅延を削除すると、ウォッチドッグの設定が常に正しく適用されるとは限りません。 質問 128バスクロックの要件は、ロック解除後の設定ウィンドウのみに適用されるのでしょうか、それともその後も追加の内部同期が行われるのでしょうか？ 1 kHzのLPOクロックの使用によって追加の同期遅延が生じることはありますか? ソフトウェアリセット後の起動タイミングの要件で、約2.5msの遅延が必要になる理由は何かありますか? 固定遅延の代わりに、推奨されるステータスビットやポーリングメカニズムはありますか？ 混乱の主な原因は、観測された遅延（ 80 µs と 2.5 ms ）が、文書化された128 バス クロックの要件（約 7.6 µs）から示唆されるタイミングよりもかなり大きいことである。 何かご助言いただければ大変ありがたいです。 よろしくお願いします。 Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays ICSが完全にロックする前にウォッチドッグを初期化したり、タイトなタイミングループを実行しようとすると、その期間中は実際のバスクロック周波数が低くなったり、不安定になったりします。実際のバスクロックが低いと、128回のバスサイクルが7.6μsよりかなり長くかかるか、ハードウェアペリフェラルが完全にリセット状態を解除する前に初期化シーケンスが実行されることを意味します。約2.5ミリ秒の遅延により、ICSは完全なロックを達成し、16.777216MHzのバス周波数を安定させるのに十分な時間を確保できる。 Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays こんにちは、 内部クロックソース（ICS）が完全にロックしてバスクロック（16.777216 MHz）が安定するまで、約2.5ミリ秒待ちます。ウォッチドッグを初期化したり、タイトループをあまりに早く実行すると、不安定またはクロックが低くなり、タイミングのずれやペリフェラルのリセット前に実行されることがあります。

关于 i.MX95 19x19 EVK 上的 SD2_VSEL 和 SD2_RST_B 连接的问题 尊敬的恩智浦技术支持团队： 在查看 i.MX95 19x19 CPU EVK 板原理图时，我注意到 SD2_VSEL 和 SD2_RST_B 信号连接到 FP09 GPIO1 和 GPIO2 引脚。 请您更详细地解释一下这些连接的用途？ 我尤其想了解为什么这两个信号要连接到 GPIO 引脚，以及它们在系统中是如何控制或使用的。 顺祝商祺！ 沃尔特 Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK 其目的是让 i.MX95 uSDHC2 模块通过 PF09 PMIC 控制 SD 卡电源轨，而不是将这些网络视为普通的板 GPIO。 SD2_VSEL → PF09 GPIO1 ：这是用于 SD/SDIO 电压切换。i.MX95 uSDHC 的 VSELECT 输出被定义为用于改变外部电源电压的信号，控制器支持通过 VEND_SPEC[VSELECT] 进行电压选择。在 PF09 中， GPIO1 可以配置为专用 VSELECT 输入；启用时，GPIO1在低电平时选择 LDO2 = 3.3 V，在高电平时选择 LDO2 = 1.8 V。这符合 SD3.0 的要求，即平台必须同时实现 3.3 V 和 1.8 V 信号。 SD2_RST_B → PF09 GPIO2 : this is for card power/RESET control.i.MX95 的 RESET_B 信号被描述为可选的、低电平有效的，对于可拆卸卡，它可以“代替硬件 RESET，在热 RESET 期间启用/禁用卡电源”。PF09 GPIO2 可以配置为 LDO1EN 输入，该引脚通过硬件启用或禁用 LDO1 输出。因此，EVK 连接为 uSDHC2 RESET/电源控制信号提供了一条直接通往 PMIC 控制的 SD 卡电源的路径。 实际上，这些 PF09 引脚并没有在 EVK 上用作随机扩展 GPIO。它们是多功能 PMIC 引脚，连接方式使得 SD 主机控制器可以请求正确的 SD 卡导轨行为： 信号 PF09 引脚角色 系统目的 SD2_VSEL PF09 GPIO1 处于 VSELECT 模式 将 NVCC_SD2 /SD I/O 电源在 3.3 V 和 1.8 V 之间切换，以实现 SD3.0 操作。 SD2_RST_B PF09 GPIO2 处于 LDO1EN 模式或等效的卡电源控制角色 启用/禁用 SD 卡电源，尤其是在 RESET/热 RESET 行为期间。 因此，控制路径通常是： uSDHC2 驱动程序/U-Boot 配置 SD 主机控制器 → uSDHC2 驱动 SD2_VSEL 和/或 SD2_RST_B → PF09 根据其 OTP/配置解释这些引脚 → PF09 改变与 SD 相关的低压差线性稳压器(LDO)状态。PF09 的 GPIO 模式/默认行为可通过 OTP 配置，其 GPIO 输出在配置为 GPO 时也可在系统开启状态下进行控制，但 EVK 接线旨在利用 PMIC 的专用 SD 电源管理功能，而不是手动进行位操作。 结论：SD2_VSEL 和 SD2_RST_B 被路由到 PF09 GPIO1/GPIO2，以便 i.MX95 uSDHC2 接口可以通过 PMIC 执行 SD 卡电压切换和卡电源/复位控制。 Re: Question About SD2_VSEL and SD2_RST_B Connections on i.MX95 19x19 EVK 你好， 是的。这些连接是故意的，SD2_VSEL 和 SD2_RST_B 用于让 i.MX95 USDHC2 接口通过 PF09 PMIC 控制 SD 卡的电源/复位行为，而不是普通的 GPIO 信号。 SD2_VSEL → PF09 GPIO1：控制 SD 卡 I/O 电压切换，SD 3.0 操作通常在 3.3 V 和 1.8 V 之间切换。 SD2_RST_B → PF09 GPIO2：提供 SD 卡电源/RESET 控制，在 RESET 或电源循环序列期间特别有用。 所以预期的路径本质上是： i.MX95 USDHC2 → SD2_VSEL / SD2_RST_B → PF09 → SD卡电源轨 Linux 设备树还显示 SD2_VSELECT 被 USDHC2 使用，SD2_RESET_B 被用于 SD 卡电源控制，这证实了这些是正常 SD 卡设计的一部分，而不是备用 GPIO。

How to get NPU Temperature and utilization for NXP i.MX93 EVK I am using i.MX93 EVK and want to monitor the Ethos-U NPU temperature & utilization(load) at runtime how can I get this data ? The agenda is to monitor the HW-parameters during the inference of AI-models. I could monitor the below parameters using i.MX8MPlus I want to achieve the similar for i.MX93. 8MPlus RAM=$(free -m | awk '/Mem:/ {print $3}') CPU_LOAD=$(vmstat 1 2 | tail -1 | awk '{print 100 - $15}') CPU_TEMP=$(awk '{print $1/1000}' /sys/class/thermal/thermal_zone0/temp 2>/dev/null || echo "N/A") GPU_TEMP=$(awk '{print $1/1000}' /sys/class/thermal/thermal_zone1/temp 2>/dev/null || echo "${CPU_TEMP}") GPU_LOAD=$(cat /sys/kernel/debug/gc/load 2>/dev/null | awk '/load/ {gsub("%","",$3); if (max=="" || $3>max) max=$3} END {if (max!="") print max "%"; else print "N/A"}') I.mx93 RAM=$(free -m | awk '/Mem:/ {print $3}') CPU_LOAD=$(vmstat 1 2 | tail -1 | awk '{print 100 - $15}') CPU_TEMP=$(awk '{print $1/1000}' /sys/class/thermal/thermal_zone0/temp) How can I monitor the GPU_LOAD & GPU_TEMP for i.MX93 npu(ethos-u) ? Linux Re: How to get NPU Temperature and utilization for NXP i.MX93 EVK Hi @sonal-acldigital  Neither the i.MX 8M Plus nor the i.MX 93 offers a method to monitor NPU temperature in real time. - imx8MP, thermal_zone0 represents the cpu-thermal temperature ，thermal_zone1 represents the soc-thermal temperature. - imx93, thermal_zone0 represents the cpu-thermal temperature. - NPU, There is no such tool like nputop. For information on performance tuning, please refer to Section 7.1.2, "Profiling for Hardware Accelerators," in the ML User Guide. B.R Re: How to get NPU Temperature and utilization for NXP i.MX93 EVK @pengyong_zhang Thanks for clarifying the thermal zones for the i.MX 8M Plus and i.MX 93. Could you please clarify the following: i.MX8MPLUS 1. GPU Temperature: Is there a dedicated system path (like /sys/class/thermal/thermal_zoneX/temp) to read individual GPU temperatures, or is it covered solely under the soc-thermal zone (thermal_zone1)? 2. GPU Load: Is reading /sys/kernel/debug/gc/load the standard method for checking GPU load, or is the process detailed in Section 7.1.2 of the ML User Guide required for this as well? i.MX93: Since there is no native tool (like nputop) to monitor NPU load and temperature, we would like to ask: Is it valid to derive relative NPU utilization by measuring the reduction in CPU load when offloading inference execution to the NPU vs. running on the CPU alone? If this method isn't recommended, is there any alternative driver node or performance counter we can use to estimate NPU activity during an inference run?