nRF52833のモジュールのプロジェクトを作成してビルドして無理やり書き込んでちゃんと動作することが確認できたので、これをVSCodeからデバッグしたい。CMSIS-DAPデバッガになったSeeeduino XIAOでなんとかしたい。ところで
CMSIS : Common Microcontroller Software Interface Standard
DAP : Debug Access Port
だそうです。
さんざんほじくった結果、VSCode拡張機能にイケているのがあって、こちらです。 Cortex coreのデバッグ用なので、nRF52にあるような特殊なペリフェラルまでデバッグできるのかどうかはまだわからない。が、気にせずどんどんやっちゃう。この拡張機能をインストールして、VSCodeの実行とデバッグアイコンをつついて、 launch.jsonファイルを作成しますをつついて、Cortex Debugを選ぶ。
と
- {
- // IntelliSense を使用して利用可能な属性を学べます。
- // 既存の属性の説明をホバーして表示します。
- // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
- "version": "0.2.0",
- "configurations": [
- {
- "name": "Cortex Debug",
- "cwd": "${workspaceFolder}",
- "executable": "./bin/executable.elf",
- "request": "launch",
- "type": "cortex-debug",
- "runToEntryPoint": "main",
- "servertype": "jlink"
- }
- ]
- }
CMSIS-DAPデバッガーを使ってCortexコアのデバッグをVSCodeから実施するときのlaunch.jsonの記述内容を示してください。
と、
- {
- "version": "0.2.0",
- "configurations": [
- {
- "name": "Cortex Debug",
- "type": "cortex-debug",
- "request": "launch",
- "servertype": "openocd",
- "cwd": "${workspaceRoot}",
- "executable": "${command:cmake.launchTargetPath}",
- "configFiles": [
- "interface/cmsis-dap.cfg",
- "target/stm32f4x.cfg" // 使用するターゲットに応じて変更してください
- ],
- "svdFile": "${workspaceRoot}/path/to/your.svd", // 必要に応じてSVDファイルのパスを指定
- "runToEntryPoint": "main",
- "postRestartCommands": [
- "break main",
- "continue"
- ],
- "preLaunchTask": "build", // 必要に応じてビルドタスクを指定
- "serverpath": "/usr/local/bin/openocd", // OpenOCDのインストールパス
- "gdbPath": "/usr/local/bin/arm-none-eabi-gdb", // GDBのパス
- "armToolchainPath": "/usr/local/bin/" // ARMツールチェーンのパス
- }
- ]
- }
- {
- "version": "0.2.0",
- "configurations": [
- {
- "name": "Cortex Debug",
- "type": "cortex-debug",
- "request": "launch",
- "servertype": "openocd",
- "cwd": "${workspaceRoot}",
- "executable": "${workspaceFolder}/build/zephyr/zephyr.elf",
- "configFiles": [
- "interface/cmsis-dap.cfg",
- "target/nrf52.cfg"
- ],
- "runToEntryPoint": "main",
- "postRestartCommands": [
- "break main",
- "continue"
- ],
- "serverpath": "/usr/bin/openocd", // OpenOCDのインストールパス
- "gdbPath": "/home/hoge/ncs/toolchains/e9dba88316/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb", // GDBのパス
- "armToolchainPath": "/home/hoge/ncs/toolchains/e9dba88316/opt/zephyr-sdk/arm-zephyr-eabi/bin/" // ARMツールチェーンのパス
- }
- ]
- }
- executableに実際のBuild成果物を指定
- configFilesのtargetをnrf52.cfgに変更
- sdvFileはわからんので削除
- preLaunchTaskは削除(nRF Connectで手動でBuildするしかない)
- openocdのパスを実態に合わせて変更
- gdbPathを実態に合わせて変更(ここにあるってのを探すのがしんどかった)
- armToolchainPathを実態に合わせて変更(これでいいのかはわからん)
で、こんな感じでブレークポイントをおいておく(launch.jsonにmainで止まるように記述してあるのでまぁ後でも設定できるんやけど)。 で、デバッグを開始する。
って感じで止まる。ボード上のLEDがすでに点滅しているのはブレークポイントより前にすでにpwmを設定しているからだろう。
この後、再生ボタンを押すごとに点滅が速くなる。
で、メニューの表示のコマンドパレットを選んで cortexって入れる
と、色々見れるじゃんってなる。でView Memoryを選んでみる。
と、アドレスを入れんしゃいってでる。で、Flashの先頭アドレスの0x00000000を入れてみると
確かにhexの内容になっている。すごいぞ。
ところで、printkはどこに出力されているんじゃいってのは、回路図(ここ(https://www.raytac.com/product/ins.php?index_id=97)にある)をみると
ここかな?って感じなので、こんな感じでFT231Xボードをつないでで、VSCodeのシリアルモニターで見てみると、あ、なんかエラー吐いてるやん、、、が、こんな感じで出力されているんです。イイネ!あーうまくいったぞい。Copilotも今回はそれなりに役に立った。こういうのやるってのが技術者感ある。ハードウェアがあるからソフトウェアがある。ソフトウェアでやりたいことがあるからハードウェアが進歩する。最初から究極のハードウェアがあるわけじゃないし、それは経済的じゃない。最も経済的な設計で希望のモノを実現するのがエンジニアリングや。って思うんやけど、時代遅れなん?(৹˃ᗝ˂৹)悲しいことです⁽⁽٩(๑ᵒ̴̶̷͈᷄ωᵒ̴̶̷͈᷅ ๑)۶⁾⁾
0 件のコメント:
コメントを投稿