Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
安装 S32K1XX SDK 您好! 我的问题是,S32K1XX SDK 安装程序无法安装到 S32DS。无论是尝试打开任何示例项目,还是打开 S32 配置工具,都没有检测到任何 SDK。只是为了说明一切是多么空洞: 我从帮助 -> S32DS 扩展和更新中安装了 S32K1XX SDK: 以及帮助 -> 安装新软件 此外,我还下载并安装了 S32_SDK_S32K1xx_RTM_4.0.2 以供外部使用,但似乎无济于事,我还无法将其添加到 S32DS 中。 谁能帮助我们为 S32K144 启动并运行这个环境?目前,我还不知道如何使用这款处理器。 R S32K1系列的S32SDK Re: S32K1XX SDK installation 我通过 updatesite 和将 S32DS 环境更新到最新版本(参见 VaneB 对此主题的评论)设法解决了这个问题。此外,在制作新项目时,请确保项目的 GCC 版本与 SDK 的 GCC 版本相同,否则将无法显示。 Re: S32K1XX SDK installation @r-j1你现在解决这个问题了吗?我现在也遇到了同样的问题。 Re: S32K1XX SDK installation 你好@r-j1 根据您共享的镜像,似乎没有为 S32K1 设备安装任何软件。 下载并安装 S32K1 设备的实时驱动程序 (RTD)。这些可以在 S32K1 实时驱动程序下的汽车软件——S32K1_S32M24x——Cortex-M 实时驱动程序部分中找到。具体来说,您需要下载 DesignStudio_updatesite.zip 文件。 例如,S32K1_S32M24X 实时驱动程序 AUTOSAR R21-11 版本 3.0.0→ SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503_DesignStudio_updatesite.zip. 下载后,通过 S32DS 扩展和更新,选择添加更新站点进行安装。 关于 S32_SDK_S32K1xx_RTM_4.0.2,请注意它只包含在 S32 Design Studio 3.4 S32K1xx Service Pack 1 中。因此,它与 S32DS 3.6 不兼容,也不支持 S32DS 3.6。 BR、VaneB
記事全体を表示
LIN スレーブがオフラインであることを検出するにはどうすればよいでしょうか? S32K144 LINスタック(ARM2.2用S32DS)をベースに、スレーブが存在する場合、LIN マスターはどのようにして問題を検出できますか? Re: How to detect LIN slave offline? ここで、API「l_ifc_read_status」を使用して、特別なフレームの「SUCCESSFULL_TRANSFER」をチェックし、必要な結果を得ます。 Re: How to detect LIN slave offline? ご提案ありがとうございます。CAN診断サービスで解決することもできますが、通常のフレームを使用して解決する方が良いと思います。ファイル「lin.c」で見つかった関数「 lin_lld_timeout_service()」をトレースします。567 行目、「データの一部を受信しましたが完了していません」は「 LIN_LLD_NODATA_TIMEOUT」イベントをトリガーできますが、「データを受信していません」はそれをトリガーできません。この動作は想定内ですか? それとも問題ですか? Re: How to detect LIN slave offline? タイムアウトフラグを取得するための同じ API はありますか?l_ifc_read_status を使用しようとしましたが、スレーブの電源をオフにしても 'error_in_response' フラグが設定されません。 よろしくお願いします。 Re: How to detect LIN slave offline? こんにちは、 はい、ここですでで提供されているように、LIN スタック内でオフラインになっている LIN スレーブを検出します。 - マスターはヘッダーを送信した後、応答を確認します。 - 応答がない場合やエラー (チェックサムなど) がある場合、タイムアウト カウンターが増加/期限切れになります。 - N 回の応答が失われると、スレーブはオフラインとしてマークされます。 - オプションとして、診断フレームを使用してスレーブに ping を実行します。 BR、ペトル Re: How to detect LIN slave offline? LIN マスターは、主に応答タイムアウトを通じて失われたスレーブを検出します。マスターがフレーム ヘッダーを送信し、特定のスレーブからの応答を期待する場合、マスターは定義された時間枠内でスレーブのデータを監視します。タイムアウトが経過する前に応答が受信されない場合、マスターはスレーブが存在しない、または機能していないと判断します。さらに、受信したフレームのチェックサム エラーは、スレーブの欠落を直接示すものではありませんが、CAN 通信の問題を示している可能性があります。より確実なチェックを行うために、マスターは LIN 診断サービス (「識別子による読み取り」など) を利用してスレーブをアクティブにポーリングできます。このような要求に対するCredibleBH の応答がない場合、スレーブが存在しないことがさらに確認されます。S32K144 LIN スタックは通常、これらのタイムアウト メカニズムを処理し、アプリケーションにステータス フラグまたはコールバックを提供します。
記事全体を表示
Import of Simulink created Project to S32DS Currently working with the S32K144 EVB and utilizing MATLAB Model-Based Design (MBD) for code generation, issues are being encountered while trying to import the generated project into S32 Design Studio. Despite following all instructions and references from NXP community forums and official documentation, the project fails to import into the development environment. Other manually created projects can be successfully built, imported, and deployed without any issues, but Simulink-generated projects consistently encounter this problem. Details regarding the issue: MATLAB/Simulink Version: MATLAB 2024a MBD Toolbox Version: v4.2.0 S32 Design Studio Version: S32DS v3.5 Steps taken: Guidelines from community resources have been followed.    The generated ProjectInfo.xml file has been verified. Compatibility between the MBD Toolbox and S32 Design Studio has been checked. How to export Generated Code to S32 Design Studio IDE (applicable for MBDT for MPC5744P v2.0) - NXP Community Re: How to export S32K144 MBDT Generated Code to S32 Design Studio - NXP Community A snapshot highlighting the specific point of the issue is attached for reference. Re: Import of Simulink created Project to S32DS I'm also facing same issue while importing xml file to s32ds. I'm using S32DS version 3.5 and MATLAB R2021b. Someone please help me with this
記事全体を表示
LPC55S36 I3C Slave Speed Limitation Two LPC55S36 boards were connected for I3C communication, with one configured as the I3C Master and the other as the I3C Slave. When the Master’s push-pull baud rate is set to 1.25 Mbps, communication proceeds without issues. However, increasing the baud rate to 2.0 Mbps causes the Slave to fail in receiving data properly, resulting in a NACK response. The question is whether there are any configuration parameters or tuning methods available that would allow the I3C Slave to reliably handle higher baud rates. Note: The sample code being used employs the function I3C_BusMasterDoTransferToI3CDev, which is defined in the fsl_component_i3c_adapter.h header. This function performs a write to the device address followed by a read, even during read operations. In contrast, the SDK example lpcxpresso55s36_i3c_polling_b2b_transfer_master uses the function I3C_MasterTransferBlocking, which performs a pure read operation during reads. Due to this behavioral difference, the latter example (I3C_MasterTransferBlocking) is able to operate correctly at 2.0 Mbps, whereas the former (I3C_BusMasterDoTransferToI3CDev) leads to reception failures at the same baud rate. At even higher baud rates, both approaches result in failed receptions on the Slave side. Re: LPC55S36 I3C Slave Speed Limitation Thank you for the explanation. As you noted, when the speed is too high, the Slave does not have sufficient time to fill the TX FIFO, so it responds with a NACK. Re: LPC55S36 I3C Slave Speed Limitation Hi @bell_huang  I have debugged the slave code. I add one toggle signal. The start address header uses open-drain baudrate (typically less than 2MHz), allowing the target more time to fill the TX FIFO and thereby achieve ACK. However, the repeated start address header uses push-pull baudrate, and if set above 4MHz, the target doesn't have sufficient time to fill the TX FIFO, resulting in NACK. Based on current MCU performance, if we want to achieve higher rates, we need to optimize the target code to accelerate its response speed. BR Harry Re: LPC55S36 I3C Slave Speed Limitation Hi @Harry_Zhang , Thank you for the information about setting the optimization level to O3. After adjusting the Slave configuration, the Master now appears to reach 4 Mbps. (I’m not sure why, but after a Slave reset the Master’s first Read fails, while subsequent Reads succeed.) Could you confirm whether 4 Mbps is indeed the limit on the Slave side? As mentioned earlier, the I3C specification allows up to 12.5 Mbps; even the Building an I3C Sensor Network Using LPC553x/LPC55S3x example operates at 10 Mbps. Re: LPC55S36 I3C Slave Speed Limitation Hi @bell_huang  I have tested it. When the PP Baud is setted to 2M. baudrate_config.i3cPushPullBaud = 2000000; baudrate_config.i3cOpenDrainBaud = 625000; You can try to improve the optimization level of the code. It can work. BR Harry Re: LPC55S36 I3C Slave Speed Limitation As mentioned in the note of my first post: The simple examples in the SDK (such as lpcxpresso55s36_i3c_polling_b2b_transfer_master) use a Single message format, which means: Write: Slave Address (RnW = 0) → Data Read: Slave Address (RnW = 1) → Data However, almost all sensors in the industry (for example, lpcxpresso55s36_i3c_master_read_sensor_icm42688p) use a Combined format, which means: Write: Slave Address (RnW = 0) → Register Address → Data Read: Slave Address (RnW = 0) → Register Address → repeated START → Slave Address (RnW = 1) → Data This explains why your Single message example can reach up to 2.0 Mbps, while my Combined format example can only achieve a maximum of 1.25 Mbps. In lpcxpresso55s36_i3c_polling_b2b_transfer_master, if you modify masterXfer to use the Combined format by adding the following code, it will switch to the Combined format. Then you will observe that the maximum achievable speed drops to 1.25 Mbps. Please refer to the attachment in this reply. masterXfer.subaddress = 0x34; masterXfer.subaddressSize = 1; Additionally, the most important point is that the I3C specification defines the baud rate to support up to 12.5 Mbps. Both Single message (Max = 2.0 Mbps) and Combined format (Max = 1.25 Mbps) are far below this limit. This is why I would like to know if there is any way to improve the Slave’s capability to accept higher baud rates. Re: LPC55S36 I3C Slave Speed Limitation Hi @bell_huang  I tested the lpc5536 SDK i3c example. I changed the EXAMPLE_I3C_PP_BAUDRATE #define EXAMPLE_I3C_PP_BAUDRATE 2000000 It can work. So it  proves that it can work at this speed. BR Harry Re: LPC55S36 I3C Slave Speed Limitation Hi @Harry_Zhang , Test steps: (1) Reset slave board (2) Reset master board Also check out the speed configuration in master code: baudrate_config.i3cPushPullBaud = 1250000; baudrate_config.i3cOpenDrainBaud = 625000; If we modify i3cPushPullBaud to 2000000, then the master cannot read correct data. Re: LPC55S36 I3C Slave Speed Limitation Hi @bell_huang  Can you share your project? So I can reproduce this issue. BR Harry
記事全体を表示
LX2160A RDBの暗号化機能に関するお問い合わせ このメッセージがあなたに届いて、お元気でいらっしゃることを願っております。私は、安全なネットワーク アプリケーション用にLX2160A リファレンス デザイン ボード (RDB)を評価しており、その暗号化機能に関連するいくつかの側面について明確に説明していただければ幸いです。 具体的には、次の点を知りたいです。 暗号化境界: LX2160A SoC 内の暗号化エンジンには、セキュリティ認証フレームワーク (FIPS 140-2 など) に準拠した暗号化境界が定義されていますか? コードとメモリのアイソレータ: 暗号化コードは他のソフトウェア コンポーネントから論理的に分離されていますか? 暗号コードとシステムの残りの部分の間には、何らかの物理的な分離がありますか? SoC は暗号化操作用に専用のメモリを予約していますか? サンドバッギングのサポート: プラットフォームは、サイドチャネル攻撃を軽減するための意図的なバッファリング、難読化、タイミング均等化など、あらゆる種類のサンドバッギングをサポートしていますか? FIPS 140-2 レベル 3 : LX2160A プラットフォームを直接使用して、または外部のセキュア エレメントと統合して、 FIPS 140-2 レベル 3 準拠を達成することは可能ですか? ドキュメント: LX2160A または RDB に実装されている暗号化およびアイソレータメカニズムの詳細を説明したホワイト ペーパー、アプリケーションノート、またはセキュリティ アーキテクチャ ドキュメントはありますか? Re: Inquiry on Cryptographic Features of LX2160A RDB おい。回答は私の質問に満足しましたが、説明が必要です。暗号アルゴリズムはチップ内に実装されていますか、それとも暗号コードを記述して自分でアルゴリズムを実装する必要がある単なる空のアクセラレータですか。DES、3DES、AES-128、AES-256、RSA (748、1024、2048 ビット)、ECDSA (256/384 ビット) を実装したいということを明記しておきます。MD5、SHA、SHA-256、SHA-384、SHA-512。これらはすでにチップ内で利用可能でしょうか、それともソフトウェアで実装するためにコードを書く必要がありますか? Re: Inquiry on Cryptographic Features of LX2160A RDB FSLNISTCAVP.pdfがあります。しかし、私の知る限り、更新情報はありません。 FSLNISTCAVP、NXP ®暗号アクセラレータ向け NIST 暗号アルゴリズム検証プログラム認証 - ホワイトペーパー お客様には、必要な個別の暗号スイートを確認するようご案内しています。LX2160 は LS プロセッサと同じエンジンを使用しているためです。 特定のアルゴリズムにご興味がある場合は、弊社の社内チームに CAN 確認させていただきます。 しかし、これはSECに関係しているので、CASEを作成してください https://support.nxp.com/s/?language=en_US また、NDA が締結されていることを確認してください。 よろしくお願いします。
記事全体を表示
S32K324 コアコード分離 ちょっと、そこ、 S32K324 でデュアルコア機能を有効にして使用する方法を調査しています。理解できない疑問が 2 つあります。 2 つのコアをロック解除して互いに独立して動作させるにはどうすればよいですか?私の理解する限りでは、これらはデフォルトでロックステップ構成で起動し、DCMROF19[LOCKSTEP_EN] ビットによって、ロックステップ構成か分離構成かがわかります。しかし、そのビットは読み取り専用、SO構成内で分離できるポイントはどこにあるのでしょうか? コアは、どのコード フラッシュ領域からコードを読み取るかをどのように認識するのでしょうか?これらは別々の機能を実行する必要があるSO、異なるコード フラッシュ領域に存在する異なるメイン ルーチンが必要です。コードを実行したい指定のコード領域に 1 つのコアでジャンプする必要がありますか、それとも各コアに特定のコード開始アドレスがありますか? 前もって感謝します Re: S32K324 seperate core code こんにちは、 これは非常に便利です。 ブートローダーを実装しており、マルチコアサポートを有効にしたいと考えています。この方法により、Core 0 から Core 1 上のアプリケーションを起動することが可能になります。 ただし、ブートローダが独自のアプリケーションを「ブート」できるようにしたいと考えています。 Core0 が独自のベクター テーブルを再配置し、別のアプリケーションにジャンプすることは可能ですか? 新しい VTOR アドレスをMC_ME->PRTN0_CORE0_ADDR に書き込んで、実行時にアプリケーションにジャンプすることはできないのでしょうか? よろしくお願いいたします。 マシュー Re: S32K324 seperate core code わかっていますが、これが推奨される解決策なのか、それともどこかで構成可能なので、後で生成されたコードによって誤って上書きされる可能性があるのか疑問に思います。 Re: S32K324 seperate core code ソリューション内で説明されているレジスタ アクセス@lukaszadrapaを実行できます。 M1 がまだ非アクティブな間に、M0 コア内にメインがあるとします。 次の呼び出しによって、M1 に自身のメイン関数が実行される場所を通知します。 voind main_on_core_0() { // ここは通常のコードです MC_ME->PRTN0_CORE1_ADDR = (uint32)(&コア1のメイン機能); } 次に、レジスタ アクセスを介して Core 1 を起動するように指示します。 MC_ME->PRTN0_CORE1_PCONF = MC_ME_PRTN0_CORE1_PCONF_CCE_MASK; MC_ME->PRTN0_CORE1_PUPD = MC_ME_PRTN0_CORE1_PUPD_CCUPD_MASK; MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY( 0x5AF0 ); MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY(~0x5AF0); Re: S32K324 seperate core code こんにちは、 ソフトウェアのどの部分が core1 を有効にするのでしょうか?私は S32k322 に取り組んでいますが、RTD 内でこれらのレジスタが使用されるのは startup_cm7.s の EnableCore1 ルーチンだけであるようです。ただし、MULTIPLE_CORE と MULTIPLE_IMAGE の両方が定義されている場合、このコード部分は除外されます。 両方のコアが異なるアプリケーションを実行する場合、M7_1 コアを起動するにはどうすればよいでしょうか?2 番目のコアを起動するために M7_0 から呼び出す CAN RTD 関数はありますか?おそらく、2 番目のコアを実行するために使用する必要がある S32DS の MCAL 構成がいくつかありますか? よろしくお願いします、 スラヴォミール Re: S32K324 seperate core code こんにちは@lukaszadrapa ありがとう!本当に助かりました! Re: S32K324 seperate core code こんにちは@FelixR S32K324 をお持ちの場合は、すでに分離モードになっています。このデバイスはデュアル コアと見なされます。 S32K344 をお持ちの場合は、デフォルトでロック ステップ モードになっており、分離モードで動作するように構成できるSO、実際には S32K324 になります。UTEST フラッシュ内の対応する DCF レコードをプログラミングすることで構成を変更 CAN ます。しかし、前述したように、S32K324 の CASE、これは必要ありません。 S32 Design Studio で S32K324 の新しいプロジェクトを作成すると、2 つのプロジェクトが作成されます。各コアごとに 1 つ。各プロジェクトには独自のリンカー ファイル、独自のスタートアップ ファイルなどがあります。 IVT のブート構成ワードでリセット後にどのコアが自動的に起動するかを定義することができます (S32K3 リファレンス マニュアルの「32.5.1 ブート構成ワード」を参照)。エントリ ポイントのアドレスは IVT で定義されます。各コアには特定のアドレスがあります。この方法で起動されないコアは、次のようなソフトウェアによって起動できます。 MC_ME->PRTN0_CORE1_ADDR = (uint32_t)(vtor); //vtorはベクターテーブルのアドレス MC_ME->PRTN0_CORE1_PCONF = MC_ME_PRTN0_CORE1_PCONF_CCE_MASK; MC_ME->PRTN0_CORE1_PUPD = MC_ME_PRTN0_CORE1_PUPD_CCUPD_MASK; MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY( 0x5AF0); MC_ME->CTL_KEY = MC_ME_CTL_KEY_KEY(~0x5AF0); よろしくお願いいたします。 ルーカス
記事全体を表示
读取 PN7642 寄存器值 你们好 我的问题是,我无法使用 Peripheral+ 视图查看寄存器值(见所附截图)。当我在调试模式下停止控制器时,所有寄存器都是红色的。只有计时器元器件向我显示一些值。什么原因会导致这种情况? (PN7642(开发套件)与 MCUXpresso(v24.12.148、SDK 版本 2.12.5)) 顺祝商祺! 奥利弗 Re: Reading PN7642 Register values 嘿,爱德华多 我已经更新了 SDK(2.15.004),但还是出现同样的问题。 我考虑过时钟问题,但对我来说,这并不是真正的外围设备。它只是引脚的配置寄存器。通过PN76_Sys_WriteRegister()向它们写入没有问题。 是否存在阅读权限问题? 顺祝商祺! 奥利弗 Re: Reading PN7642 Register values 你好@MPEngineering PN7642 有更新的 SDK 版本,请考虑将您正在使用的 SDK 版本升级到最新版本。 根据《MCUXpresso IDE 用户指南》第 14.8 节,当 MCU 上电时,许多外设都不可用,因为它们没有供电/没有时钟。在这种状态下尝试访问外设会失败,外设会以红色显示。某些外设可能部分可用,而不可用部分则再次以红色显示。 Eduardo。
記事全体を表示
Software reset error when adapting TJA1120 driver to linux 5.15, error code -110 I'm having problems with software reset when adapting TJA1120 driver (from Linux 6.6) to Linux 5.15 with error code -110, I'm not sure about the cause as well as I don't know how to fix this problem. I refer to this post NXP_C45_TJA11XX Driver Soft Reset Issue, made changes to nxp_c45_soft_reset, but it has no effect, the code is as follows. static int nxp_c45_soft_reset(struct phy_device *phydev) { int ret; ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_CONTROL, DEVICE_CONTROL_RESET); if (ret) return ret; usleep_range(2000, 2050); return phy_read_mmd_poll_timeout(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_CONTROL, ret, !(ret & DEVICE_CONTROL_RESET), 20000, 240000, true); }: Error. [ 6.188117] sunxi-mdio 4500048.mdio0. sunxi_mdio_probe() BEGIN [ 6.265731] sunxi-mdio 4500048.mdio0. phy id: 0x001bb031, adr: 0x1b, device: 4500048.mdio0-mii:1b, DRIVER: NXP C45 TJA1120 [ 6.278218] sunxi-mdio 4500048.mdio0. sunxi_mdio_probe() SUCCESS [ 47.166283] NXP C45 TJA1120 4500048.mdio0-mii:1b:. nxp_c45_soft_reset failed: -110
記事全体を表示
Software reset error when adapting TJA1120 driver to linux 5.15, error code -110 I'm having problems with software reset when adapting TJA1120 driver (from Linux 6.6) to Linux 5.15 with error code -110, I'm not sure about the cause as well as I don't know how to fix this problem. I refer to this post NXP_C45_TJA11XX Driver Soft Reset Issue, made changes to nxp_c45_soft_reset, but it has no effect, the code is as follows. static int nxp_c45_soft_reset(struct phy_device *phydev) { int ret; ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_CONTROL, DEVICE_CONTROL_RESET); if (ret) return ret; usleep_range(2000, 2050); return phy_read_mmd_poll_timeout(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_CONTROL, ret, !(ret & DEVICE_CONTROL_RESET), 20000, 240000, true); }: Error. [ 6.188117] sunxi-mdio 4500048.mdio0. sunxi_mdio_probe() BEGIN [ 6.265731] sunxi-mdio 4500048.mdio0. phy id: 0x001bb031, adr: 0x1b, device: 4500048.mdio0-mii:1b, DRIVER: NXP C45 TJA1120 [ 6.278218] sunxi-mdio 4500048.mdio0. sunxi_mdio_probe() SUCCESS [ 47.166283] NXP C45 TJA1120 4500048.mdio0-mii:1b:. nxp_c45_soft_reset failed: -110 Re: TJA1120驱动适配linux5.15时出现软件复位错误,错误码-110 Hello, As far as I know, tja1120 is not supported on 5.15. So did you backport the driver from the latest bsp? Is it working? Thanks! Best Regards. Re: TJA1120驱动适配linux5.15时出现软件复位错误,错误码-110 Hello @miipo , I can help only from device point of view. Can you distinguish if the error code has been generated by phy_write_mmd or by phy_read_mmd_poll_timeout ? Have you tried to increase time in usleep_range ? Best regards, Pavel
記事全体を表示
RT1170: グレースケールまたはRAW画像センサでMIPI-CSIを使用する 皆様、 このフォーラムの別のトピックによると、RT1170 の MIPI-CSI2 ペリフェラルはシリコンのバグのため、グレースケールおよび RAW 画像センサをサポートしていません。これは、コンピューター ビジョン アプリケーションなどで MCU を使用する人にとっては大きな問題であるため、このトピックで可能な回避策や解決策について議論すると良いでしょう。 具体的には、NXP の担当者から以下の質問についてコメントをいただけないでしょうか。 RT1170 でグレースケール/RAW8 センサを動作させるための回避策やハックはありますか?追加のハードウェアやソフトウェアのトリックを使用することでも可能でしょうか? このバグはシリコンのFUTUREリビジョンで修正される予定ですか? もし修正されるなら、更新された RT1170 MCU がいつ利用可能になるか、大まかなスケジュールはありますか? もう一度、この問題がいかに深刻であるかを強調したいと思います。これは単なる「不便」ではなく、MCU がコンピューター ビジョンの多くのアプリケーションで使用できなくなることを意味します。本来であれば、MCU はこれらのアプリケーションに最適であるはずです。NXP さん、この問題を適切な重要性を持って扱ってください。 他にも何かヒントや提案があれば、ぜひ聞かせてください!この問題の解決策が見つからない限り、私が取り組んでいる製品は失敗に終わります。 ベスト、マイケル Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors   こんにちは、Michael-partheiさん、 この「嘘」のトリックはうまくいきましたか? Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors RGB モードは動作していますか? Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors こんにちは@michael_parthei MIPI CSI-2 を使用して RAW8 データをキャプチャできましたか?そうでない場合、回避策は見つかりましたか? よろしくお願いいたします。 Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors 親愛なる@kerryzhou様、 MIPI-CSI2 が 14 ビットの生データをサポートするのを妨げていたビデオ MUX バグが、iMXRT1170 で修正されたかどうか教えていただけますか? 親切なフィードバックをお待ちしております。よろしくお願いいたします。 よろしくお願いいたします。 シャイ Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors こんにちは、nxp! この問題に関する最新情報はありますか? rt1176 を使用しており、14 ビットの生データのサポートが必要です。 カメラはRAW形式のみをサポート 回避策は?新しいシリコンリビジョンで修正されますか? Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors こんにちは、 michael_partheiさん、 どういたしまして。 1.あなたのアイデアについては、CAN使用できると思います。RGB モードを使用して生データを受信し、それを表示してみて、結果が正常かどうかに関係なく、最初にテストして、考えを確認することができます。 2. 8ビットグレースケール/RAWイメージセンサについてですが、申し訳ありませんが、前回はこのタイプの変換センサを使用していませんでした。RT1170には既にCSIインターフェース(パラレルインターフェース)が搭載されており、MIPI_CSI2ではありません。 お役に立てれば幸いです! よろしくお願いいたします。 kerry Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors ケリーさん、助けてくれてありがとう!以下の解決策についてご意見をいただければ幸いです。 解像度について「嘘」をついて、8 ビット RAW カメラ センサを備えた RGB モードで MIPI CSI ペリフェラルを使用することは機能しますか?たとえば、カメラ センサが 640 x 480 で 8 ビットのグレースケール値を持っているとします。MCU 上の MIPI CSI ペリフェラルを、320x480 解像度の RGB565 (つまり、ピクセルあたり 2 バイト) を使用するように構成することはできますか?結局、フレームごとに送信されるデータ量は同じになり (実際には、画像行ごとに同じ量になります)、MIPI CSI ペリフェラルではそのデータの解釈をあまり気にする必要はないと言えます。このアプローチは機能するでしょうか、それとも何か見落としているのでしょうか? RT1170 のカメラパラレルインターフェースは、8 ビットグレースケール/RAW イメージセンサをサポートしていますか?STMIPID02 のような専用の MIPI CSI からパラレルへのコンバーター IC を使用した経験はありますか?このようなブリッジとして機能し、RT1170 で動作することが確認されている他のチップをお勧めいただけますか? ベスト、マイケル Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors こんにちは、 michael_partheiさん 新しい質問を投稿していただきありがとうございます。 今日は、それを社内で再度確認するお手伝いをさせていただきます。 RT1170 はビデオ MUX バグのため、MIPI-CSI2 は生データをサポートできず、現時点では回避策はありません。 お客様が生データ方法を使用したい場合は、 mipi-csi の代わりにパラレル CSI インターフェースを使用できます。 今のところ、RT1170 にはまだ修正計画がありませんが、次の RT バージョンでは修正される可能性があります。 ところで、NXPについて製品を設計するときに、これらの問題に遭遇したことがありますか? はい、そうであれば、NXPについてと製品情報を使用してアカウントを作成し、NXP の内部CASEを作成することをお勧めします。その後、私が内部で報告するのを手伝います。この投稿では、3 番目の部分の電子メールを使用するだけです。 CASE作成プロセス: 1. 以下のサポートサイトを開き、中央の青い「チケットへ移動」をクリックします。 http://www.nxp.com/support/support:SUPPORTHOME 2. 次にログインを求められます。アカウントがない場合は、まずビジネス用メールで登録してください。 3. ログイン後、中央の「新しいCASEを作成」ボタンをクリックして、質問を送信してください。 ご注意ください、NXPについてメールをご利用ください。 よろしくお願いいたします。 kerry Re: RT1170: Using MIPI-CSI with grayscale or raw image sensors マイケル、 私もこの NXP MCU RT1170 に興味があり、AR1335 をこれと一緒に使用できるソリューションがあることを期待しています。 皆さん、希望はありますか?
記事全体を表示
TJA1120 ドライバを Linux 5.15 に適合させるときにソフトウェア リセット エラーが発生しました (エラー コード -110)。 TJA1120ドライバ(Linux 6.6用)をLinux 5.15に適用する際に、エラーコード-110のソフトウェアリセット問題が発生しました。原因と解決方法がわかりません。 こちらの投稿「NXP_C45_TJA11XX ドライバのソフトリセット問題」を参考に、nxp_c45_soft_reset を修正しましたが、うまくいきませんでした。コードは以下の通りです。 static int nxp_c45_soft_reset(struct phy_device *phydev) { int ret; ret = phy_write_mmd(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_CONTROL, DEVICE_CONTROL_RESET); if (ret) return ret; usleep_range(2000, 2050); return phy_read_mmd_poll_timeout(phydev, MDIO_MMD_VEND1, VEND1_DEVICE_CONTROL, ret, !(ret & DEVICE_CONTROL_RESET), 20000, 240000, true); }: エラーメッセージ: [6.188117] sunxi-mdio 4500048.mdio0:sunxi_mdio_probe() 開始 [6.265731] sunxi-mdio 4500048.mdio0:PHY ID: 0x001bb031、アドレス: 0x1b、デバイス: 4500048.mdio0-mii:1b、ドライバー: NXP C45 TJA1120 [6.278218] sunxi-mdio 4500048.mdio0:sunxi_mdio_probe() 成功 [ 47.166283] NXP C45 TJA1120 4500048.mdio0-mii:1b:nxp_c45_soft_reset 失敗: -110 Re: TJA1120驱动适配linux5.15时出现软件复位错误,错误码-110 こんにちは、 私の知る限り、tja1120 は 5.15 ではサポートされていません。それで、最新の BSP からドライバをバックポートしましたか?動作していますか? よろしくお願いします! よろしくお願いいたします。 Re: TJA1120驱动适配linux5.15时出现软件复位错误,错误码-110 こんにちは@miipoさん、 私がサポートできるのはデバイスの観点からのみです。 エラー コードが phy_write_mmd によって生成されたのか、それとも phy_read_mmd_poll_timeout によって生成されたのかをCAN区別できますか? usleep_range の時間を増やしてみたことはありますか? よろしくお願いいたします。 パベル
記事全体を表示
返回 HSE_SRV_RSP_INVALID_PARAM S32K314 集成 "Crypto_43_HSE_TS_T40D34M50I0R0" 之后,调用函数 " "Crypto_43_HSE_Exts_FormatKeyCatalogs""加密密钥目录 Crypto_43_HSE_KeyElementSet" 返回 HSE_SRV_RSP_INVALID_PARAM。可能的原因是什么?此外,我确认 Crypto 使用的所有 RAM 都配置为不可缓存。 Re: returns HSE_SRV_RSP_INVALID_PARAM 顺便提一句,我可以告诉你,我在尝试加载 AES 密钥时并没有实际使用 SHE 密钥。 Re: returns HSE_SRV_RSP_INVALID_PARAM 您好, ,我在 S32K312 上遇到了与驱动程序 Crypto_43_HSE v6.0.0 (Crypto_43_HSE_TS_T40D34M60I0R0) 完全相同的问题。 我成功格式化了密钥目录,可以看到 HSE 状态报告为 0x0B60,因此 CUST_DEL 应该处于激活状态。 在 NvM 和 Ram 密钥目录中,我有以下配置: 但我得到 当我尝试使用 KeyElementSet 来初始化键时,出现了 HSE_SRV_RSP_INVALID_PARAM。 Re: returns HSE_SRV_RSP_INVALID_PARAM 感谢您的帮助。问题解决了!非常感谢。 Re: returns HSE_SRV_RSP_INVALID_PARAM 感谢您的回复;我附上了 EB 配置文件和一些截图 Re: returns HSE_SRV_RSP_INVALID_PARAM 生命周期没有问题。您的设备仍在 CUST_DEL 中。 能否告诉我 NVM 和 RAM 目录是如何定义的? Re: returns HSE_SRV_RSP_INVALID_PARAM 谢谢您的答复。根据这张内存截图,您能找出任何问题吗? Re: returns HSE_SRV_RSP_INVALID_PARAM 你好@hangwu 很抱歉延迟回复。 您还处于 CUST_DEL 生命周期吗?要确认这一点,最简单的办法是请将 0x1B00_0220 - 0x1B00_026F 处的内存截图发给我。 目录只能在 CUST_DEL 生命周期中格式化,因此这可能是根本原因。下一个失败的命令(keyelementset......)可能只是目录未格式化的结果。 此致, Lukas returns HSE_SRV_RSP_INVALID_PARAM 由于项目限制,我无法提供完整的可运行项目。以下是两个主要源文件。我集成了"S32K3XX_S32M27x_RTD_R21-11_5.0.0_P08"RTD 套餐。EB 配置严格如下: " \S32K3XX_S32M27x_RTD_R21-11_5.0.0_P08\eclipse\plugins\Crypto_43_HSE_TS_T40D34M50I0R0\examples\EBT\S32K3XX" 。 我测试了随机数生成、哈希值、UpdateFw、GetFwVersion 和其他服务,所有工作都正常。然而 "Crypto_43_HSE_Exts_FormatKeyCatalogs" "Crypto_43_HSE_KeyElementSet" "Crypto_43_HSE_KeySetValid" "Crypto_43_HSE_ProcessJob" 全部返回"HSE_SRV_RSP_INVALID_PARAM" 。 我发现HSE_STATUS_INSTALL_OK 位被清零,于是尝试调用 FormatKey,但失败了。 Re: returns HSE_SRV_RSP_INVALID_PARAM 你好@hangwu 能否分享一些简单的项目来重现该问题? 此致, Lukas
記事全体を表示
s32kがopenOCDをサポートしている場合 こんにちは皆さん S32K シリーズ (S32K144 や S32K344 など) が openOCD をサポートしているかどうかを知りたいです。サポートされている場合、これらの S32K の cfg ファイルはどこで見つかりますか? Re: if s32k support openOCD 私のボードの s32k144 では、 「s32k.cfg」を使用できるでしょうか? 私のopenocdのバージョンは「Open On-Chip Debugger 0.12.0+dev-snapshot (2025-07-16-14:15)」です Re: if s32k support openOCD こんにちは@rtzeropti OpenOCD Web サイトには、S32K デバイスの公式サポートに関する情報はありません。 サポートを求めるには、OpenOCD コミュニティが最適です。 BR ヴェインB Re: if s32k support openOCD 私も同じ質問があります。CMSIS-DAP デバッガーをどのようにサポートすればよいのでしょうか?
記事全体を表示
有 G2D 问题的 YUV 到 RG 色彩转换 你好! 我们正在尝试将使用libuvc(USB摄像头)捕获的YUV帧转换为RGB,但我们无法获得正确的颜色。 libuvc 提供的帧格式是 YUV422(根据标题): enum uvc_frame_format { .... UVC_FRAME_FORMAT_COMPRESSED, /** YUYV/YUV2/YUV422: YUV encoding with one luminance value per pixel and * one UV (chrominance) pair for every two pixels. */ 尺寸为 1920x1024,跨度为 3840(1920*2) 我们用来转换颜色的代码是 cv::Mat ConvertFrame(uvc_frame_t *frame, int inputFormat=G2D_YUYV){ void *G2D_Handler=NULL; if (g2d_open(&G2D_Handler)!=0){ puts("G2D_Start: Error opening g2d device"); }; int size = frame->data_bytes; struct g2d_buf *srcM = g2d_alloc (size,1); struct g2d_buf *dstM = g2d_alloc (frame->width * frame->height * 3,1); memcpy(srcM->buf_vaddr, frame->data, size); struct g2d_surface src,dst; src.planes[0] = srcM->buf_paddr; src.planes[1] = 0; //srcM->buf_paddr; src.planes[2] = 0; //srcM->buf_paddr; src.left = 0; src.top = 0; src.right = frame->width; src.bottom = frame->height; src.stride = frame->step; src.width = frame->width; src.height = frame->height; src.rot = G2D_ROTATION_0; src.format = inputFormat; cv::Mat out(frame->height, frame->width, CV_8UC3, dstM->buf_vaddr ); dst.planes[0] = dstM->buf_paddr; dst.left = 0; dst.top = 0; dst.right = out.cols; dst.bottom = out.rows; dst.stride = out.step1(); dst.width = out.cols; dst.height = out.rows; dst.rot = G2D_ROTATION_0; dst.format = G2D_RGB888 ; int r = g2d_blit(G2D_Handler, &src, &dst); if (r!=0) puts("convertFrame :: ERROR g2d_blit"); r=g2d_finish(G2D_Handler); if (r!=0) puts("convertFrame :: ERROR g2d_finish"); char name[128]; snprintf(name,128,"g2dOutput_%d.png", inputFormat ); cv::imwrite(name,out); g2d_free (srcM); return out; } 如果使用 inputFormat = G2D_YUYV,我们可以得到更好的结果,但从附图中可以看出,这远远不够正确。 谁能告诉我们如何解决这个问题? 提前感谢! 图形与显示 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux 多媒体 Re: YUV to RG color conversion with G2D problem 我有了突破。 i.MX 图形用户指南》指出 ” 在 i.MX 6(i.MX 6Quad Plus 除外)上,RGB 步幅对齐为 16 字节,在 i.MX 6Quad Plus、i.MX 7ULP 和 i.MX 8 系列设备上,无论是源表面还是目标表面,RGB 步幅 对齐均为 1 像素。 ” 尽管我使用的是 i.mx8MP 而且应该不需要步幅对齐,但我还是将步幅值更改为 16 字节对齐,g2d 操作(YUYV 到 RGB888)成功了! 令人讨厌的是,我的应用程序现在需要处理额外的步长。再说一遍,在 Kirkstone 上不需要这种步幅对齐(特别是这个版本的 yocto 清单—— imx-5.15.52-2.1.0.xml:为 L5.15.52-2.1.0 版本添加清单 [YOCIM... · nxp-imx /imx-manifest @842ad7b) Re: YUV to RG color conversion with G2D problem 差不多是这样 g2d_surface srcSurface; g2d_surface dstSurface; srcSurface.format = G2D_YUYV; srcSurface.left = 0; srcSurface.right = 1920; srcSurface.top = 0; srcSurface.bottom = 1080; srcSurface.stride = 1920; srcSurface.width = 1920; srcSurface.height = 1080; srcSurface.blendfunc = G2D_ZERO; srcSurface.global_alpha = 0; srcSurface.clrcolor = 0; srcSurface.rot = G2D_ROTATION_0; srcSurface->planes[0] = src_g2d_buf->buf_paddr; srcSurface->planes[1] = 0; srcSurface->planes[2] = 0; dstSurface.format = G2D_RGB888; dstSurface.left = 0; dstSurface.right = 300; dstSurface.top = 0; dstSurface.bottom = 300; dstSurface.stride = 300; dstSurface.width = 300; dstSurface.height = 300; dstSurface.blendfunc = G2D_ZERO; dstSurface.global_alpha = 0; dstSurface.clrcolor = 0; dstSurface.rot = G2D_ROTATION_0; srcSurface->planes[0] = dst_g2d_buf->buf_paddr; srcSurface->planes[1] = 0; srcSurface->planes[2] = 0; int result = g2d_blit(_handle, src, dest); Re: YUV to RG color conversion with G2D problem 你怎么能在 Kirkstone 上将 YUYV 转换为 RGB888。我永远无法完成这项工作。你会分享代码吗?但是,谢谢 YUYV 到 RGBX8888 可以正常工作,正如我已经在下面说过的那样。也许这对你的应用程序来说没问题,因为你可以忽略 " X " 元器件,因为不在乎。 Re: YUV to RG color conversion with G2D problem 我也在 IMX8M Plus 上使用 G2D。奇怪的是,YUYV 转 RGB888 在 Kirkstone 上运行正常,但在 Scarthgap 上,g2d 库却打印出目标格式无效的错误信息。 有可能解决这个问题吗? Re: YUV to RG color conversion with G2D problem 感谢您的迅速反馈,Ivan, ,我实施了您的解决方案,但我的图像还是坏了(见附件)。我还附上了代码,也许你会发现一些明显的问题。 你使用的是什么 CPU? 不清楚您为什么要 src.bottom = height/2; src.height = height/2; Thx Re: YUV to RG color conversion with G2D problem 大家好 是的,我已经解决了这个问题: 这只是所用尺寸的问题。 void *G2D::convert(void *imageBuffer, int width, int height){ int size = width * height *2; struct g2d_surface src,dst; src.planes[0] = srcM->buf_paddr; src.planes[1] = 0; src.planes[2] = 0; src.left = 0; src.top = 0; src.right = width; src.bottom = height/2; src.stride = width *2; src.width = width; src.height = height/2; src.rot = G2D_ROTATION_0; src.format = G2D_YUYV; dst.planes[0] = dstM->buf_paddr; dst.left = 0; dst.top = 0; dst.right = width; dst.bottom = height; dst.stride = width ; dst.width = width; dst.height = height; dst.rot = G2D_ROTATION_0; dst.format = G2D_RGB888 ; memcpy(srcM->buf_vaddr, imageBuffer, size); int r = g2d_blit(G2D_Handler, &src, &dst); if (r!=0) puts("convertFrame :: ERROR g2d_blit"); r=g2d_finish(G2D_Handler); if (r!=0) puts("convertFrame :: ERROR g2d_finish"); return dstM->buf_vaddr; } 希望对你有用! Re: YUV to RG color conversion with G2D problem 嗨,伊万, ,你能解决这个问题吗? 我也遇到了同样的问题。 谢谢 Re: YUV to RG color conversion with G2D problem 您好 @Bio_TICFSL, 我也有同样的问题: 在 NXP imx8mp G2D GPU (GC520L) 上,YUYV 转 RGBX 可以正常工作: G2D_YUYV 转 G2D_RGBX8888 可以正常工作 但 YUYV 转 RGB(24 位 RGB888)不能正常工作。我有和上面一样的破损图片。 G2D_YUYV 至 G2D_RGB888 有什么提示可以解决这个问题吗? 谢谢 Re: YUV to RG color conversion with G2D problem 你好@Bio_TICFSL、 是否有与此话题相关的新闻? BR Re: YUV to RG color conversion with G2D problem 你好 ivan_garcia 目前,libg2d 不支持将 YUYV 转换为 BGR。我将与 R&D 团队讨论,以便启用。 此致
記事全体を表示
Secondary boot for XIP-Flash Hi, I would like to enable the Secondary boot functionality of iMXRT1010EVK, after writes '1' to the PERSIST_SECONDARY_BOOT bit of SRC_GPR10 register then make a reset,  it seems not working.. I supposed that the secondary boot image is not placed at the right place as I placed it at the default redundant boot image address 0x60040000, I have no idea if it can work as I also saw a setting of XSPI_FLASH_SEC_IMG_OF FSET that needs to be filled. My question is where I should place the secondary boot image? and are there any register I should set to indicate BootROM to jump? What are necessary steps I should do to boot from Secondary Boot Image? i.MXRT 101x Re: Secondary boot for XIP-Flash Hi, Then it makes sense to make corrections to the documentation to reduce the pain for subsequent engineers:) RT1010 Processor Reference Manual, Rev. 0, 09/2019 (the last avaible for now): - Chapter 9.6.4 Redundant boot image support - Chapter 9.10.2 Enter Bootloader API, Boot image selection field. - Chapter 21.8.14 SRC General Purpose Register 10, PERSIST_SECONDARY_BOOT and PERSIST_REDUNDANT_BOOT fields. Re: Secondary boot for XIP-Flash Hi Calvin Lin, Thanks for your reply. I've confirmed that the Flash Remapping Setting feature is only supported by the RT106x, in another word, the RT1010 doesn't support the feature that jumps to the second image. I've also attached an application note which illustrates the Flash Remapping Setting feature. Have a great day. TIC   ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you!   - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Secondary boot for XIP-Flash Hi Jeremy, My evaluation kit is iMXRT1010EVK, in my test, I imported two MCUxpresso projects( "iled_blinky" and "hello world") from SDK, then completes the procedures listed below: 1. Compile the "hello world" project first for generating the binary image; 2. Using NXP-MCUBootUtility tool to program the binary image at address 0x60040000; 3. Add codes to "iled_blinky" for writing '1' to the PERSIST_SECONDARY_BOOT bit of SRC_GPR10 register; 4. Download the project "iled_blinky" through MCUxpresso with LPC-Link2; 5. Erasing the XIP-Flash address from 0x60000000 to 0x6003FFFF; 6. Press POR button on EVK board. I supposed that as there is no bootable image on address 0x60000000, so BootROM should redirect boot address to 0x60040000 to run the secondary image, but it didn't. As I couldn't find the way writing XSPI_FLASH_SEC_IMG_OFFSET register, so please explain the procedures what I missed. thank you. Re: Secondary boot for XIP-Flash Hi Calvin Lin, Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you. I'd like to know more information about the phenomenon, so whether you can introduce the process of secondary boot testing you did, and it may help me to figure it out. Looking forward to your reply. Have a great day. TIC   ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you!   - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
記事全体を表示
S32Gマルチコアアプリケーションの実行に失敗しました AN13750に基づいて開発環境をセットアップする際、次の図に示す手順に従いました。 以下の問題が発生しています: root@s32g274ardb2:~# echo 1 > /sys/kernel/ipc-shm-sample-instance1/ping root@s32g274ardb2:~# dmesg | grep ipc-shm-sample_multi-instance [ 63.397060] ipc-shm-sample_multi-instance: インスタンス 0 でデモを開始しています... [ 63.397085] ipc-shm-sample_multi-instance: INST0 ch 0 >> 19 バイト: 送信メッセージ: 1 [ 63.397098] ipc-shm-sample_multi-instance: send_data_msg(): インスタンス0のチャネルID 1、サイズ32のバッファを取得できませんでした [ 422.873017] ipc-shm-sample_multi-instance: インスタンス 1 でデモを開始しています... 私のソフトウェアのバージョン: BSP:33.0-5.10.109 ipcf:4.6.0_D2205 これをどう解決すればよいか教えてください ありがとう! Re: S32G multi-core application failed to run 私も同じエラーが出ています ipc-shm-sample: send_data_msg(): チャネルID 1、サイズ 32 のバッファを取得できませんでした Linux 車載 BSP 40と41を使用しましたが、同じエラーが発生しました 私 Re: S32G multi-core application failed to run こんにちは、 lion_6 情報をいただきありがとうございます。 同様のチケットを投稿していることを確認しました。お客様へのサポート提供を容易にするため。このチケットであなたをサポートします。( S32G2 S32G-VNP-RDB2 でアプリケーションを実行するとエラーが発生する - NXP コミュニティ) BR ジョーイ
記事全体を表示
k32l2b31 writing to LPUART1->STAT |= (1<<25) cause semihost_hardfault i want to activate LIN Break detection on k32l2b31  bit LKDE must be set in status register i try LPUART1->STAT |= (1<<25) but it appear "semihost_hardfault" on debug who knows why ? best regards Re: k32l2b31 writing to LPUART1->STAT |= (1<<25) cause semihost_hardfault The "semihost_hardfault" when activating LIN break detection on the K32L2B31 most certainly suggests a problem that extends beyond simply setting the 'LKDE' bit. Possible causes include faulty LPUART clock configuration, accessing the peripheral before proper activation, memory access violations caused by an invalid base address, wrongly configured LIN break interrupts without a handler, or problems with the debugger/semihosting configuration. Before enabling LIN break detection, debug the initialization code, validate the base address, step through code with a debugger, check interrupts, simplify your code, and reference the datasheet to guarantee proper peripheral configuration. pa turnpike ez pass login Re: k32l2b31 writing to LPUART1->STAT |= (1<<25) cause semihost_hardfault The "semihost_hardfault" when enabling LIN break detection on the K32L2B31 likely indicates a problem beyond just setting the `LKDE` bit. Potential causes include incorrect LPUART clock configuration, accessing the peripheral before proper initialization, memory access violations due to a wrong base address, improperly configured LIN break interrupts without a handler, or issues with the debugger/semihosting setup. Debug by reviewing initialization code, verifying the base address, stepping through code with a debugger, checking interrupts, simplifying your code, and consulting the datasheet to ensure correct peripheral setup before enabling LIN break detection.
記事全体を表示
Ilitek ILI9881C MIPI LCD Panel issue on i.MX93 I am working with a carrier board based on the iMX93, which is connected to a DSI panel. I'm trying to use the ilitek ili9881c driver with specific configurations to get the panel to display correctly, but I have been unsuccessful so far. I do some displays with Weston and modetest. In 2 cas, The panel displays something initially, but then the screen becomes blurry and eventually becomes completely unreadable. Could you please assist me in making it work with the information follow : Panel DSI (https://midasdisplays.com/shop/tft/mdt0500b2ihc-mipi/) with documentation (https://midasdisplays.com/wp-content/uploads/2023/08/MDT0500B2IHC-MIPI.pdf) Driver panel-ilitek-ili9881c for ili9881C IC on linux-imx 6.1.36. Configuration : There are no information about timming configuration on datasheet of Panel then i use the configuration from driver "bananapi,lhr050h41" of  "ilitek ili9881c"; Display timings : static const struct drm_display_mode lhr050h41_default_mode = { .clock = 62000, .hdisplay = 720, .hsync_start = 720 + 10, .hsync_end = 720 + 10 + 20, .htotal = 720 + 10 + 20 + 30, .vdisplay = 1280, .vsync_start = 1280 + 10, .vsync_end = 1280 + 10 + 10, .vtotal = 1280 + 10 + 10 + 20, .width_mm = 62, .height_mm = 110, };   Devicetree : &lcdif { status = "okay"; assigned-clock-rates = <310000000>, <62000000>, <400000000>, <133333333>; // assigned-clock-rates = <372000000>, <62000000>, <400000000>, <133333333>; // assigned-clock-rates = <248000000>, <62000000>, <400000000>, <133333333>; }; &dsi { status = "okay"; #address-cells = <1>; #size-cells = <0>; panel@0 { compatible = "bananapi,lhr050h41", "ilitek,ili9881c"; reg = <0>; power-supply = <&reg_vdd_3v3>; reset-gpios = <&ioexpander_1 1 GPIO_ACTIVE_LOW>; backlight = <&disp_backlight>; width-mm = <62>; height-mm = <110>; port { panel_to_dsi: endpoint { remote-endpoint = <&dsi_to_panel>; }; }; }; ports { port@1 { reg = <1>; dsi_to_panel: endpoint { remote-endpoint = <&panel_to_dsi>; }; }; }; }; &epxp { status = "okay"; }; &dphy { status = "okay"; }; Clock configuration : /* * Fvco = (Fref / rdiv) * (MFI + MFN / MFD) * Fout = Fvco / odiv * The (Fref / rdiv) should be in range 20MHz to 40MHz * The Fvco should be in range 2.5Ghz to 5Ghz */ static const struct imx_fracn_gppll_rate_table fracn_tbl[] = { PLL_FRACN_GP(1700000000U, 141, 0, 0, 1, 2), PLL_FRACN_GP(1400000000U, 175, 0, 0, 1, 3), PLL_FRACN_GP(1039500000U, 173, 25, 100, 1, 4), PLL_FRACN_GP(900000000U, 150, 0, 0, 1, 4), PLL_FRACN_GP(800000000U, 200, 0, 0, 1, 6), PLL_FRACN_GP(650000000U, 162, 50, 100, 0, 6), PLL_FRACN_GP(594000000U, 198, 0, 1, 0, 8), PLL_FRACN_GP(560000000U, 140, 0, 1, 0, 6), PLL_FRACN_GP(520800000U, 217, 0, 1, 1, 10), PLL_FRACN_GP(504000000U, 42, 0, 1, 1, 2), PLL_FRACN_GP(498000000U, 166, 0, 1, 0, 8), PLL_FRACN_GP(484000000U, 121, 0, 1, 0, 6), PLL_FRACN_GP(445333333U, 167, 0, 1, 0, 9), PLL_FRACN_GP(400000000U, 200, 0, 1, 0, 12), PLL_FRACN_GP(393216000U, 163, 84, 100, 0, 10), PLL_FRACN_GP(300000000U, 150, 0, 1, 0, 12), /* ILI9881C Panel */ PLL_FRACN_GP(372000000U, 186, 0, 1, 0, 12), PLL_FRACN_GP(310000000U, 155, 0, 1, 0, 12), PLL_FRACN_GP(248000000U, 124, 0, 1, 0, 12) }; From documentation of imx93: Clocks : tested with 3 clocks x4, x5, x6 cat /sys/kernel/debug/clk/clk_summary Weston :  mopdetest : sudo modetest -M imx-drm -D 0 -a -s 35@33:720x1280 -P 31@33:720x1280 Is my configuration wrong ? #i.MX93 #DSI #ILI9881C Re: Ilitek ILI9881C MIPI LCD Panel issue on i.MX93 can you please share your DTS file  Re: Ilitek ILI9881C MIPI LCD Panel issue on i.MX93 Hello, Please do accept my apologize for the delayed response, the logs provided show no issues, it just shows that the driver is running, from the same logs I see that the driver triggers a sleep thats the only "strange" thing I could see, I could suggest a couple of things to try out if you are willing to try. 1.- Please double check the voltage level of the display that it is correct and working as expected when the failure is seen, specifically the PWM. 2.- Please double check with the display vendor wheter the driver is working as spected, as this driver is not provided by us. Best regards/Saludos, Aldo. Re: Ilitek ILI9881C MIPI LCD Panel issue on i.MX93 Hello Aldo. Thank you for your response. I tested with different clocks, but the issue remains the same: the panel initially displays something, but then the screen becomes blurry and eventually becomes completely unreadable. Strange message in logs: I analyzed the dmesg logs and found an issue with dw-mipi-dsi-imx (see the dmesg log). The fset command doesn't provide the timing information (see the fset command output). New questions : Question 1: How can I resolve this issue? Question 2: Based on the log information below, is there any other issue? 1. Configuration I contacted the panel provider and obtained more information about the timing configuration : Here is my new configuration : linux-imx/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c for 720x1280x60 Hz static const struct drm_display_mode lhr050h41_default_mode = { .clock = 66340, .hdisplay = 720, .hsync_start = 720 + 4, // HACT + HSA .hsync_end = 720 + 4 + 60, // HACT + HSA + HBP .htotal = 720 + 4 + 60 + 60, // HACT + HSA + HBP + HFP .vdisplay = 1280, .vsync_start = 1280 + 4, // VACT + VSA .vsync_end = 1280 + 4 + 16, // VACT + VSA + VBP .vtotal = 1280 + 4 + 16 + 10, // VACT + VSA + VBP + VFP .width_mm = 62, .height_mm = 110, }; Devicetree : &lcdif { status = "okay"; assigned-clock-rates = <331700000>, <66340000>, <400000000>, <133333333>; // assigned-clock-rates = <256360000>, <66340000>, <400000000>, <133333333>; }; &dsi { status = "okay"; #address-cells = <1>; #size-cells = <0>; panel@0 { compatible = "bananapi,lhr050h41", "ilitek,ili9881c"; reg = <0>; power-supply = <&reg_vdd_3v3>; reset-gpios = <&ioexpander_1 1 GPIO_ACTIVE_LOW>; backlight = <&disp_backlight>; width-mm = <62>; height-mm = <110>; port { panel_to_dsi: endpoint { remote-endpoint = <&dsi_to_panel>; }; }; }; ports { port@1 { reg = <1>; dsi_to_panel: endpoint { remote-endpoint = <&panel_to_dsi>; }; }; }; }; &epxp { status = "okay"; }; &dphy { status = "okay"; }; linux-imx/drivers/clk/imx/clk-fracn-gppll.c /* * Fvco = (Fref / rdiv) * (MFI + MFN / MFD) * Fout = Fvco / odiv * The (Fref / rdiv) should be in range 20MHz to 40MHz * The Fvco should be in range 2.5Ghz to 5Ghz */ static const struct imx_fracn_gppll_rate_table fracn_tbl[] = { PLL_FRACN_GP(1700000000U, 141, 0, 0, 1, 2), PLL_FRACN_GP(1400000000U, 175, 0, 0, 1, 3), PLL_FRACN_GP(1039500000U, 173, 25, 100, 1, 4), PLL_FRACN_GP(900000000U, 150, 0, 0, 1, 4), PLL_FRACN_GP(800000000U, 200, 0, 0, 1, 6), PLL_FRACN_GP(650000000U, 162, 50, 100, 0, 6), PLL_FRACN_GP(594000000U, 198, 0, 1, 0, 8), PLL_FRACN_GP(560000000U, 140, 0, 1, 0, 6), PLL_FRACN_GP(520800000U, 217, 0, 1, 1, 10), PLL_FRACN_GP(504000000U, 42, 0, 1, 1, 2), PLL_FRACN_GP(498000000U, 166, 0, 1, 0, 8), PLL_FRACN_GP(484000000U, 121, 0, 1, 0, 6), PLL_FRACN_GP(445333333U, 167, 0, 1, 0, 9), PLL_FRACN_GP(400000000U, 200, 0, 1, 0, 12), PLL_FRACN_GP(393216000U, 163, 84, 100, 0, 10), PLL_FRACN_GP(300000000U, 150, 0, 1, 0, 12), PLL_FRACN_GP(331700000U, 165, 17, 20, 1, 12), // _rate, _mfi, _mfn, _mfd, _rdiv, _odiv PLL_FRACN_GP(256360000U, 128, 9, 50, 1, 12) }; Clock summery from commande: cat /sys/kernel/debug/clk/clk_summary 2. Log a. DMESG  I added some printk in PANEL driver code to check its flow (Log begin with PANEL:) ... [ 1.613373] pwm-backlight pwm-backlight: GPIO lookup for consumer enable [ 1.613387] pwm-backlight pwm-backlight: using device tree for GPIO lookup [ 1.613396] of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/pwm-backlight[0]' [ 1.613407] of_get_named_gpiod_flags: can't parse 'enable-gpio' property of node '/pwm-backlight[0]' [ 1.613417] pwm-backlight pwm-backlight: using lookup tables for GPIO lookup [ 1.613422] pwm-backlight pwm-backlight: No GPIO consumer enable found [ 1.616645] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops) [ 1.624620] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/dsi@4ae10000 to encoder DSI-34: -517 [ 1.634715] dw-mipi-dsi-imx 4ae10000.dsi: [drm:dw_mipi_dsi_imx_bind] *ERROR* failed to attach bridge: -517 [ 1.644614] dw-mipi-dsi-imx 4ae10000.dsi: [drm:dw_mipi_dsi_imx_probe] *ERROR* failed to register component: -517 ... [ 1.805466] pca953x 4-0020: GPIO lookup for consumer reset [ 1.805476] pca953x 4-0020: using device tree for GPIO lookup [ 1.805484] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/soc@0/bus@42000000/i2c@426b0000/gpio@20[0]' [ 1.805501] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/soc@0/bus@42000000/i2c@426b0000/gpio@20[0]' [ 1.805515] pca953x 4-0020: using lookup tables for GPIO lookup [ 1.805519] pca953x 4-0020: No GPIO consumer reset found [ 1.805622] pca953x 4-0020: using no AI [ 1.809964] gpiochip_find_base: found new base at 488 [ 1.809995] gpio gpiochip5: Persistence not supported for GPIO 2 [ 1.810280] gpio-490 (reset): hogged as output/high [ 1.815318] gpio gpiochip5: (4-0020): added GPIO chardev (254:5) [ 1.815325] gpio gpiochip5: registered GPIOs 488 to 495 on 4-0020 [ 1.815517] pca953x 4-0021: GPIO lookup for consumer reset [ 1.815522] pca953x 4-0021: using device tree for GPIO lookup [ 1.815530] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/soc@0/bus@42000000/i2c@426b0000/gpio@21[0]' [ 1.815545] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/soc@0/bus@42000000/i2c@426b0000/gpio@21[0]' [ 1.815559] pca953x 4-0021: using lookup tables for GPIO lookup [ 1.815563] pca953x 4-0021: No GPIO consumer reset found [ 1.815660] pca953x 4-0021: using no AI [ 1.819619] gpiochip_find_base: found new base at 480 ... [ 1.837049] PANEL: ili9881c_dsi_probe [ 1.837165] ili9881c-dsi 4ae10000.dsi.0: GPIO lookup for consumer reset [ 1.840818] ili9881c-dsi 4ae10000.dsi.0: using device tree for GPIO lookup [ 1.840843] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/soc@0/dsi@4ae10000/panel@0[0]' - status (0) [ 1.841045] PANEL: drm_panel_of_backlight [ 1.841053] PANEL: drm_panel_add [ 1.845060] PANEL: mipi_dsi_attach [ 1.849049] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops) [ 1.860484] imx-drm display-subsystem: bound 4ae10000.dsi (ops dw_mipi_dsi_imx_ops) [ 1.868486] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0 [ 1.876358] PANEL: ili9881c_get_modes [ 1.876360] PANEL: drm_mode_duplicate [ 1.880018] PANEL: drm_mode_set_name [ 1.883671] PANEL: mode->type = 0x48 [ 1.887239] PANEL: drm_mode_set_name [ 1.890801] PANEL: return 1 [ 1.937230] PANEL: ili9881c_prepare [ 1.937238] PANEL: regulator_enable -> Sleep 5ms [ 1.953133] ------------[ cut here ]------------ [ 1.953138] WARNING: CPU: 0 PID: 40 at drivers/gpio/gpiolib.c:3140 gpiod_set_value+0x5c/0xcc [ 1.953158] Modules linked in: [ 1.953165] CPU: 0 PID: 40 Comm: kworker/u4:1 Not tainted 6.1.36+gd997ba75bc0a #1 [ 1.953171] Hardware name: BOSCH MOP ENG i.MX93 Sirius board (DT) [ 1.953175] Workqueue: events_unbound deferred_probe_work_func [ 1.953185] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.953190] pc : gpiod_set_value+0x5c/0xcc [ 1.953194] lr : ili9881c_prepare+0x74/0x1e8 [ 1.953202] sp : ffff80000a12b340 [ 1.953205] x29: ffff80000a12b340 x28: ffff0000050cc4b0 x27: 0000000000000000 [ 1.953212] x26: ffff800009396ad0 x25: ffff8000097619f0 x24: 0000000000000028 [ 1.953219] x23: 00000000ffff98ff x22: 00000000ffffff81 x21: 0000000000000000 [ 1.953225] x20: 0000000000000001 x19: ffff0000042cc430 x18: fffffffffffebf10 [ 1.953232] x17: 0000000017b99bc0 x16: 00000000000000c7 x15: 0000000000000030 [ 1.953238] x14: 0000000000000152 x13: 0000000000000000 x12: 0000000000000000 [ 1.953244] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff80000a12b240 [ 1.953251] x8 : ffff00002fd94000 x7 : ffff00002fd9ab40 x6 : 0000000008c2a66c [ 1.953257] x5 : 00000000410fd050 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.953263] x2 : 0000000000000000 x1 : ffff000004bdad00 x0 : 0000000000000001 [ 1.953270] Call trace: [ 1.953273] gpiod_set_value+0x5c/0xcc [ 1.953278] ili9881c_prepare+0x74/0x1e8 [ 1.953282] drm_panel_prepare+0x28/0x40 [ 1.953290] panel_bridge_pre_enable+0x14/0x20 [ 1.953296] drm_atomic_bridge_chain_pre_enable+0x94/0xd0 [ 1.953304] drm_atomic_helper_commit_modeset_enables+0x170/0x26c [ 1.953310] lcdifv3_drm_atomic_commit_tail+0x30/0x70 [ 1.953317] commit_tail+0xa4/0x190 [ 1.953321] drm_atomic_helper_commit+0x164/0x180 [ 1.953327] drm_atomic_commit+0xa8/0xe0 [ 1.953332] drm_client_modeset_commit_atomic+0x210/0x270 [ 1.953338] drm_client_modeset_commit_locked+0x5c/0x18c [ 1.953342] drm_client_modeset_commit+0x30/0x60 [ 1.953346] drm_fb_helper_set_par+0xb8/0x110 [ 1.953351] fbcon_init+0x1fc/0x500 [ 1.953356] visual_init+0xb4/0x104 [ 1.953364] do_bind_con_driver.isra.0+0x1b8/0x390 [ 1.953368] do_take_over_console+0x1a4/0x200 [ 1.953372] do_fbcon_takeover+0x6c/0xe4 [ 1.953376] fbcon_fb_registered+0x1e0/0x1ec [ 1.953380] register_framebuffer+0x1ac/0x2f4 [ 1.953386] __drm_fb_helper_initial_config_and_unlock+0x358/0x540 [ 1.953391] drm_fbdev_client_hotplug+0x150/0x210 [ 1.953395] drm_fbdev_generic_setup+0xb4/0x194 [ 1.953399] imx_drm_bind+0x260/0x2e0 [ 1.953406] try_to_bring_up_aggregate_device+0x164/0x1d0 [ 1.953412] __component_add+0xa4/0x170 [ 1.953416] component_add+0x14/0x20 [ 1.953420] dw_mipi_dsi_imx_probe+0x118/0x254 [ 1.953424] platform_probe+0x68/0xc0 [ 1.953429] really_probe+0xbc/0x2dc [ 1.953433] __driver_probe_device+0x78/0x114 [ 1.953437] driver_probe_device+0x3c/0x15c [ 1.953441] __device_attach_driver+0xb8/0x134 [ 1.953445] bus_for_each_drv+0x7c/0xd4 [ 1.953451] __device_attach+0x9c/0x1a0 [ 1.953455] device_initial_probe+0x14/0x20 [ 1.953459] bus_probe_device+0x98/0xa0 [ 1.953463] deferred_probe_work_func+0x80/0xc0 [ 1.953467] process_one_work+0x1d4/0x330 [ 1.953474] worker_thread+0x220/0x430 [ 1.953478] kthread+0x108/0x10c [ 1.953483] ret_from_fork+0x10/0x20 [ 1.953489] ---[ end trace 0000000000000000 ]--- [ 1.953591] PANEL: gpiod_set_value 1 (reset)-> Sleep 20ms [ 1.981153] ------------[ cut here ]------------ [ 1.981156] WARNING: CPU: 0 PID: 40 at drivers/gpio/gpiolib.c:3140 gpiod_set_value+0x5c/0xcc [ 1.981167] Modules linked in: [ 1.981172] CPU: 0 PID: 40 Comm: kworker/u4:1 Tainted: G W 6.1.36+gd997ba75bc0a #1 [ 1.981176] Hardware name: BOSCH MOP ENG i.MX93 Sirius board (DT) [ 1.981179] Workqueue: events_unbound deferred_probe_work_func [ 1.981185] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.981190] pc : gpiod_set_value+0x5c/0xcc [ 1.981195] lr : ili9881c_prepare+0x94/0x1e8 [ 1.981199] sp : ffff80000a12b340 [ 1.981201] x29: ffff80000a12b340 x28: ffff0000050cc4b0 x27: 0000000000000000 [ 1.981208] x26: ffff800009396ad0 x25: ffff8000097619f0 x24: 0000000000000028 [ 1.981215] x23: 00000000ffff98ff x22: 00000000ffffff81 x21: 0000000000000000 [ 1.981222] x20: 0000000000000000 x19: ffff0000042cc430 x18: fffffffffffecca0 [ 1.981228] x17: 0000000017b99bc0 x16: 00000000000000c7 x15: 0000000000000038 [ 1.981235] x14: 0000000000000022 x13: 0000000000000000 x12: 0000000000000000 [ 1.981241] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff80000a12b240 [ 1.981248] x8 : ffff00002fd94000 x7 : ffff00002fd9ab40 x6 : 00000000ffffffff [ 1.981254] x5 : 00000000410fd050 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.981260] x2 : 0000000000000000 x1 : ffff000004bdad00 x0 : 0000000000000001 [ 1.981266] Call trace: [ 1.981268] gpiod_set_value+0x5c/0xcc [ 1.981273] ili9881c_prepare+0x94/0x1e8 [ 1.981278] drm_panel_prepare+0x28/0x40 [ 1.981284] panel_bridge_pre_enable+0x14/0x20 [ 1.981288] drm_atomic_bridge_chain_pre_enable+0x94/0xd0 [ 1.981295] drm_atomic_helper_commit_modeset_enables+0x170/0x26c [ 1.981301] lcdifv3_drm_atomic_commit_tail+0x30/0x70 [ 1.981306] commit_tail+0xa4/0x190 [ 1.981311] drm_atomic_helper_commit+0x164/0x180 [ 1.981316] drm_atomic_commit+0xa8/0xe0 [ 1.981321] drm_client_modeset_commit_atomic+0x210/0x270 [ 1.981327] drm_client_modeset_commit_locked+0x5c/0x18c [ 1.981331] drm_client_modeset_commit+0x30/0x60 [ 1.981336] drm_fb_helper_set_par+0xb8/0x110 [ 1.981340] fbcon_init+0x1fc/0x500 [ 1.981345] visual_init+0xb4/0x104 [ 1.981351] do_bind_con_driver.isra.0+0x1b8/0x390 [ 1.981355] do_take_over_console+0x1a4/0x200 [ 1.981359] do_fbcon_takeover+0x6c/0xe4 [ 1.981364] fbcon_fb_registered+0x1e0/0x1ec [ 1.981368] register_framebuffer+0x1ac/0x2f4 [ 1.981374] __drm_fb_helper_initial_config_and_unlock+0x358/0x540 [ 1.981379] drm_fbdev_client_hotplug+0x150/0x210 [ 1.981383] drm_fbdev_generic_setup+0xb4/0x194 [ 1.981388] imx_drm_bind+0x260/0x2e0 [ 1.981393] try_to_bring_up_aggregate_device+0x164/0x1d0 [ 1.981397] __component_add+0xa4/0x170 [ 1.981402] component_add+0x14/0x20 [ 1.981406] dw_mipi_dsi_imx_probe+0x118/0x254 [ 1.981409] platform_probe+0x68/0xc0 [ 1.981414] really_probe+0xbc/0x2dc [ 1.981418] __driver_probe_device+0x78/0x114 [ 1.981422] driver_probe_device+0x3c/0x15c [ 1.981426] __device_attach_driver+0xb8/0x134 [ 1.981430] bus_for_each_drv+0x7c/0xd4 [ 1.981436] __device_attach+0x9c/0x1a0 [ 1.981439] device_initial_probe+0x14/0x20 [ 1.981443] bus_probe_device+0x98/0xa0 [ 1.981447] deferred_probe_work_func+0x80/0xc0 [ 1.981451] process_one_work+0x1d4/0x330 [ 1.981456] worker_thread+0x220/0x430 [ 1.981461] kthread+0x108/0x10c [ 1.981464] ret_from_fork+0x10/0x20 [ 1.981470] ---[ end trace 0000000000000000 ]--- [ 1.981560] PANEL: gpiod_set_value 0 (reset)-> Sleep 20ms [ 2.193755] PANEL: ili9881c_switch_page [ 2.194765] PANEL: mipi_dsi_dcs_set_tear_on [ 2.195774] PANEL: mipi_dsi_dcs_exit_sleep_mode [ 2.196783] PANEL: ili9881c_prepare -> OK [ 2.196789] PANEL: ili9881c_enable + sleep 120ms [ 2.401176] PANEL: mipi_dsi_dcs_set_display_on [ 2.402191] PANEL: ili9881c_enable -> OK [ 2.452996] Console: switching to colour frame buffer device 90x80 ... [ 3.458019] mmc1: SDHCI controller on 42860000.mmc [42860000.mmc] using ADMA [ 3.490601] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: none. [ 3.499240] VFS: Mounted root (ext4 filesystem) on device 179:2. [ 3.505721] devtmpfs: mounted [ 3.512373] Freeing unused kernel memory: 3200K [ 3.517072] Run /sbin/init as init process [ 3.521270] with arguments: [ 3.521272] /sbin/init [ 3.521275] with environment: [ 3.521277] HOME=/ [ 3.521279] TERM=linux [ 3.521281] dtb-module=sirius-imx93.dtb [ 3.642688] systemd[1]: systemd 253.1^ running in system mode (+PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP -GCRYPT -GNUTLS -OPENSSL +ACL +BLKID -CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 -BZIP2 -LZ4 -XZ -ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=hybrid) [ 3.674584] systemd[1]: Detected architecture arm64. ... b. WESTON weston ini :  cat /etc/xdg/weston/weston.ini [core] use-g2d=true repaint-window=16 #gbm-format=argb8888 idle-time=0 xwayland=true #enable-overlay-view=1 [shell] [libinput] touchscreen_calibrator=true [output] name=DSI-1 mode=720x1280@60 [screen-share] command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize Weston log Date: 2024-11-21 CET [11:38:49.372] weston 11.0.2 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: 10.0.0-661-ga3c5e63a+ [11:38:49.373] Command line: /usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so [11:38:49.373] OS: Linux, 6.1.36+gd997ba75bc0a, #1 SMP PREEMPT Sun Nov 3 01:09:31 UTC 2024, aarch64 [11:38:49.373] Flight recorder: enabled [11:38:49.374] Using config file '/etc/xdg/weston/weston.ini' [11:38:49.375] Output repaint window is 16 ms maximum. [11:38:49.377] Loading module '/usr/lib/libweston-11/drm-backend.so' [11:38:49.383] initializing drm backend [11:38:49.383] Trying logind launcher... [11:38:49.397] logind: session control granted [11:38:49.405] using /dev/dri/card0 [11:38:49.405] DRM: supports atomic modesetting [11:38:49.405] DRM: does not support GBM modifiers [11:38:49.405] DRM: supports picture aspect ratio [11:38:49.406] Loading module '/usr/lib/libweston-11/g2d-renderer.so' [11:38:49.476] failed to query DRM device from EGL [11:38:49.500] event1 - gpio-keys: is tagged by udev as: Keyboard [11:38:49.500] event1 - gpio-keys: device is a keyboard [11:38:49.508] event2 - Goodix Capacitive TouchScreen: is tagged by udev as: Keyboard Touchscreen [11:38:49.509] event2 - Goodix Capacitive TouchScreen: device is a keyboard [11:38:49.509] event2 - Goodix Capacitive TouchScreen: device is a touch device [11:38:49.517] event0 - 44440000.bbnsm:pwrkey: is tagged by udev as: Keyboard [11:38:49.518] event0 - 44440000.bbnsm:pwrkey: device is a keyboard [11:38:49.552] libinput: configuring device "gpio-keys". [11:38:49.552] Touchscreen - Goodix Capacitive TouchScreen - /sys/devices/platform/soc@0/44000000.bus/44350000.i2c/i2c-1/1-005d/input/input2/event2 [11:38:49.552] libinput: configuring device "Goodix Capacitive TouchScreen". [11:38:49.552] input device event2 has no enabled output associated (none named), skipping calibration for now. [11:38:49.552] libinput: configuring device "44440000.bbnsm:pwrkey". [11:38:49.571] DRM: head 'DSI-1' updated, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown' Supported EOTF modes: SDR [11:38:49.571] DRM: head 'DSI-1' found, connector 35 is connected, EDID make 'unknown', model 'unknown', serial 'unknown' Supported EOTF modes: SDR [11:38:49.571] Registered plugin API 'weston_drm_output_api_v1' of size 32 [11:38:49.571] Color manager: no-op [11:38:49.572] Loading module '/usr/lib/libgbm.so' [11:38:49.572] Failed to load module: /usr/lib/libgbm.so: cannot open shared object file: No such file or directory [11:38:49.572] Output 'DSI-1' attempts EOTF mode: SDR [11:38:49.572] Output 'DSI-1' using color profile: built-in default sRGB SDR profile [11:38:49.577] Initialized backlight for head 'DSI-1', device /sys/class/backlight/pwm-backlight [11:38:49.577] Output DSI-1 (crtc 33) video modes: [email protected], preferred, current, 62.0 MHz [11:38:49.577] associating input device event1 with output DSI-1 (none by udev) [11:38:49.577] associating input device event2 with output DSI-1 (none by udev) [11:38:49.578] associating input device event0 with output DSI-1 (none by udev) [11:38:49.578] Output 'DSI-1' enabled with head(s) DSI-1 [11:38:49.578] Compositor capabilities: arbitrary surface rotation: yes screen capture uses y-flip: yes cursor planes: yes arbitrary resolutions: no view mask clipping: yes explicit sync: yes color operations: no presentation clock: CLOCK_MONOTONIC, id 1 presentation clock resolution: 0.000000001 s [11:38:49.579] Loading module '/usr/lib/weston/desktop-shell.so' [11:38:49.581] Loading module '/usr/lib/libweston-11/xwayland.so' [11:38:49.648] Registered plugin API 'weston_xwayland_v1' of size 32 [11:38:49.648] Registered plugin API 'weston_xwayland_surface_v1' of size 16 [11:38:49.648] xserver listening on display :0 [11:38:49.649] Loading module '/usr/lib/weston/systemd-notify.so' [11:38:49.650] info: add 1 socket(s) provided by systemd [11:38:49.650] launching '/usr/libexec/weston-keyboard' [11:38:49.658] launching '/usr/libexec/weston-desktop-shell' c. Modetest fbset   Modetest Encoders: id crtc type possible crtcs possible clones 34 33 DSI 0x00000001 0x00000001 Connectors: id encoder status name size (mm) modes encoders 35 34 connected DSI-1 62x110 1 34 modes: index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot #0 720x1280 60.22 720 730 750 780 1280 1290 1300 1320 62000 flags: ; type: preferred, driver props: 1 EDID: flags: immutable blob blobs: value: 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 6 non-desktop: flags: immutable range values: 0 1 value: 0 4 TILE: flags: immutable blob blobs: value: CRTCs: id fb pos size 33 36 (0,0) (720x1280) #0 720x1280 60.22 720 730 750 780 1280 1290 1300 1320 62000 flags: ; type: preferred, driver props: 24 VRR_ENABLED: flags: range values: 0 1 value: 0 Planes: id crtc fb CRTC x,y x,y gamma size possible crtcs 31 33 36 0,0 0,0 0 0x00000001 formats: XR24 AR24 RG16 XB24 AB24 AR15 XR15 props: 8 type: flags: immutable enum enums: Overlay=0 Primary=1 Cursor=2 value: 1 32 zpos: flags: immutable range values: 0 0 value: 0 Frame buffers: id size pitch modetest -M imx-drm -D 0 -a -s 35@33:720x1280 -P 31@33:720x1280 setting mode 720x1280-60.22Hz on connectors 35, crtc 33 failed to set gamma: Function not implemented testing 720x1280@XR24 on plane 31, crtc 33 ##################################################################################### STOP MODETEST ##################################################################################### [ 190.526189] PANEL: return 1 [ 358.517178] PANEL: ili9881c_disable [ 358.521022] ------------[ cut here ]------------ [ 358.529113] WARNING: CPU: 0 PID: 371 at drivers/gpio/gpiolib.c:3140 gpiod_set_value+0x5c/0xcc [ 358.537631] Modules linked in: crct10dif_ce polyval_ce polyval_generic layerscape_edac_mod at24 btnxpuart fuse [last unloaded: goodix_ts] [ 358.549975] CPU: 0 PID: 371 Comm: modetest Tainted: G W 6.1.36+gd997ba75bc0a #1 [ 358.558656] Hardware name: BOSCH MOP ENG i.MX93 Sirius board (DT) [ 358.564732] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 358.571682] pc : gpiod_set_value+0x5c/0xcc [ 358.575764] lr : ili9881c_unprepare+0x30/0x50 [ 358.580115] sp : ffff80000b14b930 [ 358.583417] x29: ffff80000b14b930 x28: ffff800009396ad0 x27: ffff0000042cc888 [ 358.590541] x26: ffff0000042cca80 x25: ffff000008262a00 x24: ffff800009761948 [ 358.597665] x23: 0000000000000038 x22: ffff00000506e800 x21: ffff0000042cc8e0 [ 358.604789] x20: 0000000000000001 x19: ffff0000042cc430 x18: 0000000000000006 [ 358.611913] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000b14b490 [ 358.619037] x14: 000000000000032c x13: 000000000000032c x12: 0000000000000001 [ 358.626161] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff80000b14b6b0 [ 358.633285] x8 : ffff0000082b0ac0 x7 : ffff000005193200 x6 : 0000000000000001 [ 358.640409] x5 : 0000000000000000 x4 : ffff0000082b0000 x3 : ffff800009cd1b18 [ 358.647533] x2 : 0000000000000000 x1 : ffff000004bdad00 x0 : 0000000000000001 [ 358.654657] Call trace: [ 358.657093] gpiod_set_value+0x5c/0xcc [ 358.660837] ili9881c_unprepare+0x30/0x50 [ 358.664832] drm_panel_unprepare+0x28/0x40 [ 358.668922] panel_bridge_post_disable+0x14/0x20 [ 358.673524] dw_mipi_dsi_bridge_post_atomic_disable+0x38/0xf0 [ 358.679261] drm_atomic_bridge_chain_post_disable+0x54/0xd0 [ 358.684825] disable_outputs+0x11c/0x2d0 [ 358.688734] drm_atomic_helper_commit_modeset_disables+0x1c/0x50 [ 358.694723] lcdifv3_drm_atomic_commit_tail+0x24/0x70 [ 358.699758] commit_tail+0xa4/0x190 [ 358.703234] drm_atomic_helper_commit+0x164/0x180 [ 358.707922] drm_atomic_commit+0xa8/0xe0 [ 358.711831] drm_mode_atomic_ioctl+0x8d8/0xb50 [ 358.716259] drm_ioctl_kernel+0xc8/0x174 [ 358.720177] drm_ioctl+0x20c/0x420 [ 358.723565] __arm64_sys_ioctl+0xac/0xf0 [ 358.727483] invoke_syscall+0x48/0x114 [ 358.731227] el0_svc_common.constprop.0+0xcc/0xec [ 358.735916] do_el0_svc+0x2c/0xd0 [ 358.739217] el0_svc+0x2c/0x84 [ 358.742268] el0t_64_sync_handler+0xf4/0x120 [ 358.746523] el0t_64_sync+0x18c/0x190 [ 358.750173] ---[ end trace 0000000000000000 ]--- [ 358.755814] PANEL: ili9881c_unprepare [ 358.755873] VDD_3V3: Underflow of regulator enable count [ 358.764992] ------------[ cut here ]------------ [ 358.769604] WARNING: CPU: 1 PID: 371 at drivers/gpio/gpiolib.c:3140 gpiod_set_value+0x5c/0xcc [ 358.778123] Modules linked in: crct10dif_ce polyval_ce polyval_generic layerscape_edac_mod at24 btnxpuart fuse [last unloaded: goodix_ts] [ 358.790640] CPU: 1 PID: 371 Comm: modetest Tainted: G W 6.1.36+gd997ba75bc0a #1 [ 358.799321] Hardware name: BOSCH MOP ENG i.MX93 Sirius board (DT) [ 358.805398] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 358.812347] pc : gpiod_set_value+0x5c/0xcc [ 358.816429] lr : ili9881c_unprepare+0x30/0x50 [ 358.820780] sp : ffff80000b14b950 [ 358.824082] x29: ffff80000b14b950 x28: ffff800009396ad0 x27: ffff0000042cc888 [ 358.831205] x26: ffff0000042cca80 x25: ffff000008262a00 x24: ffff800009761948 [ 358.838329] x23: 0000000000000038 x22: ffff00000506e800 x21: ffff0000042cc8e0 [ 358.845453] x20: 0000000000000001 x19: ffff0000042cc430 x18: 0000000000000006 [ 358.852577] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000b14b430 [ 358.859701] x14: 0000000000000272 x13: 0000000000000000 x12: 0000000000000000 [ 358.866825] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff80000b14b6c0 [ 358.873950] x8 : ffff0000082b0ac0 x7 : ffff00002fdaeb40 x6 : 0000000000000000 [ 358.881073] x5 : ffff00002fda7a18 x4 : ffff0000082b0000 x3 : ffff800009cd1b18 [ 358.888197] x2 : 0000000000000000 x1 : ffff000004bdad00 x0 : 0000000000000001 [ 358.895322] Call trace: [ 358.897757] gpiod_set_value+0x5c/0xcc [ 358.901493] ili9881c_unprepare+0x30/0x50 [ 358.905487] drm_panel_unprepare+0x28/0x40 [ 358.909578] panel_bridge_post_disable+0x14/0x20 [ 358.914189] drm_atomic_bridge_chain_post_disable+0x88/0xd0 [ 358.919753] disable_outputs+0x11c/0x2d0 [ 358.923661] drm_atomic_helper_commit_modeset_disables+0x1c/0x50 [ 358.929650] lcdifv3_drm_atomic_commit_tail+0x24/0x70 [ 358.934685] commit_tail+0xa4/0x190 [ 358.938161] drm_atomic_helper_commit+0x164/0x180 [ 358.942849] drm_atomic_commit+0xa8/0xe0 [ 358.946758] drm_mode_atomic_ioctl+0x8d8/0xb50 [ 358.951187] drm_ioctl_kernel+0xc8/0x174 [ 358.955104] drm_ioctl+0x20c/0x420 [ 358.958493] __arm64_sys_ioctl+0xac/0xf0 [ 358.962410] invoke_syscall+0x48/0x114 [ 358.966154] el0_svc_common.constprop.0+0xcc/0xec [ 358.970843] do_el0_svc+0x2c/0xd0 [ 358.974145] el0_svc+0x2c/0x84 [ 358.977196] el0t_64_sync_handler+0xf4/0x120 [ 358.981459] el0t_64_sync+0x18c/0x190 [ 358.985109] ---[ end trace 0000000000000000 ]--- [ 358.989859] PANEL: ili9881c_unprepare [ 359.053293] PANEL: ili9881c_prepare [ 359.056957] PANEL: regulator_enable -> Sleep 5ms [ 359.073199] ------------[ cut here ]------------ [ 359.082420] WARNING: CPU: 1 PID: 371 at drivers/gpio/gpiolib.c:3140 gpiod_set_value+0x5c/0xcc [ 359.090937] Modules linked in: crct10dif_ce polyval_ce polyval_generic layerscape_edac_mod at24 btnxpuart fuse [last unloaded: goodix_ts] [ 359.103273] CPU: 1 PID: 371 Comm: modetest Tainted: G W 6.1.36+gd997ba75bc0a #1 [ 359.111953] Hardware name: BOSCH MOP ENG i.MX93 Sirius board (DT) [ 359.118030] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 359.124979] pc : gpiod_set_value+0x5c/0xcc [ 359.129061] lr : ili9881c_prepare+0x74/0x1e8 [ 359.133325] sp : ffff80000b14b8f0 [ 359.136627] x29: ffff80000b14b8f0 x28: ffff0000050366b0 x27: 0000000000000000 [ 359.143751] x26: ffff800009396ad0 x25: ffff8000097619f0 x24: 0000000000000028 [ 359.150876] x23: 00000000ffff98ff x22: 00000000ffffff81 x21: 0000000000000000 [ 359.157999] x20: 0000000000000001 x19: ffff0000042cc430 x18: 0000000000000000 [ 359.165123] x17: 0000000000000000 x16: 0000000000000008 x15: 0000000000000000 [ 359.172247] x14: 0000000000000074 x13: 0000000000000000 x12: 0000000000000000 [ 359.179371] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff80000b14b7f0 [ 359.186495] x8 : ffff00002fda8000 x7 : ffff000005192a00 x6 : 00000000000003e8 [ 359.193619] x5 : 00000000410fd050 x4 : 0000000000000000 x3 : 0000000000000000 [ 359.200743] x2 : 0000000000000000 x1 : ffff000004bdad00 x0 : 0000000000000001 [ 359.207868] Call trace: [ 359.210304] gpiod_set_value+0x5c/0xcc [ 359.214047] ili9881c_prepare+0x74/0x1e8 [ 359.217955] drm_panel_prepare+0x28/0x40 [ 359.221873] panel_bridge_pre_enable+0x14/0x20 [ 359.226301] drm_atomic_bridge_chain_pre_enable+0x94/0xd0 [ 359.231692] drm_atomic_helper_commit_modeset_enables+0x170/0x26c [ 359.237776] lcdifv3_drm_atomic_commit_tail+0x30/0x70 [ 359.242821] commit_tail+0xa4/0x190 [ 359.246295] drm_atomic_helper_commit+0x164/0x180 [ 359.250984] drm_atomic_commit+0xa8/0xe0 [ 359.254893] drm_client_modeset_commit_atomic+0x210/0x270 [ 359.260284] drm_client_modeset_commit_locked+0x5c/0x18c [ 359.265579] drm_client_modeset_commit+0x30/0x60 [ 359.270181] drm_fbdev_client_restore+0x6c/0xc0 [ 359.274705] drm_client_dev_restore+0x80/0xe0 [ 359.279047] drm_lastclose+0x74/0x8c [ 359.282617] drm_release+0x10c/0x124 [ 359.286179] __fput+0x70/0x250 [ 359.289230] ____fput+0x10/0x20 [ 359.292359] task_work_run+0x80/0xe0 [ 359.295929] do_notify_resume+0x1e0/0x1280 [ 359.300020] el0_svc+0x74/0x84 [ 359.303071] el0t_64_sync_handler+0xf4/0x120 [ 359.307335] el0t_64_sync+0x18c/0x190 [ 359.310984] ---[ end trace 0000000000000000 ]--- [ 359.316570] PANEL: gpiod_set_value 1 (reset)-> Sleep 20ms [ 359.341194] ------------[ cut here ]------------ [ 359.351199] WARNING: CPU: 0 PID: 371 at drivers/gpio/gpiolib.c:3140 gpiod_set_value+0x5c/0xcc [ 359.359717] Modules linked in: crct10dif_ce polyval_ce polyval_generic layerscape_edac_mod at24 btnxpuart fuse [last unloaded: goodix_ts] [ 359.372061] CPU: 0 PID: 371 Comm: modetest Tainted: G W 6.1.36+gd997ba75bc0a #1 [ 359.380741] Hardware name: BOSCH MOP ENG i.MX93 Sirius board (DT) [ 359.386819] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 359.393767] pc : gpiod_set_value+0x5c/0xcc [ 359.397849] lr : ili9881c_prepare+0x94/0x1e8 [ 359.402113] sp : ffff80000b14b8f0 [ 359.405415] x29: ffff80000b14b8f0 x28: ffff0000050366b0 x27: 0000000000000000 [ 359.412539] x26: ffff800009396ad0 x25: ffff8000097619f0 x24: 0000000000000028 [ 359.419663] x23: 00000000ffff98ff x22: 00000000ffffff81 x21: 0000000000000000 [ 359.426787] x20: 0000000000000000 x19: ffff0000042cc430 x18: ffffffffffff7770 [ 359.433912] x17: 0000000000000000 x16: 0000000000000010 x15: 0000000000000038 [ 359.441035] x14: 00000000000003d6 x13: 0000000000000000 x12: 0000000000000000 [ 359.448159] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff80000b14b7f0 [ 359.455283] x8 : ffff00002fd94000 x7 : ffff000005193200 x6 : 0000000208023479 [ 359.462407] x5 : 00000000410fd050 x4 : 0000000000000000 x3 : 0000000000000000 [ 359.469531] x2 : 0000000000000000 x1 : ffff000004bdad00 x0 : 0000000000000001 [ 359.476656] Call trace: [ 359.479092] gpiod_set_value+0x5c/0xcc [ 359.482835] ili9881c_prepare+0x94/0x1e8 [ 359.486744] drm_panel_prepare+0x28/0x40 [ 359.490661] panel_bridge_pre_enable+0x14/0x20 [ 359.495098] drm_atomic_bridge_chain_pre_enable+0x94/0xd0 [ 359.500489] drm_atomic_helper_commit_modeset_enables+0x170/0x26c [ 359.506573] lcdifv3_drm_atomic_commit_tail+0x30/0x70 [ 359.511617] commit_tail+0xa4/0x190 [ 359.515092] drm_atomic_helper_commit+0x164/0x180 [ 359.519781] drm_atomic_commit+0xa8/0xe0 [ 359.523690] drm_client_modeset_commit_atomic+0x210/0x270 [ 359.529072] drm_client_modeset_commit_locked+0x5c/0x18c [ 359.534367] drm_client_modeset_commit+0x30/0x60 [ 359.538969] drm_fbdev_client_restore+0x6c/0xc0 [ 359.543484] drm_client_dev_restore+0x80/0xe0 [ 359.547826] drm_lastclose+0x74/0x8c [ 359.551388] drm_release+0x10c/0x124 [ 359.554950] __fput+0x70/0x250 [ 359.558001] ____fput+0x10/0x20 [ 359.561130] task_work_run+0x80/0xe0 [ 359.564700] do_notify_resume+0x1e0/0x1280 [ 359.568791] el0_svc+0x74/0x84 [ 359.571842] el0t_64_sync_handler+0xf4/0x120 [ 359.576097] el0t_64_sync+0x18c/0x190 [ 359.579747] ---[ end trace 0000000000000000 ]--- Re: Ilitek ILI9881C MIPI LCD Panel issue on i.MX93 Hello, I see that in your test you tried with different clocks, does the issue persist for the different clock values? Also, is there any strange message in logs? Best regards/saludos, Aldo.
記事全体を表示
RSA 使用示例 我正在开发 s32k344 板,我正在尝试开发一个使用 RSA 的数字签名验证例程。目的是从外部导入 RSA 公钥,用它来验证加载到闪存中的文件的签名。 是否有示例代码说明如何导入 RSA 密钥和执行 RSA 加密操作? 谢谢 Re: RSA usage examples 早上好,我的 K32L2B31VLH0A 也遇到了类似的问题。我想使用2048字节的RSA或ECDS来验证签名,这应该需要更少的资源才能获得相同的结果。我的问题是内存不足,至少恩智浦 mbed TLS 库是这么返回的。该微控制器是否有可用的示例,或者 32 KB RAM 是否不够用?我有四个产品使用了这种微控制器,我需要了解是否需要更换微控制器,或者是否有可行的解决方案。我需要的是能够验证签名固件升级。 Re: RSA usage examples 你好@niccolentini 请参见所附示例。 环境: S32K344 配有 HSE FW 0_2_40_0 S32DS 3.5 RTD 4.0.0HF01 EB 29.0 此致, Lukas
記事全体を表示
SysTickタイマーの実行速度が速すぎます <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MK64FN1M0VLQ12 を使用したデザインがあります。ボードの 1 つが異常な動作をしていますが、他のボードは正常です。 症状としては、SysTick タイマーが明らかに 25 倍速くカウントしているようです。オシロスコープを使用してすべてのクロックを測定したところ(ピン PTA6 に接続)、すべて正しい周波数でした。カウントが速すぎることの証拠は、OSA_TimeDelay() 呼び出しで指定した時間の 1/25 が返されることです。 クロックの構成: EXTAL および XTAL 上の 6.49 MHz 水晶。 PLL は 118.98333 MHz の MCGOUTCLK を生成します。 コアクロック分周比は 1 です。 バスクロック分周比は 2 です。 FlexBus クロック分周器は 4 です。 フラッシュクロック分周比は 8 です。 OSCERCLK (6.49MHz の信号が 2 つの ADC に送られます。 デバッガー (IAR EWARM) を使用して、正常なボードと不良なボードの両方で SysTick 制御およびリロード レジスタを調べました。良いボードと悪いボードの両方で同じ値が表示されます。不良ボード上のすべては正常に動作していますが、MQX 時間遅延がすべて 25 倍短すぎます。 この「不良」ボードは、MCU が交換され、ジャンパー ワイヤがスーパー グルーを使用してボードに接着されるなど、数回にわたって修理されています。このスーパーグルーは JTAG コネクタの下とピンの周囲に塗布されました。MCU が電源投入時にこれらのピンをサンプリングし、インピーダンスがいくらか低いために MCU が文書化されていない動作モードに切り替わる可能性はありますか?リファレンスマニュアルでブートストラップピンに関する記述を検索しましたが、何も見つかりませんでした。 MCU を交換しても問題は解決しませんでした。適切な溶剤でスーパーグルーをすべて除去しても問題は解決しませんでした。 あらゆるご指摘をいただければ幸いです。 Kinetis KシリーズMCU Re: SysTick timer is running too fast なぜこのようなことが起こったのか説明はありますか?現在、S32K344 で MCUBoot を実行しているときに、このクロック速度の問題 (25 倍速すぎる) が発生しています。 Re: SysTick timer is running too fast <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 これまでこの問題に遭遇したことはありません。 OSA_TimeDelay() 関数で設定した値はどうでしょうか? そして、どうすれば予想通りより速く時間遅延を測定できるのか興味があります。 可能であれば、より詳細な情報を提供してもらえますか?ありがとう。 すてきな一日を、 馬慧 ----------------------------------------------------------------------------------------------------------------------- 注: この投稿で質問が解決した場合は、「正解」ボタンをクリックしてください。ありがとう! -----------------------------------------------------------------------------------------------------------------------
記事全体を表示