i.MX6 プロセッサで重大な問題が発生しており、コミュニティからの支援を期待しています。私たちが製造した一連の回路基板のうち、サンプルの約 20% が DCP レジスタにアクセスした後にプロセッサのクラッシュを引き起こします。詳細な背景と情報は以下の通りです。
# 問題の説明
一連の回路基板を製造したところ、サンプルの 20% に同じ欠陥があることが判明しました。
コードが DCP レジスタ (アドレス 0x02284000) にアクセスしようとすると、プロセッサは完全にクラッシュし、JTAG デバッガーでもコアにCANアクセスできなくなります。JTAG は次のエラーを報告します:
「エラー: 0x02284000 でデータが中止されました、dfsr = 0x00000008」。
このエラーが発生すると、プロセッサは実行を再開できません (続行するために「c」が入力されても)。
基板3番と6番に不良があります。これらのボードでは、他のボードと比較して VDD_SNVS_IN 電圧がわずかに高いことが一時的に観察されました。
Error data abortエラーデータ中止
can accessCAN アクセス# ハードウェア環境
回路の電圧ポイントの設計に違いがあるかどうかわからないSO、故障したボードと他のボードの電圧差を測定しました。
-プロセッサ: i.MX6ULL (MCIMX6Y2)
-故障ボード番号: 3番と5番 (故障率約20%)
-通常のボード番号: 残りの80%のボード
# コード複製
問題を再現するには次のコードを使用します。DCP アクセス部分のコメントが解除されると、LED の点滅が停止します (プロセッサがクラッシュします)。
JTAG 経由で DCP に手動でアクセスすると、次のエラーも発生します。
>>> set $R = 0x2284000
>>> p/x *$R #include "MCIMX6Y2.h"
#include "fsl_iomuxc.h"
#include "pad_config.h"
#define LED_PAD_CONFIG_DATA 0x13008
int main()
{
CCM_CCGR1_CG13(0x3);
CCM_CCGR3_CG6(0x3);
IOMUXC_SetPinMux(RGB_RED_LED_IOMUXC,0);
IOMUXC_SetPinConfig(RGB_RED_LED_IOMUXC, LED_PAD_CONFIG_DATA);
GPIO1->GDIR |= (1<<4);
GPIO1->DR |= (1<<4);
while(1)
{
GPIO1->DR &= ~(1<<4); // led on
delay(0xFFFFF);
GPIO1->DR |= (1<<4); // led off
delay(0xFFFFF);
#if 0 // Turn on the code, MCU will be crash
int *ptr = 0x2284000; // This is DCP address
UART1_PrintHex32(*(ptr));
#endif
}
return 0;
}# その他の発見
-通常のボードは、0x2284000 にアクセスすると 0x10000281 を返します (予想どおり)。
-マニュアルIMX6ULLRM.pdfによると、他のすべてのペリフェラルレジスタをテストしましたが、データアボートは発生しませんでした。問題はDCP領域に限定されています。
well (ADC1_HC0)
set $R = 0x2198000
p/x *$R
well (AIPSTZ1_MPR)
set $R = 0x207C000
p/x *$R
......
well (TEMPMON_TEMPSENSE0)
set $R = 0x20C8180
p/x *$R
well (TSC_BASIC_SETTING)
set $R = 0x2040000
p/x *$Rヘルプの要求
- DCPとクロックツリーの関係：DCPモジュールはどのクロックに依存していますか？特別なクロック設定は必要ですか？
-ハードウェア設計上の欠陥：VDD_SNVS_IN 電圧がわずかに高いことが原因でしょうか？他に確認が必要な電圧や信号はありますか？
-ソフトウェア構成: 特別な DCP 初期化手順や保護メカニズムはありますか?
- JTAG デバッグ: DCP アクセス障害後に JTAG 接続を復元する方法はありますか?
私たちのガイドに記載されている必要性に従っていますか:
1. タイミング要件 (2ms) が満たされます。
2. コイン型電池で電源を供給している場合でも、DCP レジスタにアクセスした後にクラッシュが発生します。
1. IMX6ULLIEC.pdf 表 10 の動作範囲は、VDD_SNVS_IN の動作範囲を 2.8 ～ 3.6 V で説明しています。
標準3.0V。
2. ただし手册并未说明，提前多长時間？
原理図では、VDD_SNVS_IN は VDD_HIGH_IN および VDD_SOC_IN よりも先に電圧がかかります。
ディスプレイの観測結果はこのように、1ms ほど前に、十分ですか？
上電流シーケンスの起動状態が一致していないためかどうか、次の手順を検討してください。
電源树
3. 合計 10 枚のパネルを共用したところ、2 枚に同様の障害が発生しました。
4. パネル子 uboot+linux 卡死。
uboot/arch/arm/mach-imx/mx6/soc.c
実験では、DCP モジュールからシーケンス番号として数値を取得すると、SOC がクラッシュします。
以降、试编写裸机LED程序、代価里读写DCP寄存器、同クラッシュ
int arch_misc_init(void)
{
if (IS_ENABLED(CONFIG_FSL_DCP_RNG)) {
struct udevice *dev;
int ret;
ret = uclass_get_device_by_driver(UCLASS_RNG, DM_DRIVER_GET(dcp_rng), &dev);
if (ret)
printf("Failed to initialize dcp rng: %d\n", ret);
}
setup_serial_number();
return 0;
}次来尝试：
1. すべてのパネルのタイムシーケンスが一致するかどうかを同時にテストし、VDD_SNVS_IN がどの程度動作するかをテストします。
2. パネルは、時系列の影響を避けるために、VDD_SNVS_IN を常に最後の電圧に保って、バッテリー 3.0V に接続します。
上記完了その後再回帖
VDD_SNVS_IN電源は通常3.0Vを必要とします。回路基板を設計する際には、この電源をCPUに電力を供給する最初の出力にする必要があります。
ピンP12（VDD_SNVS_INピン）。これも要件を満たしています。
マニュアルでもご確認いただけます。
VDD_SNVS_INが直接供給される場合
コイン電池の場合、VDD_HIGH_INとVDD_SNVS_INの間にショットキーダイオードが必要です。
設計は要件を満たしていますか？また、合計10枚のボードを製作したのですが、そのうち2枚は正常に動作していませんか？
ボード上ではどのようなソフトウェアが実行されていますか?