これは大象嵌入式（Daxiang Embedded）S32K144 の回路図です。現在の問題は、プログラムが起動せず、フラッシュがずっと空のままという点です。リセットボタンを放したときの RESET の対地電圧が 1V になっており、これは明らかに正しくありません。
販売店の説明では、チップがロックされており、RESET から出力が出るとのことです。以下は RESET の対地波形です。
しかし、GPT に書き込み手順を一通り試してもらったところ、チップはロックされておらず、フラッシュには書き込めるものの、すぐに消去されてしまうと言われました。
その後、GPT に全体の流れを説明したところ、次のような説明を返されました：チップのリセットループはウォッチドッグではなく、LOCKUP リセットである。空のフラッシュの CPU が 0xFFFFFFFE で命令をフェッチする → バスエラー → HardFault（ハンドラも 0xFFFFFFFE にある）→ 再帰 → LOCKUP → リセット → 再びループ。周期は数百マイクロ秒。
しかし、提示された解決策はいずれも効果がありませんでした。詳しい方、どう解決すればよいかわかりますか
リセットIOが繰り返しローレベルに引き込まれるのは、書き込んだプログラムがPTA5（RST）というIOを使っていて、ソフトウェア上でそのIOをローレベルに引き下げ、さらにソフトウェア側でそのIOのリセット機能を無効にしていないため、ずっとリセットして再起動しているのではありませんか？正常なサンプルプログラムを別のものにして書き込んでみてください。
この 1V という RESET 電圧は確かに問題です。通常、リセットボタンを離した後、RESET は内部プルアップ、または外部プルアップ抵抗によって VCC（3.3V）近くまで引き上げられるはずです。1V ということは、プルアップが弱すぎるか、チップ内部でリセットを継続的に引き下げているかのどちらかです。
回路図を見る限り、R7 の 2.2k プルアップは十分なはずです。ただし、S32K144 の RESET ピンは双方向である点に注意してください。チップ自身が能動的にリセットを引き下げることもあります。もし本当に LOCKUP ループなら、チップは数百マイクロ秒ごとに自分自身をリセットし、オシロスコープで見ている 1.64kHz ののこぎり波はおそらくそれです。
まず、次の点を確認してください。
-
R7 両端の電圧を測定し、プルアップ抵抗が確実に VCC_MCU に接続されており、電圧が正常であることを確認してください。開発ボードの電源が仮はんだになっていたり、LDO の出力が不安定だったりすると、プルアップ電圧が不足することがあります。
-
リセットボタンを切り離し、RESET ピンをジャンパで直接 VCC に接続して、プログラムが動作するか確認してください。動作するなら問題はリセット回路にあります。それでも動作しないなら、リセット回路の問題は除外できます。
-
J-Link または PE デバッガで直接接続し、オンボードの OpenSDA を経由せずに、チップ ID を認識できるか確認してください。オンボードデバッガがリセットを妨げることがあります。
-
VDDA と VREFH を確認してください。S32K144 のアナログ電源が未接続または不安定な場合も、奇妙なリセット動作の原因になります。
GPT が言っていた LOCKUP ループについてですが、論理的には正しいです。空のフラッシュでは確かにそうなります。ただし重要なのは、なぜフラッシュが空になったのかです。プログラマが書き込めていないのか、書き込んだ後に消去されてしまったのか。J-Flash または S32 Design Studio で直接チップに接続し、フラッシュの内容が実際にどうなっているか確認することをおすすめします。フラッシュが本当にすべて FF なら、まず最も単純な blink プログラムを書き込んで、動作するか確認してください。動作するなら、チップはロックされておらず、書き込み手順の問題です。それでも動作しない場合、チップの破損またはロック状態を疑ってください。
GPT の説明は、実際その通りです。S32K144 のフラッシュが空の状態だと、無効なアドレスからのフェッチが発生し、HardFault、さらに Lockup、そしてシステムリセットへと進行します。MCU がそのリセットピンをアクティブにローレベルに駆動しているため、ごらんになっている 1.64kHz ののこぎり波が発生しています。これを修正するには、「Connect under reset」に対応したデバッガーが必要です。J-Link をお使いの場合は、J-Link Commander を開き、unlock kinetis コマンドを試してください。これにより、不正な命令を実行しようとする前にコアが停止します。
同じ基板で、先月まさにこの落とし穴にはまりました。あなたのGPT分析はかなり的確です。LOCKUPループです。ただし、リセット波形に引っ張られないでください。
当時の私の解決方法は、書き込み時にリセットキーを手で押さえ、Downloadをクリックしたらすぐに離すというものでした。チップがリセット解除される前にコードを書き込むためです。いったんLOCKUPループに入るとSWDタイミングが崩れて、デバッガは書き込みが成功したと思い込みますが、実際にはまったく書き込まれていません。あとで読み出すと全部0xFFで、「消去された」ように見えます。
また、起動ファイルがS32K144専用のものであるか確認してください。STM32から移植したコードの場合、ベクタテーブルの位置やリンカスクリプトが合っていない可能性があります。S32K144のFlash開始アドレスは0x0000_0000ですが、ベクタテーブルには正当な初期SPとReset_Handlerを含める必要があります。この2つの値が0xFFFFFFFFだと、チップはリセット解除直後にHardFaultに入ります。
それから、3.3Vが安定しているかも測定してください。この基板はUSB給電だと負荷に耐えきれないことがあり、電圧が2.8V以下まで落ちるとFlash書き込みがサイレントに失敗し、「書き込めない」ように見えることもあります。USBケーブルを短いものに替えるか、外付けの5Vで試してみてください。
新しい基板ですか？プログラムが入っていないためにリセットが繰り返されている可能性もあります。
以前ESP32S3を使った時も同じで、新しいモジュールではフラッシュが空だとリセットが繰り返されました。ESP32の場合の解決策は、BOOTボタンを押しながら電源を入れて書き込みモードに入ることです。
上司からもらったものです。使ったことがないと言っていました。
公式のサンプルを使っていますが、PTA5の設定は行っていないようです。
試してみましたが、Kinetis のロック解除はできました。ただし、フラッシュにはまだ書き込めません。あるいは、書き込めてもすぐに消去されてしまうようです。
ありがとう、明日の朝試してみます