Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
iMX8M Plus CC Controller Hii, We are developing the custom som based on the iMX8M plus processors with custom carrier board. In this, We have a requirement for USB1 OTG supported with ID pin. We have taken ID pin from GPIO1_IO4. Due to board space constraint and ID Pin requirement we are planning to use HD3SS3220IRNH - TI (CC Controller with diff mux) in our design. Please confirm whether i.mx8m plus supports HD3SS3220IRNH as OTG. Specifically for Flashing purpose whether this controller is supported? Re: iMX8M Plus CC Controller Hi @govind18  The i.MX 8M Plus can be configured in system designs to work with the TI HD3SS3220 to implement a dual-role USB Type-C port; however, this device is not a Type-C controller that has been officially verified or supported by NXP‘s EVK. GPIO1_IO4 can be used as USB ID in Uboot/Linux and does not affect UUU programming. It is recommended that the HD3SS3220 be configured to UFP/Sink by default at power-on. Best Regards, Zhiming Re: iMX8M Plus CC Controller Hi @Zhiming_Liu  Could you please suggest any other tested CC controller that has ID pin Supported? Re: iMX8M Plus CC Controller Hi  On EVK board, the i.MX8MP is using  PTN5110NHQZ  as CC controller. Please refer the EVK design here. Zhiming_Liu_0-1789018946469.pngZhiming_Liu_0-1789018946469.png https://www.nxp.com/design/design-center/development-boards-and-designs/8MPLUSLPD4-EVK Best Regards, Zhiming Re: iMX8M Plus CC Controller Hi @Zhiming_Liu Could you please suggest CC controller?
查看全文
LPC1778 IAP烧录CCLK越大反而烧录越慢 您好,我在使用LPC1778的IAP模式进行烧录时,发现CCLK越大反而烧录越慢。 IAP指令大多可以传入CCLK参数,手册中的描述是:Param3: CPU Clock Frequency (CCLK) in kHz。 我在调试LPC1778时,将驱动默认的CCLK值从12000(12MHz)改为4000(4Mhz),发现烧录速度反而变快了。我尝试了多个值,发现CCLK参数越大,烧录反而越慢,请问这是什么原因?这个CCLK指的是什么频率? 回复: LPC1778 IAP烧录CCLK越大反而烧录越慢 Hi @BianHaopeng1  CCLK 在 LPC1778/LPC178x 文档中指 ARM processor clock frequency / Main CPU clock ,也就是内核 CPU 时钟,IAP 的擦除命令明确要求传入 CPU Clock Frequency (CCLK) in kHz 。 原因大概率不是“CCLK 越低 Flash 物理写入越快”,而是 IAP ROM 例程把你传入的 CCLK 当作当前 CPU 主频来计算 Flash 擦写时序/等待时间 。因此,如果实际 CPU 仍在较高频率运行,而你只把传给 IAP 的参数从 12000 改成 4000 ,IAP 会按 4 MHz 去生成更短的延时/时序,表现上烧录变快;但这属于给 IAP 传了错误时钟,Flash 擦写可靠性、温度/电压边界和长期保持不一定有保证。 正确做法是: CCLK 参数应填写调用 IAP 时真实的 CPU 主频,单位 kHz 。 BR Harry Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 在 LPC1778 中,CCLK 指的是实际的 CPU 核心时钟频率(以 kHz 为单位),而不是晶振/XTAL 频率。IAP 引导加载程序使用 CCLK 参数来计算其内部时序,特别是对于闪存编程和 UART 通信。如果您提供的值与 MCU 的实际 CPU 时钟不匹配,或者时钟配置与 IAP 代码预期的不同,则时序计算可能会出错,导致编程或通信速度变慢。因此,请确保 CCLK 参数与 PLL/分频器配置后的 CPU 时钟完全匹配(例如,120 MHz 应指定为 120000 kHz,而不是 12000)。
查看全文
RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hi Team  , I downloaded SAFERTOS from SAFERTOS® Archives - High Integrity Systems I am following below S32 design studio and RTD version for SAFERTOS.(Version as they mentioned in document) ComponentVersion S32 Design Studio IDE v3.6.4 ARM GCC Compiler 11.4 S32K3 Real-Time Drivers (RTD) 6.0.0 I am facing some error, Vardhman_0-1788413006999.pngVardhman_0-1788413006999.png I tried with different S32 design studio( Version 3.5) and RTD version RTD (2.0.0. and 5.0.0) Is this .mex created with different version ?  Can you please provide what could be the solution. Thanks. Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello @Vardhman , I am glad to hear that the SafeRTOS demo is now running on the board.   The standard Variables and Expressions views normally display values only when the target is halted. Since the project uses the PEmicro debugger, please open: Window → Show View → Other… → PE Microcomputer Systems → Real Time Expressions Add ulTickHookCallCount to this view and resume the application. This view is specifically intended for monitoring variables while the target is running. If required, declare the debug variable as volatile and use a debug build with low or disabled compiler optimization. Please also refer to the following NXP Community threads, which describe how to enable and use the Real Time Expressions view for monitoring variables while the target is running: How to watch variables live - NXP Community Solved: How do I enable Live View for variables when debugging? - NXP Community Best regrads, Pavel Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello Team, Vardhman_0-1788508409179.pngVardhman_0-1788508409179.png S32 was removing this double quotes and modifying path when I copied to local directory. when I corrected path. Demo RTOS is running on board. Query - I am not able to see global variable live on S32 design studio.What setting I need to do ?? Everytime I suppose to halt the code then I can able to see variable values. Vardhman_1-1788508801698.pngVardhman_1-1788508801698.png      Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello, Step 1 - I installed S32-3.6.4 version RTD 6.0.0. I was facing this issue now its resolved. I was installing wrong RTD package. Now its working. Vardhman_0-1788436426474.pngVardhman_0-1788436426474.png Step 2 - Now I have imported the Demo SAFERTOS project provided by highintegrity systems see below snip. Vardhman_1-1788436679719.pngVardhman_1-1788436679719.png Step 3 - I went in manage SDK there I found that PlatformSDK_S32K344_M7 giving error or its not supported, what could be the possibility? to resolve this  Vardhman_2-1788436993601.pngVardhman_2-1788436993601.png Step 4 - When I am creating new project not able to see SDK there still. How to resolve this ?  Step 5 - I have one query I installed 3.6.4 S32 design studio when I am installing this RTD package(6.0.0) I can see S32 design studio updated to 3.6.10. If this S32 design studio updating to 3.6.10 then this version will not supported by  highintegrity systems as they mentioned compatible version for DEMO SAFERTOS IS 3.6.4 - pls give openion on this.  Step 6 - S32 design studio updated to 3.6.10  Vardhman_4-1788437960107.pngVardhman_4-1788437960107.png Step 7 - I am getting this error after building code, Vardhman_3-1788437895528.pngVardhman_3-1788437895528.png I have attached RTD that i have installed. SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_DesignStudio_updatesite Thanks ,  Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Hello @Vardhman , Please check that NXP GCC 10.2 is installed. Also, make sure that the GCC 10.2 toolchain is selected when creating the application project. A similar issue is described in the following Community thread, including screenshots. Although the thread refers to the S32K1xx RTD, the reported dependency-related symptoms are similar: S32DS 3.6.7: S32K1xx RTD 3.0.0 not detected when creating a new project Best regards, Pavel Re: RE: SafeRTOS Support and Package Availability for FRDM-A-S32K34 Thanks this is working.
查看全文
カメラセンサーOS02G10 MIPI CSI for IMX8MM こんにちは、みんな。 OS02g10のドライバーは以下から入手しました: https://github.com/Shaggy013/kernel-5.10 ドライバーをパッチとして追加しました。 私のデバイスツリーは次のようになっています。 csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; カメラドライバーとmxc_mipi-csi.c用にプローブ機能を修正しました。mx6s-csi.c 以前はフォーマット一致エラーが2回発生しましたが、mx6s-csiに追加しました { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } そしてmxc_mipi-csi.cに追加されました { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } v4l2 APIは正常に動作し、エラーは発生しません。以下は画像を取得するためのコマンドです v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw そして、デバッグメッセージの結果 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 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) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) その後は何も起こらず、ただ待って待つだけで何も起こらない。 20MHzオシロスコープではMIPI DATAおよびMIPI CLKラインのトラフィックを観測できません。(帯域幅が低いのは承知していますが、データ回線であれば何らかの変化が見られるはずです。しかし、全く反応がありません。) clkノードが正しいかどうか確信が持てません。クロック名によるmipi_csiクロックと一致する&clkノードがない可能性もあります。どなたか使用経験のある方はいらっしゃいますか? どうすればいいでしょうか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM こんにちは、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: Camera sensor os02g10 MIPI CSI for IMX8MM うまくいきました。 .bpp2でなければならない しかし主な問題はハードウェアにあった
查看全文
S32K388 GMAC0 Eth_43_GMACドライバーがRX割り込みを受け取らない こんにちは、 私は以下の設定を使用しています。 S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 提供されたEth_InternalLoopback_S32K388例プロジェクトをベースにし、PCからメディアコンバーター経由でフレームを受け取れるように改良しました。例 S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600で言及されていた RTD 修正を追加しました。ブレークポイントを達成できました Eth_43_GMAC_Receive(EthConf_EthCtrlConfig_EthCtrlConfig_0、0U、&Status); そして、イーサネットフレームを点検できました EthIf_RxIndication(Eth_43_GMAC_apxInternalCfg[PartitionId]->Eth_43_GMAC_apCtrlConfig[CtrlIdx]->EthCtrlEthIfIdx, FrameType, IsBroadcast, MacSrcAddr, Payload, PayloadLength, IngressTimeTuplePtr, RxHandleId); しかし、while 1 ループを追加し、Rx 割り込みを有効にして GMAC0_CH0_RX_IRQHandler にリンクしても、どこにも割り込みが発生しませんでした。プロジェクトを以下に添付しました。 James_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.pngJames_Zhang_SE_0-1788220964718.png S32K3 オートモーティブ-RTD  Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、 @James_Zhang_SE さん、 添付のプロジェクトを確認しました。RTD7.0.1でRX IRQを有効にするには、Ingress QueueHandlerFunctionを変更してQueueInterruptを有効にする必要があります。 PavelL_0-1788263577590.pngPavelL_0-1788263577590.pngPavelL_0-1788263577590.png その変更後、GMAC_RxIRQHandler() でブレークポイントに到達しました。Eth_43_GMAC_Receive() にて。 また、RGMII TXCLKが入力として定義されていますが、出力として定義されるべきです。 ただし、WiresharkでTXフレームを見るには、イニットシーケンスを適切に変更する必要があります。 例S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600 。あなたのプロジェクトでは、次のように見え ます: PavelL_1-1788264277735.pngPavelL_1-1788264277735.pngPavelL_1-1788264277735.png よろしくお願いいたします。 パベル Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、パベルさん。 サポートありがとうございます。ご提案の修正を適用した後、GMACドライバーが動作するようになりました。 いくつか追加の質問がありますので、ご教示いただければ幸いです。 GMACドライバーの設定や使用手順を完全に説明した詳細なドキュメントはありますか?まずは自分でドキュメントを確認して、ドライバのことをもっと理解したいと思っています。 EthIf_RxIndication()の中で、呼び出す必要がありますか? Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId); 関数の最後に受信バッファを解放する処理はありますか? GMACの設定オプションは数多く用意されています。各設定パラメータが何をするのか、どのように設定すべきかを説明するドキュメントや参考文献はありますか? ご協力ありがとうございました。皆さんのサポートに本当に感謝しています。 Re: S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt こんにちは、 @James_Zhang_SE さん。 最新情報のご共有ありがとうございます。GMACドライバーが今あなたのために使えるようになったと聞いて安心しました。 追加のご質問について: 1.ドライバーの設定および使用に関する主な参照は、RTDインストールに含まれているEth_43_GMACユーザーマニュアルです。例:C:\NXP\S32DS.3.6.6_RTD701\S32DS\software\PlatformSDK_S32K3\RTD\Eth_43_GMAC_TS_T40D34M70I1R0\doc\RTD_ETH_43_GMAC_UM.pdf 同じディレクトリに保存されている対応するEth_43_GMAC統合マニュアル(RTD_ETH_43_GMAC_IM.pdf)と、利用可能なGMACサンプルプロジェクトも確認することをお勧めします。   2. Eth_43_GMAC_ReleaseRxBuffer() を呼び出す必要があるかどうかは、EthCtrlReleaseResourceAfterReception 設定パラメータによって決まります。 PavelL_0-1789024403441.png 受信後の自動リリースが有効の場合、ドライバーはEthIf_RxIndication()が戻った後にRXリソースを解放するため、明示的にリリースすべきではありません。 自動解放が無効になっている場合、EthIf_RxIndication() が戻った後も、受信バッファは割り当てられたままになります。その場合、アプリケーションは最終的に以下を呼び出さなければなりません。 Eth_43_GMAC_ReleaseRxBuffer(CtrlIdx, RxHandleId);   このモードは、アプリケーションが受信データを保持してさらなるプロセッシングを行う必要がある場合に有用です。ただし、バッファはアプリケーションが使用を終えた後に解放されなければなりません。そうしないと、利用可能な受信バッファが最終的に枯渇してしまう。 また、受信したペイロードポインタは、対応するバッファが解放された後は使用しないでください。 3. Eth_43_GMACユーザーマニュアルは個々の構成パラメータの主要な参照資料でもあります。さらに、S32設定ツールでは、対応する設定を選択またはマウスオーバーすると、多くのパラメーターの説明が表示されます。MACフィルタリング、DMA操作、MTLキュー、タイムスタンプ、割り込み状態などのハードウェアレベルの動作については、S32K3リファレンスマニュアルのGMAC/EMAC章を参照してください。 実用的な出発点として、RTDパッケージで提供されているGMACの例を参照することをお勧めします。このページには、lwIPの機能的なサンプルも掲載されています。 https://community.nxp.com/t5/S32K-Knowledge-Base/S32K-Examples/ta-p/1108990 何か問題を感じたら、遠慮なくサポートをお願いしてください。各トピックごとに専用スレッドを設けることが望ましいです。これにより、他のユーザーにとってケースの明確さを保つことができます。 よろしくお願いいたします。 パベル
查看全文
IMX95 datasheet Hello, How can I get imx95 datasheet with register maps, peripherals, etc.? Regards, Artur Re: IMX95 datasheet Thank you and have a nice day Regards, Artur Re: IMX95 datasheet The datasheet alone does not contain the full register maps and peripheral descriptions. For that, you need the https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf. Thanks
查看全文
IMX95 数据手册 你好, 如何获取包含寄存器映射、外设等信息的imx95数据手册? 问候, 阿图尔 Re: IMX95 datasheet 谢谢,祝您愉快! 问候, 阿图尔 Re: IMX95 datasheet 单凭数据手册无法包含完整的寄存器映射和外设描述。 为此,您需要https://www.nxp.com/docs/en/reference-manual/IMX95RM.pdf 。 谢谢!
查看全文
LPC1778 IAPプログラミングにおいて、CCLKの値が大きいほどプログラミング速度は遅くなります。 こんにちは。LPC1778のIAPモードを使用してプログラムを書き込んでいたところ、CCLKの値が大きいほど書き込み処理が遅くなることがわかりました。 ほとんどの IAP 命令は CCLK パラメータを受け入れることができます。これはマニュアルでは次のように説明されています: Param3: CPU クロック周波数 (CCLK) (kHz)。 LPC1778のデバッグ中に、ドライバのデフォルトのCCLK値を12000(12MHz)から4000(4MHz)に変更したところ、書き込み速度が実際に向上しました。いくつかの値を試したところ、CCLKパラメータが大きいほど書き込み処理が遅くなることがわかりました。これはなぜでしょうか?CCLKはどの周波数を指しているのでしょうか? 回复: LPC1778 IAP烧录CCLK越大反而烧录越慢 こんにちは@BianHaopeng1 LPC1778/LPC178xのドキュメントでは、CCLKはARMプロセッサのクロック周波数、つまりメインCPUクロック(コアCPUクロック)を指します。IAP消去コマンドでは、CPUクロック周波数(CCLK)をkHz単位で指定する必要があります。 その理由は、「CCLKが低いほど物理的なフラッシュ書き込みが速くなる」ということではなく、IAP ROMルーチンが渡されたCCLKを現在のCPU周波数として扱い、フラッシュ消去/書き込みのタイミング/待機時間を計算しているためである可能性が高い。したがって、実際のCPUがより高い周波数で動作している状態で、IAPに渡されるパラメータを12000から4000に変更した場合、IAPは4MHzに基づいてより短いレイテンシ/タイミングを生成し、書き込みが速くなる。しかし、これはIAPに誤ったクロックが渡されることを意味し、フラッシュ消去/書き込みの信頼性、温度/電圧の許容範囲、および長期安定性が保証されない。 正しい方法は、IAP呼び出し時の実際のCPUクロック速度をkHz単位でCCLKパラメータに入力することです。 BR ハリー Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 LPC1778では、CCLKは水晶発振器の周波数ではなく、実際のCPUコアクロック周波数(kHz単位)を意味します。IAPブートローダーは、特にフラッシュメモリのプログラミングやUART通信において、内部タイミングを計算するためにCCLKパラメータを使用します。提供した値がMCUの実際のCPUクロックと一致しなかったり、クロックがIAPコードの期待値と異なる設定をしていると、タイミング計算が誤り、プログラミングや通信が遅くなることがあります。したがって、PLL/分周器の設定後、CCLKパラメータがCPUクロックと完全に一致するようにしてください(例えば、120MHzは120000kHzと指定する必要があり、12000とは指定しません)。
查看全文
MFRC630とCLRC663は互換性がありますか? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 現在、当社の製品は2台のCLRC663を使用しています。これらは50オームのインピーダンスにマッチングされているため、CLRC663の「高電流」機能を活用しません。未来では制作コストを節約し、1 CLRC663(14443と15693をサポートする必要があるため必要)と1 MFRC630(2つ目のリーダーはmifareのみで済みます)だけを使いたいと考えています。 両方の製品で自社ライブラリをテストすることに成功しましたが、「変更可能な」UIDチップタイプでも動作しているようです 良い。つまり、ソフトウェアの問題ではないということです。私の推測では、MFRC630はCLRC630とは別のファームウェアで、サポートしていないのだと思いますISO15693 フットプリントとピン配置は同じです 唯一気になるのは、マッチングについてです。 ミフェアでマッチングされたCLRC663を、マッチングネットワークを変えずにドロップインMFRC630に置き換えることは可能でしょうか? NFCコントローラーソリューション NFCフロントエンド・ソリューション Re: MFRC630 and CLRC663 Interchangeability? すでに答えは見つかっていると思いますが、これを見つけた方のために、アプリケーションノート(https://www.nxp.com/docs/en/application-note/AN11256.pdf)に「変更は不要」と書かれています。 私もMFRC630を使用するプロジェクトに取り組んでいますが、開発段階ではCLRC663を使用しています。CLRC663用の基板が存在するからです。プロジェクトが終わったら、移行が申請書の通りスムーズに進んだかどうかを確認する投稿を追加します。 Re: MFRC630 and CLRC663 Interchangeability? こんにちは、 @jof さん、 はい、これらのICは「チューニング」に対応しています。シリコンは同じですが、MFRC660 MIFAREテクノロジ(ISO 14443、タイプA)のみをサポートし、CLRC663はタイプA、タイプB、その他すべてのテクノロジをサポートしていますISO15693... BR トマス
查看全文
MFRC630 and CLRC663 Interchangeability? Currently our product uses two pcs of CLRC663. They are matched to 50Ohms impedance, so they will not make use of the "high current" capability of the CLRC663. For the furture, we want to save on production costs and use just one CLRC663 (needed because it must support 14443 and 15693) and one MFRC630 (second reader only needs mifare). I succesfully tested our own library on both products and they seem to work, even with "changeable" uid chip types very well. So it wouldn't be a software thing. My guess is that the MFRC630 is just a different firmware than CLRC630, to not support ISO15693 Footprint and pinout are the same The only thing i wonder is about the matching. Could the CLRC663 which is matched for mifare, replaced by a drop-in MFRC630 without changing the matching network? NFC Controller Solutions NFC Frontend Solutions Re: MFRC630 and CLRC663 Interchangeability? I assume you've already found the answer, but for anyone who might find this, there is an application note ( https://www.nxp.com/docs/en/application-note/AN11256.pdf) which says that no changes need to be made. I am also working on a project which will use the MFRC630, but for development, I'm using CLRC663 because there is a board for it. I shall add a post here after finishing the project, confirming whether the migration went as smoothly as the application note says. Re: MFRC630 and CLRC663 Interchangeability? Hello @jof ,  Yes, the ICs are "tuning" compatible. The silicon is the same but MFRC660 supports only MIFARE technology (ISO 14443, Type A) while the CLRC663 supports all technologies as Type A, Type B, ISO15693...  BR Tomas 
查看全文
适用于 IMX8MM 的 OS02G10 MIPI CSI 摄像头传感器 大家好。 我从以下位置获取了 os02g10 的驱动程序: https://github.com/Shaggy013/kernel-5.10 我以补丁的形式添加了驱动程序。 我的设备树如下所示: csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; 我修改了相机驱动程序和 mxc_mipi-csi.c 的探测函数,mx6s-csi.c 之前我遇到过两次格式匹配错误,但我添加了 mx6s-csi { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } 并添加到 mxc_mipi-csi.c { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } v4l2 API 工作正常,没有错误。以下是我获取图片的命令 v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw 结果以及我的调试信息 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 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) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) 之后什么都不会发生,只有等待、等待,什么也不会发生。 我用20MHz示波器观察不到MIPI DATA和MIPI CLK线上的任何信号。(我知道带宽很低,但对于数据线路来说,任何变化都应该能被察觉,然而却一片寂静。) 我不确定clk节点是否正确,也许没有与mipi_csi时钟名称匹配的&clk节点。有人用过吗? 我能做些什么 ? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM 您好,您可以使用我们已向上游提交的 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: Camera sensor os02g10 MIPI CSI for IMX8MM 我成功了。 .bpp必须等于 2 但主要问题出在硬件上。
查看全文
Camera sensor os02g10 MIPI CSI for IMX8MM Hi all. I got the driver for os02g10 from: https://github.com/Shaggy013/kernel-5.10 I added driver as a patch. My DeviceTree looks that: csi1_bridge: csi1_bridge@32e20000 { compatible = "fsl,imx8mm-csi", "fsl,imx8mq-csi", "fsl,imx6s-csi"; reg = <0x32e20000 0x1000>; interrupts = ; clocks = <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_CSI1_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "disp-axi", "csi_mclk", "disp_dcic"; power-domains = <&dispmix_pd>; status = "disabled"; }; mipi_csi_1: mipi_csi@32e30000 { compatible = "fsl,imx8mm-mipi-csi"; reg = <0x32e30000 0x1000>; interrupts = ; clock-frequency = <360000000>; clocks = <&clk IMX8MM_CLK_CSI1_CORE>, <&clk IMX8MM_CLK_CSI1_PHY_REF>, <&clk IMX8MM_CLK_DISP_AXI_ROOT>, <&clk IMX8MM_CLK_DISP_APB_ROOT>; clock-names = "mipi_clk", "phy_clk", "disp_axi", "disp_apb"; bus-width = <2>; resets = <&mipi_csi_resets>; power-domains = <&mipi_pd>; status = "disabled"; }; os02g10: os02g10@3c { compatible = "ovti,os02g10"; reg = <0x3c>; // spec (manual) says that I2c addres is 0x3d status = "okay"; pinctrl-names = "rockchip,camera_default", "rockchip,camera_sleep"; pinctrl-0 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; pinctrl-1 = <&pinctrl_csi_pwdn>, <&pinctrl_csi_rst>, <&pinctrl_mux_oe>; csi_id = <0>; pwdn-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; mux-gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; mclk = <24000000>; mclk_source = <0>; rockchip,camera-module-index = <1>; rockchip,camera-module-facing = "back"; rockchip,camera-module-name = "OS02G10 camera"; rockchip,camera-module-lens-name = "1//2.9 inch 15*"; rockchip,camera-hdr-mode = <0>; // kernel-5.10\include\uapi\linux\rk-camera-module.h:307 (enum rkmodule_hdr_mode) mipi_csi; port { os02g10_ep: endpoint { remote-endpoint = <&mipi1_sensor_ep>; }; }; }; }; &csi1_bridge { fsl,mipi-mode; status = "okay"; port { csi1_ep: endpoint { remote-endpoint = <&csi1_mipi_ep>; }; }; }; &mipi_csi_1 { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; mipi1_sensor_ep: endpoint@1 { reg = <1>; remote-endpoint = <&os02g10_ep>; data-lanes = <2>; csis-hs-settle = <13>; csis-clk-settle = <2>; csis-wclk; }; csi1_mipi_ep: endpoint@2 { reg = <2>; remote-endpoint = <&csi1_ep>; }; }; }; &clk { init-on-array = ; }; I modified probe function for camera driver and for mxc_mipi-csi.c, mx6s-csi.c Before I had 2 times format match error but I added to the mx6s-csi { .name = "RAWRGB10 (SBGGR10)", .fourcc = V4L2_PIX_FMT_SBGGR10, .pixelformat = V4L2_PIX_FMT_SBGGR10, .mbus_code = MEDIA_BUS_FMT_SBGGR10_1X10, .bpp = 1, } and added to mxc_mipi-csi.c { .code = MEDIA_BUS_FMT_SBGGR10_1X10, .fmt_reg = MIPI_CSIS_ISPCFG_FMT_RAW10, .data_alignment = 8, } and v4l2 API works, there is no error. Below my command to get picture v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw and the result with my debug messages mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_power os02g10 3-003c: in function: os02g10_s_power os02g10 3-003c: in function: os02g10_runtime_resume os02g10 3-003c: in function: __os02g10_power_on os02g10 3-003c: OS02G10_REG_SOFTWARE_RESET mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clk_enable mxc_mipi-csi 32e30000.mipi_csi: enable mipi_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable phy_clk returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_axi returns: 0 mxc_mipi-csi 32e30000.mipi_csi: enable disp_apb returns: 0 VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_fmt VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enum_mbus_code os02g10 3-003c: in function: os02g10_enum_mbus_code mxc_mipi-csi 32e30000.mipi_csi: camera sensor format (media-bus-format.h): 0x3007 mxc_mipi-csi 32e30000.mipi_csi: supported format0 by mipi-csi driver: 0x2008 mxc_mipi-csi 32e30000.mipi_csi: supported format1 by mipi-csi driver: 0x2007 mxc_mipi-csi 32e30000.mipi_csi: supported format2 by mipi-csi driver: 0x3001 mxc_mipi-csi 32e30000.mipi_csi: supported format3 by mipi-csi driver: 0x3007 mx6s-csi 32e20000.csi1_bridge: in function: mx6s_vidioc_enum_fmt_vid_cap - format RAWRGB10 (SBGGR10) Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 1920 Size Image : 2073600 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags: mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_s_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_clear_counters mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_start_stream mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_sw_reset: REG CMN_CTRL 0x32E30004 = 0x00004000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format mxc_mipi-csi.0: fmt: 0x3007, 1920 x 1080 mxc_mipi-csi 32e30000.mipi_csi: in function: __mipi_csis_set_format: REG ISPRESOL_CH0 0x32E30044 = 0x04380780 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_hsync_settle: REG DPHYCTRL 0x32E30024=0x0d800000 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_set_params: REG CMN_CTRL 0x32E30004 = 0x00004104 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG CMN_CTRL 0x32E30004=0x00004105 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) mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_system_enable: REG DPHYCTRL 0x32E30024=0x0d800007 mxc_mipi-csi 32e30000.mipi_csi: in function: mipi_csis_enable_interrupts: REG CSIS_INTMSK 0x32E30010 = 0xf00fffff mxc_mipi-csi.0: --- mipi_csis_start_stream --- mxc_mipi-csi.0: 0x04 CMM CTRL : 0x00004105 mxc_mipi-csi.0: 0x08 CLK CTRL : 0x000f0000 mxc_mipi-csi.0: 0x10 INT MASK0: 0xf00fffff mxc_mipi-csi.0: 0x14 INT SRC0 : 0x00000000 mxc_mipi-csi.0: 0x18 INT MASK1: 0x00000000 mxc_mipi-csi.0: 0x1c INT SRC1 : 0x00000000 mxc_mipi-csi.0: 0x20 PHY STAT : 0x000000f1 mxc_mipi-csi.0: 0x24 PHY CTRL : 0x0d800007 mxc_mipi-csi.0: 0x30 PHY M/S-L: 0x000001f4 mxc_mipi-csi.0: 0x34 PHY M/S-H: 0x00000000 mxc_mipi-csi.0: 0x38 PHY S-CTL: 0x00000000 mxc_mipi-csi.0: 0x3C PHY S-CTH: 0x00000000 mxc_mipi-csi.0: 0x40 ISP CONF : 0x000000ac mxc_mipi-csi.0: 0x44 ISP RESOL: 0x04380780 mxc_mipi-csi.0: 0x48 ISP SYNC : 0x04380780 os02g10 3-003c: in function: os02g10_s_stream os02g10 3-003c: in function: __os02g10_start_stream os02g10 3-003c: in function: __os02g10_start_stream __v4l2_ctrl_handler_setup returns: 0 os02g10 3-003c: in function: os02g10_s_stream: unlock_and_return VIDIOC_STREAMON returned 0 (Success) After that nothing is going to happen, just waiting and waiting and nothing. I can not observe any traffic on MIPI DATA and MIPI CLK lines by 20MHz oscilloscope. (I know the bandwidth is low but for data lines there should be anything seen - any change but there is completely silence)  Im not sure if clk node is correct and maybe there is no match &clk node with mipi_csi clocks by clock names. Has anyone experience with it? What can I do ? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Camera sensor os02g10 MIPI CSI for IMX8MM Hi, you can use our linux upstreamed driver,  we have tested this on i.mx8mp based debix platform.  Here is our driver  https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad Here is our DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- Rutvij  SiliconSignals Re: Camera sensor os02g10 MIPI CSI for IMX8MM I got it to work. .bpp has to be = 2 but main issue was with hardware
查看全文
MFRC630 和 CLRC663 可以互换吗? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 目前我们的产品使用了两颗 CLRC663。它们的阻抗匹配度为 50 欧姆,因此无法利用 CLRC663 的“大电流”能力。展望未来,我们希望节省生产成本,只使用一个 CLRC663(因为它必须支持 14443 和 15693)和一个 MFRC630(第二个读卡器只需要 mifare)。 我已成功在两款产品上测试了我们自己的库,它们似乎都能正常工作,即使是“可变”的uid芯片类型也是如此。 出色地。所以这应该不是软件问题。我猜测MFRC630只是固件版本与CLRC630不同,所以才不支持ISO15693。 封装尺寸和引脚排列相同 我唯一想知道的就是匹配方面的问题。 与 mifare 匹配的 CLRC663 能否在不改变匹配网络的情况下,被即插即用的 MFRC630 取代? NFC 控制器解决方案 NFC 前端解决方案 Re: MFRC630 and CLRC663 Interchangeability? 我假设你已经找到了答案,但为了方便可能看到这条信息的人,这里有一份应用笔记( https://www.nxp.com/docs/en/application-note/AN11256.pdf ),其中指出无需进行任何更改。 我目前也在做一个使用 MFRC630 的项目,但为了开发,我使用的是 CLRC663,因为有相应的开发板。项目完成后,我将在此处发布一篇帖子,确认迁移是否像应用笔记中所说的那样顺利。 Re: MFRC630 and CLRC663 Interchangeability? 你好@jof , 是的,这些集成电路是“调谐”兼容的。虽然芯片相同,但MFRC660仅支持MIFARE技术(ISO 14443,A型),而CLRC663支持所有技术,包括A型、B型、ISO15693等。 BR 托马斯
查看全文
The larger the CCLK for LPC1778 IAP programming, the slower the programming speed. Hello, when I was using the IAP mode of the LPC1778 to burn the program, I found that the larger the CCLK, the slower the burning process became. Most IAP instructions can accept the CCLK parameter, which is described in the manual as: Param3: CPU Clock Frequency (CCLK) in kHz. When debugging the LPC1778, I changed the default CCLK value of the driver from 12000 (12MHz) to 4000 (4MHz), and found that the burning speed actually increased. I tried several values and found that the larger the CCLK parameter, the slower the burning process. What could be the reason for this? What frequency does CCLK refer to? 回复: LPC1778 IAP烧录CCLK越大反而烧录越慢 Hi @BianHaopeng1 In the LPC1778/LPC178x documentation, CCLK refers to the ARM processor clock frequency / Main CPU clock, which is the core CPU clock. The IAP erase command explicitly requires the CPU Clock Frequency (CCLK) to be passed in kHz. The reason is most likely not that "a lower CCLK results in faster physical Flash writes," but rather that the IAP ROM routine treats the CCLK you pass in as the current CPU frequency to calculate the Flash erase/write timings/wait times. Therefore, if the actual CPU is still running at a higher frequency, and you only change the parameter passed to IAP from 12000 to 4000, IAP will generate a shorter latency/timing based on 4 MHz, resulting in faster burning; however, this means that an incorrect clock is being passed to IAP, and the reliability of Flash erase/write, temperature/voltage boundaries, and long-term stability are not guaranteed. The correct approach is to fill in the actual CPU clock speed at the time of the IAP call, in kHz, for the CCLK parameter. BR Harry Re: LPC1778 IAP烧录CCLK越大反而烧录越慢 On the LPC1778, CCLK means the actual CPU core clock frequency (in kHz), not the crystal/XTAL frequency. The IAP bootloader uses the CCLK parameter to calculate its internal timing, particularly for flash programming and UART communication. If the value you provide does not match the MCU’s real CPU clock—or if the clock is configured differently from what the IAP code expects—the timing calculations can become incorrect, causing slower programming or communication. Therefore, make sure the CCLK parameter exactly matches the CPU clock after PLL/divider configuration (e.g., 120 MHz should be specified as 120000 kHz, not 12000).
查看全文
[SPSDK][i.MX95] nxpele 读取公共熔丝失败 您好, 我正在研究如何在 IMX95 19x19 EVK 板上启用安全启动。我已经使用 SPSDK 成功对我的镜像进行了签名。现在,在写入熔丝之前,我想使用 `nxpele` 读取它们,但我遇到了以下错误。 ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-熔丝 --index 136 SPSDK解析错误:SPSDK:响应中的消息大小无效:0x4 请查看调试日志文件:/home/user/.local/state/spsdk/3.11.0/log/debug.log 获取更多信息 ``` 日志中显示以下内容: ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"响应中的消息 SIZE 无效:{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 调试:spsdk:***************************************************(自启动以来已耗时 206 毫秒,spsdk_logger.py:212) DEBUG:spsdk:* SPSDK 调试日志记录已启动 2026-09-03 15:58:44 * (自启动以来耗时 207 毫秒,spsdk_logger.py:213) 调试信息:spsdk:* SPSDK 版本:3.11.0* (自启动以来耗时 207 毫秒,spsdk_logger.py:215) 调试信息:spsdk:* Python 版本:3.14.4* (自启动以来耗时 207 毫秒,spsdk_logger.py:216) 调试:spsdk:* 操作系统版本:Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (自启动以来耗时 208 毫秒,spsdk_logger.py:217) DEBUG:spsdk:* 最后一条命令:['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-熔丝', '--index', '136'] * (自启动以来已过去 208 毫秒,spsdk_logger.py:218) 调试:spsdk:***************************************************(自启动以来已运行 208 毫秒,spsdk_logger.py:219) 跟踪:spsdk.uboot.uboot:Uboot写入 -> 无效(自开始以来已耗时 210 毫秒, __init__ .py:50) 调试:spsdk.uboot.uboot:Uboot读取直到 <- => (自启动以来已过去 210 毫秒,uboot.py:271) 调试:spsdk.uboot.uboot:正在检查如果串口控制台因发送无效命令而打开:“无效\r\n未知命令‘无效’ - 请尝试‘帮助’\r\nu-boot=>”(自启动以来 224 毫秒,uboot.py:209) 调试:spsdk.utils.database:当前数据库指纹哈希值:f0f0598d4e6ae6c755d693693f232e30537cfb3b(自启动以来耗时 226 毫秒,database.py:1967) 调试信息:spsdk.utils.database:已加载从缓存读取数据库:/tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache(自启动以来耗时 226 毫秒,database.py:1976) 调试:spsdk.utils.misc:正在加载从 /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml 读取文本文件(自启动以来耗时 226 毫秒,misc.py:312) 信息:spsdk.ele.ele_comm:ELE通信器在 mimx9596 中使用 92800000 地址处的 196608 B 大小的缓冲区,版本:最新目标。 调试:spsdk.ele.ele_comm:ELE消息 0x92800000 0x30000 0602971788000000 (自启动以来已过去 245 毫秒,ele_comm.py:502) 跟踪:spsdk.uboot.uboot:Uboot写入 -> ele_message 0x92800000 0x30000 0602971788000000 (自开始以来耗时 246 毫秒, __init__ .py:50) 调试:spsdk.uboot.uboot:Uboot读取直到 <- => (自启动以来 246 毫秒,uboot.py:271) 调试:spsdk.ele.ele_comm:原始ELE消息输出: ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (自启动以来 256 毫秒,ele_comm.py:422) 调试:spsdk.ele.ele_comm:已剥离输出:060497e1d600000000000000(自启动以来耗时 256 毫秒,ele_comm.py:460) 调试:spsdk.apps.utils.utils:SPSDK:响应中的消息大小无效:0x4(自启动以来耗时 257 毫秒,utils.py:182) 回溯(最近一次调用): 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py”,第 172 行,包装纸 retval = function(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”,在 safe_main 函数的第 2189 行 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 1631 行,在__call__ 返回 self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 1552 行,主线 rv = self.invoke(ctx) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 2032 行,在 invoke 中 返回 _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 1415 行,在 invoke 中 返回 ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”,第 910 行,在 invoke 中 返回回调函数(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py”,第 46 行,在 new_func 中 返回 f(get_current_context().obj, *args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”,第 575 行,在 cmd_read_common_fuse 中 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”,第 588 行,在 ele_read_common_fuse 中 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py”,第 519 行,在 send_message 函数中 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”,第 1235 行,在 decode_response 中 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”,第 346 行,在 decode_response 中 raise SPSDKParsingError(f"响应中的消息 SIZE 无效:{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 ``` 注:我使用的是 `SPSDK 3.11.0` 我已在 SPSDK 的 GitHub 页面上创建了一个 issue: https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 非常感谢您的帮助。 谢谢! BR, Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 嗨joanxie 我使用的是 Linux 电路板支持包 版本 LF6.18.20_2.0.0 (yocto wrynose) 以下是 nxpele get-info 的输出结果 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 请问您执行此命令时使用的是哪个 EL 固件版本?让我再确认一下。 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 我重现了这个问题,并检查了内部数据库,确认这是一个已存在的问题,将在 spsdk 3.12.0 中修复。
查看全文
S32K3x4EVB-T172 PIL通信エラー/タイムアウト(MBDT S32K3xx 1.4.0使用時) こんにちは、 MATLAB 2023a上で、MBDT S32K3xx (v1.4.0)を使用してPIL S32CTのサンプルを実行してみました。私のセットアップは、S32K3x4EVB-T172をオンボードのOpenSDAポートに接続しています。 試み1(OpenSDA COM): 生成されたターゲットモデルのフラッシュは成功しますが、PIL実行はすぐに以下のエラーで失敗します。 「通信チャネルが開かれませんでした」(添付のエラーメッセージのスクリーンショット参照) 試み2(外部USB2シリアルコンバータ) OpenSDAポートはフラッシュ用に繋いだままにしつつ、外部USB2SirealコネクタをJ44(1からTX、2からRX)に接続してPIL通信を行い、ハードウェア設定でCOMポートを更新しました。モデルは正常にフラッシュしますが、実行時にタイムアウトするとエラーがあります。 エラー:rtiostreamインターフェースからのデータ受信に10秒のタイムアウトが超過しました。この通信障害には複数の原因が考えられます。 あなたは以下のことをすべきです: (a) ターゲットハードウェア構成が正しいか、例えばバイトの順序が正しいかを確認します。 (b) ターゲットアプリケーションがターゲットハードウェア上で動作していることを確認。 (c) アプリケーションの実行時障害(例:例外で割り算、誤ったカスタムコード統合など)の可能性を考慮します。 注(c):実行時の失敗の原因を特定するために、シグナルハンドラとデバッグをサポートするSILの使用を検討してください。 解決策が見つからない場合は、rtw.connectivity.RtIOStreamHostCommunicatorのsetTimeoutRecvSecs方法を使ってタイムアウト値を増加させることを検討してください。   質問: 1.S32K3x4EVB-T172ボードはPIL用に外部USB2Serialコンバータが必要ですか?それとも内蔵のOpenSDAポート経由でPILを動かせますか? 2. 外部USB-シリアル変換が必要な場合、想定されるハードウェアUART構成は具体的にどのようなものですか? 3. 何か設定が抜けているのでしょうか? どんなアドバイスでも大変ありがたく思います! Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 こんにちは、 @PruthviB さん、 さらに調査する前に、なぜ MBDT S32K3xx v1.4.0を使っているのか、もう少し詳しく教えていただけますか?最新のリリースはv1.8.0で、いくつかの修正と改善が含まれています。まずはバージョン1.8.0にアップグレードして、問題が再現するかどうかを確認することをお勧めします。 あなたの構成についてですが、S32K3X4EVB-T172のPIL通信には外部のUSB-シリアル変換器は必須ではありません。オンボードの OpenSDAインターフェースはすでにホスト-ターゲット通信に使われるターゲットUARTへのアクセスを提供しているため、同じUSB接続でプログラミングとPIL通信の両方に使用できます。 OpenSDAはUARTピンに直接アクセスできるため、追加のUSBからシリアルアダプターへの接続は一般的に不要であり、複数のシリアルインターフェースが同時に動作している場合には設定競合を引き起こすことさえあります。 以下のような例を試してみていただけますか: MBDT S32K3xx v1.8.0 オンボードのOpenSDA USB接続のみ ハードウェア設定で選択された、OpenSDAによって公開されるCOMポート よろしくお願いします、 ドラゴス Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 やあ、 @dragostoma OpenSDAのオンボードインターフェースに関するご案内ありがとうございます。 バージョンに関しては、MBDT for BMSではMBDT v1.4.0が推奨バージョンでした。v1.4.0でのPILシミュレーションの実行についてのガイダンスを教えていただけますか? よろしくお願いいたします。 プルートヴィ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 こんにちは、 @PruthviB さん、 確かに、おっしゃる通りです。BMS Toolboxには、S32K3 Toolboxバージョン1.4.0が必要です。最初の議論ではBMSツールボックスについて言及されていなかったので、問題は古いバージョンのS32K3ツールボックスを使用していることに関連していると考えました。 バージョン1.4.0におけるPILシミュレーションに関しては、ワークフローに変更はありません。ツールボックスに付属する例モデルは、 LPUARTインスタンスを使用し、そのRXおよびTX信号がOpenSDAインターフェースを通じてルーティングされるように設定されています。専用の USBからシリアルコンバータを使用する場合は、別のLPUARTインスタンスを設定し、コネクテッドする受信および送信ピンを割り当てる必要があります。 要約すると: OpenSDAインターフェースの使用:ツールボックスに付属する例モデルは、追加の修正なしで動作するはずです。必要なLPUARTインスタンスと関連するRX/TXピンは既に設定済みです。 専用のUSBからシリアルコンバータを使用する場合:コンバーターは対象機器の特定のRXピンおよびTXピンに接続する必要があります。したがって、これらのピンは構成され、利用可能なLPUARTインスタンスにマッピングされる必要があり、それに伴いプロジェクト構成も更新する必要があります。 USB2Serialコンバーターを使用する際は、正しいCOMポートを使用し、J44のRXピンとTXピンが設定されているか確認してください。 どのように機能するか教えてください。 ドラゴス
查看全文
Audifort Review: Does It Really Stop Tinnitus Overnight? Audifort Review: Does It Really Stop Tinnitus Overnight? If you are dealing with a non-stop ringing, buzzing, or clicking sound in your ears every single day, you know how desperate the search for relief can get. When looking for solutions online, you may come across aggressive advertisements for liquid dietary drops like Audifort that imply instant results or overnight relief from tinnitus. The short answer is no: Audifort does NOT stop tinnitus overnight. No oral supplement or natural drop can instantly cure chronic tinnitus or rebuild damaged auditory nerves in 24 hours. However, that does not mean the formula is useless. When evaluated realistically as a natural dietary supplement rather than a miracle cure, Audifort provides supportive nutrients that nourish inner ear blood vessels and calm overactive nerve signals over time. In this Audifort review, we look beyond the sales marketing to analyze how the drops actually work, its core ingredients, realistic expectation timelines, potential side effects, and how to avoid fake online listings.
查看全文
i.MX95 Neutron:同じINT4 LLMで4問中1回答でNPU/CPUの不一致が発生します 概要 i.MX95 上で量子化された ONNX を 1 つ実行します。1 つは CPUExecutionProvider の下、もう 1 つは ニュートロン実行プロバイダー。2つの腕は同じ答えを出しません:2,466対 選択式問題では25.7%が異なる答えを返します(MMLUでは43.6%)。無料で 世代ごとに同じことが起こります - MMLU プロンプトでは、19 世代のうち 13 世代で 異なる回答の手紙。 これは言葉遣いの違いではありません。それはモデルが答える内容の違いです。一方、総合的なベンチマーク精度はわずか-1.8ポイントの変動にとどまった。 私たちは、Neutronランタイムが数値的に何をして生成するかを理解したいのです この大きさが予想されるかどうかも重要です。 設定 あなたの側で再現可能:モデルは表2からUG10166、量子化は 自分だけのレシピ、修正なし。 - ボード:i.MX95 19x19 EVK(IMX95LPD5EVK-19)、LPDDR5 - BSP: LF6.18.2_1.0.0、デバイスツリー imx95-19x19-evk-neutron.dtb - ランタイム:BSP + NeutronExecutionProviderからのONNX Runtime 1.22.0 - Neutron コンバータ:3.1.3 - モデル:meta-llama/Llama-3.2-1B-Instruct - 量子化:NXP/eiq-olive rev aae820e、 例/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 変換:convert_ort_models_to_neutron.py、CPU Armのモデルに適用されます。onnx - 環境: NEUTRON_CMA_512SLOTS=6 両方のArmは1つの量子化されたモデルから来ています。NPUアームはそのモデルを通過させるものです convert_ort_models_to_neutron.py。ソースのSHA-256を記録します - グラフ と 外部重み - 換算時に測定し、測定のたびに再確認します。 2回目の量子化実行や2回目のエクスポートはありません。 私たちが観察すること 1.4つの項目のうち1つは異なる回答が得られる。 MMLU、ARC-Challenge、PIQAからの2,466組のペアアイテム、0ショット、対数尤度でスコアリング 候補者の継続については、候補者ごとに1つのフォワード、生成なし、サンプリングなし。 各ベンチマークについて、ANSWER が変化した項目の割合、次に、 正確性が変更されました: - MMLU(4つの選択肢):回答変更率43.6%、正誤変更率27.1% - ARCチャレンジ(4つの選択肢):回答変更率21.3%、正誤変更率13.3% - PIQA(2つの選択肢):回答変更率9.4%、正誤変更率9.4% - 合計:回答変更率25.7%、正誤変更率17.3% 2つの数字が異なるのは、変更の3分の1(634件中208件)が1つの間違いから移動しているためです。 別の間違った答えへの答え - 正確さを失わせる真の行動の変化 手つかず。PIQAはバイナリであるため、そのような盲点はなく、2つの数値は一致する。 その通り。 2. 自由生成の場合も同様で、答え自体が変わります。 プロンプト数50、貪欲解読、トークン数64。MMLUプロンプトでは期待される出力が始まります 回答文字を含んで、その答えは世代から直接読み取ることができます (n = 19): - 両Arm間で異なる回答文字:19件中13件 - CPUで正解:19中7 - Neutronで正解:19題中6題 - 両Armが間違っていて、異なる誤答が出る意見の相違:13回中6回 回答の3分の2が変わったが、点数はほぼ同じだった(7対6)。 サンプル数は少ないので、ここでは例として報告します。上記の2,466項目の測定結果 これは定量的なものです。 以下に、一字一句そのままの例を示します。プロンプトには 4 つの選択肢がリストされており、文字を求められ、 期待される答えは 😧 CPU: " A\n説明: 式 9(9m + 3t) は 81m + 27t と同等です。 正解はAです。 NPU:「C\n正解はCです。」 どちらも間違っているが、その間違い方は異なり、それを記録できるベンチマークスコアは存在しない。 3. 乖離は累積ではなく、最初のフォワードで発生します。 このレター形式では、最初に生成されたトークンが答えであり、生成の 60% が 既に違いが生じているのは、デコードを行う前の、プリフィルパスのみで生成されたトークンである。 ステップ。50のプロンプトすべてにおいて、乖離曲線は急激に上昇した後、平坦化する。84%は トークン4、トークン64による98%。これが初期差分の伝播の様子です 貪欲なデコードの場合、KVキャッシュを通じてエラーが蓄積されることはありません。 4. 集計精度はそれらすべてを隠してしまう。 CPUは50.28%、Neutronは48.50%、-1.78ポイント差、そして 3つのベンチマークは個別に重要です。634項目に限定して 意見は異なっています。CPUは37.1%の確率で正しかったのに対し、Neutronは30.1%、235%の確率で正解です。 決定された項目のうち191、すなわち対称ノイズが50/50となる場合、55/45です。 除外したもの - サイレントCPUフォールバック: ORTプロファイリングレポートでは、80/80 MatMulNBitsが NeutronExecutionProvider、CPU使用率0。部分的な配置はできません。 - 2つの異なるモデル:同じソースファイル、グラフのSHA-256および外部重み コンバージョン時に記録され、得点前に再確認されました。 - サンプリング: 全体を通して貪欲なデコード。温度、トップk、トップpは使用しません。 - 異なる入力:両方のアームが同じアイテムファイルを同じ順序で消費します。 同じ固定シードです。 - 成果物のスコアリング:ボードはトークンごとの対数確率のみを捉えます;すべての決定 ロジックはホスト側でオフラインで動作し、両アームで同じように動作します。 - NPUのラン・トゥ・ランノイズ:同じNeutronセッション内で同じ項目を再生すること ビット同一の対数確率が得られます。NPUアームは再現可能であり、その不一致 それはCPUに対してであり、自分自身に対してではありません。 私たちの質問 これはニュートロンSのINT4経路に期待される挙動でしょうか?もしそうなら、どのようにすべきでしょうか NPU上でのLLM展開を検証し、集計ベンチマーク精度を明確に示します 表面に浮かび上がらない? 私たちは欠陥を想定しているわけではありません。浮動小数点CPUカーネルと 整数のNPU経路は通常であり、どのくらいの大きさを考えているのか知りたいです 通常、そしてどの基準でNEUTRONへのLLMポートを受け入れますか?もし 回答の4分の1が変わるのは期待内であり、それは私たちにとって有益なことです 知っていて、それを中心に設計する。 Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 迅速なご回答ありがとうございます! DS Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM こんにちは、 @DamienSCHNEBELEN さん。 IMX95 NPUはmatmulしか動作できず、NPUでのLLMのパフォーマンスは実際には平均的なレベルです。したがって、あなたが観察した現象は予測可能な範囲内であり、NPU上でLLMモデルを動かすことは推奨しません。 B.R
查看全文
i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, I am using an i.MX RT1064 controller and debugging/flashing through the PEmicro Multilink interface in MCUXpresso IDE. Occasionally, I encounter the attached "PEmicro Connection Assistant" error while attempting to connect to the target. The issue appears to occur randomly; I have not identified any specific software activity, code change, or hardware event that consistently triggers it. What I have observed is that when this error occurs, the controller's boot configuration appears to have changed unexpectedly. In this state, I am unable to flash or debug the device. The only way I have been able to recover is by restoring the boot configuration to its original settings - Internal Flash Mode, after which flashing and debugging work normally again. A few additional details: MCU: i.MX RT1064 Debug Probe: PEmicro Multilink Universal Rev E IDE: MCUXpresso IDE Has anyone encountered a similar issue? I would appreciate any guidance on: What could cause the boot configuration to change unexpectedly. Whether there are known scenarios in which the debugger or application code could affect the boot configuration. Recommended methods to prevent this from happening. Can the boot configuration be changed through software without manual change I've attached a screenshot of the error message for reference. Thank you. i.MXRT 106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, Could you help me with the following questions? Are you using a custom board or the EVK? What version of the SDK and IDE are you using? Have you burned any fuses? You mentioned that you need to restore the boot configuration to internal flash mode—what boot configuration are you currently using? Best Regards, Pablo Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly I am using a custom board, but this issue was also observed on the EVK. SDK Version : 26.03.00 IDE Version : 25.6.136 We haven't burned any fuse. We usually use Internal Boot mode to flash our code and normal operation, but it causes some unexpected issues randomly, so we change it to Serial Download Mode, erase the flash and then change it back to Internal Boot mode before flashing code again. Please find attached image for boot configuration info. Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi @Subhasri_S, The BOOT_MODE register is initialized by sampling the BOOT_MODE0 and BOOT_MODE1 inputs on the rising edge of POR_B. After these inputs are sampled, their subsequent state does not affect the contents of the internal BOOT_MODE register. If BT_FUSE_SEL = 0, the specific boot configuration parameters can be set using the GPIO pins instead of eFuses. Could you help me measure the BOOT_MODE and BT_CFG pins during reset when the issue occurs? Another possible conclusion for this issue is described in the following knowledge base article: Knowledge Base : RT board recovery for debugger connect issues "When the flash contains an app that is abnormal(access memory does not exist, memory is corrupted, misconfiguration of the clocks, etc.), it will cause the board to end up in an unknown state, then the debugger can’t take control over the core. But, when put the core in serial downloader mode, then it will put the core in a known state, this way, the debugger will be able to take control of the core. So, when meeting the debugger issues in the RT board, try to mass erase the external flash in serial download mode, then it will recover the board debugger to a normal situation." Best Regards, Pablo Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly Hi, please find the recorded BOOT_MODE and BOOT_CFG Pin values when the issue occurs.
查看全文
minimal configuration to negotiate higher current limit on USB I have a device that can be powered over USB with an MCXN947 processor on it.  I don't currently have the USB configured, just pulling 5V.  However, I would like to raise the current limit which seems to default to 100mA. What's the minimal configuration I can do to raise the current limit?  In MCUXpresso config tools, I tried setting up USBFS.  It requires at least one interface, so I tried to set up DFU.  I managed to get things to build mostly, but the config tools generate a file timer_queue.c that defines a SysTick_Handler that conflicts with the FreeRTOS port.c SysTick_Handler. 1) Is there something better I can do to try to raise the current limit? 2) If setting up this DFU interface is as good as anything else, how should I resolve conflicts between autogenerated code and the FreeRTOS port? Re: minimal configuration to negotiate higher current limit on USB Hello @robert_hines  Yes, a USB device must declare its required power in the bMaxPower field during USB enumeration. To draw more than 100 mA, I recommend configuring your device as a USB HID or USB CDC device, as these are generally easier to implement than DFU.   Thank you.   BR Alice
查看全文