ねむいさんのぶろぐ

中国自然歩道を往く -北伐！県境を越えて鳥取県に侵入せよ！-

Codeliteを使ったデバッグ環境構築はどこに行ったのか？そして北陸進出
計画はなぜ越前市に来たとたんに足踏みしているのか？ねむいさんのぶろぐの
過去画像差し替えが完了するのはいつなのか？

答えは今回の命を賭した岡山県境越えそして鳥取県侵入に隠されている…！
かも？

●2022.11.19 中国自然歩道(東粟倉～鳥取県境～芦津～智頭)

いきなりのくそみたいな展開…
人身事故3連発で使いたくもない貴重な株主優待拳を消費してしまう羽目に…
しかも自由席ガラガラで指定グリーンとか無意だったの…
とにもかくにも何とか岡山県は大原にたどり着きました。

今回は東粟倉にある愛の村パークなる研修施設に泊まりました…
なんと旅行支援も使ってないのに素泊まり2500円とすさまじいコスパで
温泉まで入れちゃいます！！まぁでも車持ってる人専用のお宿ですね～

てなわけで12時間にわたる地獄開始！！！

朝の後山地区を駆ける。
今年初めに寄った道仙寺に今回もよりました。

道仙寺護摩堂です。前回の予習はここまで。
あとは未踏の戦いの場が始まります…！

護摩堂の近くには愛の水という湧水があるのですが金とるのか…
愛がないと思ったら奥に進むとちゃんとフリー湧き水ありました…
愛とは何か。

今までの中国自然歩道はひたすらアスファルトでだらだら長い印象ですが
今から急に難易度が跳ね上がり険しい山岳地帯となります…！
ねむいさんはここさえ攻略出来たら後は楽かとこの時は思ってました…。

岡山～鳥取県境の山野は普通にクマが出没するそうです…
真っ赤な警告看板がガチ感出してて恐ろしいですね…
ねむいさんも10年前に買ってそのまま放置していた熊鈴を今回ついに
実践投入し程度見ます…そしてここから登山道…！

東海自然歩道の犬越路をほうふつとさせる石交じりの登山路です。
途中ではクマの糞も見つけちゃったりして警戒度上げつつ上りますが…

ありゃりゃ…なんだこれめちゃくちゃきついのぼりですよぅ…
ねむいさんが山に登るとよく遭遇する斜め50度くらいの世界に…
はぁはぁ…

滑落しないように慎重に上ると勾配が緩くなってきてだんだん歩きやすく
なってきました・・難所は越えたか…やった…

…！！！！！！！
ねむいさん道を間違えて危険なバリルートを上っていたようです…
道理できついわけだわ…

そこからはほどなくして後山分岐にそしてさくっと舟木山頂上です☆

自然歩道のルートではないですがもちろん後山にも向かいます…！

岡山県最高峰、後山です…。
大馬鹿だからこんな北伐ちゃれんぢするのですよぅ！

今度は進路を西にとって自然歩道ルート上のダルガ峰を目指します…！

絶対に許さないよ
(いやらしい角度に傾きながら)

標高1000m越えの天空のトレイルを走っているとどんどん晴れてきました。
途中の鍋が谷山です。

走りやすい素晴らしいトレイル区間…最高…♥

遺跡みたいな岩がちりばめられている駒の尾山頂です。
振り返ると後山がもうあんなにはるか彼方に見えます…！

次は最後のピークダルガ峰をめざします…
だんだんススキが目立ってきました。

岡山県の区切りとなるピークダルガ峰に到着です…！
ごらんのとおり“だるがなる”とよむ不思議な山頂です。

ダルガ峰からは大量の薄に囲まれて下っていきます…。
途中のダルガ峰山小屋では私もメッセージを残してきました！

一瞬車道に出たと思ったら今度は大崩壊というか自然に帰った
山道に…おろしたてのトレランシューズがあああ！！

何とかやばい空間を躱して大茅スキー場に到着です。
雪はないですが大量のススキがお出迎えです☆

スキー場のふもとでは自販機があったのでここで後半戦を戦う装備を
整えました…！いざ！

お次は若杉原生林と岡山県境です…
600mまで降りちゃったのでまた約550mくらい登り返さないといけません☠

若杉原生林駐車場です。
ここにもくまさん警報看板が大量にありました。

若杉原生林をかいくぐる…！
ここを上り詰めるといよいよ岡山・鳥取県境がある若杉峠です。

そしてお地蔵さんがある若杉峠に到着です。

ここから先は鳥取県になります…
がいきなり熊よりやばそうな脅し文句が
…たいしたことないでしょねむいさんを誰だと思ってるのよ


鳥取県になってから突然激しくなる上り下り…
がぁぁああああぁっぁぁあ


足を踏み入れるものを遮る鳥取警告看板が再び目に入る…
しかしねむいさんのライブラリに撤退というメソッドはない！

ていうの嘘ですすみませんもう帰して…
芦津・吉川越えです…

んあこたぁわかっとるわい！です！ＹＯ！

うっかり足をつった状態で何とか上ってきた狩谷山です…
ここでアミノ酸と天日塩の補給で足の回復を行いました。

狩谷山からはさらに上って標高1200mに…がぁぁぁぁあぁっぁぁあ
でもさっきのアミノ酸と天日塩が効いて足はちゃんと動きますが


1200m超えた地点で急に下りになったちょっと先に車道が…
やっと解放された…と思ったら今度は懲役8kmのアスファルトが…

まぁ標高1100mからのえんえん下り道なので多分非常に気楽です。
ススキがきれいですね～(必死の形相で


懲役8kmと思いきや意外と見るものがありました。
かつては林業や鉱業が盛んだったようですね。

とそれに気を取られてこの穴ぼこにやられるところだった！１！！！１１
こけそうになったけどでんぐり返りじゃなくて前回り受け身で奇跡的に
ノーダメでクリア！

そのまま駆け下りていくと本日最後のトレイル"三滝区間"にやってきました。
水洗トイレもあったので最後の補給をして挑みます…！

何気なく進むといきなり激しい落差になって気が置けません。

？？？？？

三滝ダムです。

対岸に渡りトレイルは進みます。

この区間の見せ場、三滝です。

あとは安全な道を通って今回最後のトレイル区間終了です…
暗くなる前に何とかここまで攻略できました…

あとはアスファルト道を駆け下りていくだけ！
うぉぉおおおおお！！

急速に暗がりが広がってきましたがトレイル区間は抜けたので
街灯もあったりしてライト使わなくてもへっちゃらです…☆

ていうのはうそです…どんどん暗くなってきたので熊鈴をしまって
代わりにライトを装備して進みます。

すっかり日が落ちて夜になったころに芦津バス停に到着です。
ここが次回のエントリポイントになります。
あとは走って智頭駅に向かうのみ！

ぁー星空めっちゃきれい
(写真が失敗したわけではない)

暗くてよくわかりませんでしたがここもかつての街道で史跡がたくさん
みられるようですね。

国道にぶつかって今度は国道沿い西に進路を取りひたすら走ります！！！
足もちゃんと走れてるからいまだ問題なし！！

千代川沿いに走っていると智頭駅の看板が！！！
あと少し！！！！！１！！

…ッッ着いた…！はるばる58㎞を超えて県境を越えて鳥取県の智頭駅に
ついにゴールしました…！そしてスーパーが閉まるギリギリだったので感慨に
浸る間もなくお土産と晩飯を買い込む…。

ちなみにさっきのはＪＲの智頭駅で智頭急行の智頭駅もあります。
智頭急行のほうに鎮座する駅娘のえりおさんは芋くてあんましかわいくｎ
ｶﾜｲｲ

運転手さんの計らいで休日割引料金1200円でで上郡に帰れたりちょっと
助かりました。そしてあとは新快速で京都まで夢の中…
今回も無事にタフな戦いを制しました！

そんなわけで中国自然歩道岡山の最難関をクリアして鳥取県まで進攻できました
が！今回は序の口でさらにやばい区間が待ち構えているのでしっかりリサーチを
重ねて体力をつけて挑もうと思います！！
ぁーその前に北陸地方は新幹線が敦賀に通ってしまうまでに優先的に攻略して
金沢まで到達したいのでそちらが優先になるかとおもいますという複数正面作戦
状態となりますがなんとか頑張ってみますよぅ

●2022.11.19 中国自然歩道(東粟倉～鳥取県境～芦津～智頭)GNSSログ

いろいろ試す53

副業(本業は二次裏メイド)が激務になったのと秋の登山ラリーが始まったので
まったく時間が取れてませんが何とか進めていきたいと思います…

●ようやくSWDマルチドロップも使い物に･･･！
-OpenOCD-0.12.0-RC2更新-
長かった…ラズパイピコが登場してから長い戦いだったがようやく本家にも
安定した状態で取り込まれたようですね…感無量です。

↓以下RaspiPicoに書き込んだところのログ

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash_bin main.bin 0x10000000"

Open On-Chip Debugger 0.12.0-rc2+dev-00001-g12ce17094 (2022-10-30-22:35)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

Info : FTDI SWD mode enabled

Warn : Transport "swd" was already selected

Info : clock speed 1000 kHz

Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001

Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001

Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected

Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints

Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected

Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints

Info : starting gdb server for rp2040.core0 on 3333

Info : Listening on port 3333 for gdb connections

Info : starting gdb server for rp2040.core1 on 3334

Info : Listening on port 3334 for gdb connections

[rp2040.core0] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

[rp2040.core1] halted due to debug-request, current mode: Thread 

xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00

Info : Found flash device 'win w25q16jv' (ID 0x001540ef)

Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors



Info : Padding image section 0 at 0x1001fe80 with 128 bytes (bank write end alignment)

Warn : Adding extra erase range, 0x1001ff00 .. 0x1001ffff

Info : wrote 130816 bytes from file main.bin in 4.495757s (28.416 KiB/s)

Info : verified 130688 bytes in 0.206712s (617.405 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:05

コアがちゃんと2つ見えているのがわかりますね～
また、注目すべき点はコアの数だけgdbサーバのポートも増加している点です
デバッグ時はgdbも一個ずつ起動してつなげていきます

openocdも0.12.0になってARM以外のかなりのCPUコアもサポートしています。
STM8はすでに書き込みデバッグに成功していますが新規にサポートされた
RISCVのGD32V系、また本家にサポートが取り込まれたESP32などはまだ全くの
手付かずなのでこれから挑戦していきたいと思います！

というところでねむいさん特製ビルドのOpenOCDはこちらになりますので
どしどしお使いください…！

●で、CodeLiteとGDBを使ったデバッグはどうなったの？

…正直まだ検証が進んでません…
10年同じ事やってたのでtarget extended-remoteってなんだよってとこから
再開ですしSTM32の検証がやっと終わってほかのcortex-M、あとARM7TDMIも
見ていこうと思ってますがすべてのCPUで安定して動かせられるパタンが中々
見つからず苦戦しています。
・今できてること
　→ステップ実行(ステップイン/ステップアウト)
　→ブレークポイント
　→変数読み取り
・InsightではできたがCodeLiteでできなくなったこと
　→IOViewでペリフェラルを直感的にたたけなくなった
　　　(gdbのprintコマンドでせこせこ変えるしかない)
　→main関数内の最上位でステップアウトをうっかりやらかすと死ぬ
　→ブレークポイントを設定しないでrunさせたら死ぬ
　→調子おかしくなったと感じてstopしてもgdbにコマンドがなぜか通らず死ぬ
　→とにかく機嫌損ねたら死ぬ
　

死んだらこちらも能動的に殺しにかかってtaskkillコマンドでOpenOCDごと
強制終了してつなぎなおしてます。Insight時代からやってましたがよく
わからなくなったら全部終了で再開するのが最適だと感じてます。
画像はNuvotonのnano130のデバッグ終了時の画面です…いささか強引ですが
これが一番楽…とこんな感じでLPC系のマイコンとかも確認を進めていきます。

●avrdudeがものすごく中身変わっていた
avrdudeがすさまじい勢いで修正がかかりまくりどんどん進化してます
当然途中で大変更が発生することもあり、これで深刻な影響を受けるのは
たいていビルドする人間です…orzビルドが通らなくなったorz

今回readline周りが大幅変更でまともにビルド通らず動かずで難儀しましたが
何とか安定して動かすことができました…細かいことは省きますがreadlineが
dllとして追加になりました。もちろん自前ビルドです。
以下avr128da48に書き込んだ時のログ

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi    -U flash:w:main.bin 



avrdude: Version 7.0-20220508

         Copyright (c) Brian Dean, http://www.bdmicro.com/

         Copyright (c) Joerg Wunsch



         System wide configuration file is C:¥Devz¥AVR¥avrdude¥avrdude.conf



avrdude: input file main.bin auto detected as raw binary

         Using Port                    : usb

         Using Programmer              : pkobn_updi

avrdude: found CMSIS-DAP compliant device, using EDBG protocol

         AVR Part                      : AVR128DA48

         RESET disposition             : dedicated

         RETRY pulse                   : SCK

         Serial program mode           : yes

         Parallel program mode         : yes

         Memory Detail                 :



                                           Block Poll               Page                       Polled

           Memory Type Alias    Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack

           ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

           fuse0       wdtcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse1       bodcfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse2       osccfg      0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse4       tcd0cfg     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse5       syscfg0     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse6       syscfg1     0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse7       codesize    0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuse8       bootsize    0     0     0    0 no          1    1      0     0     0 0x00 0x00

           fuses                   0     0     0    0 no          9   16      0     0     0 0x00 0x00

           lock                    0     0     0    0 no          4    1      0     0     0 0x00 0x00

           tempsense               0     0     0    0 no          2    1      0     0     0 0x00 0x00

           signature               0     0     0    0 no          3    1      0     0     0 0x00 0x00

           prodsig                 0     0     0    0 no        125  125      0     0     0 0x00 0x00

           sernum                  0     0     0    0 no         16    1      0     0     0 0x00 0x00

           userrow     usersig     0     0     0    0 no         32   32      0     0     0 0x00 0x00

           data                    0     0     0    0 no          0    1      0     0     0 0x00 0x00

           eeprom                  0     0     0    0 no        512    1      0     0     0 0x00 0x00

           flash                   0     0     0    0 no     131072  512      0     0     0 0x00 0x00



         Programmer Type : JTAGICE3_UPDI

         Description     : Curiosity nano (nEDBG) in UPDI mode

         ICE HW version  : 0

         ICE FW version  : 1.21 (rel. 37)

         Serial number   : MCHP3280031800001375

         Vtarget         : 3.31 V

         PDI/UPDI clock Xmega/megaAVR : 100 kHz

avrdude: partial Family_ID returned: "    "

avrdude: AVR device initialized and ready to accept instructions

avrdude: device signature = 0x1e9708 (probably avr128da48)

avrdude: Note: flash memory has been specified, an erase cycle will be performed.

         To disable this feature, specify the -D option.

erasing chip

avrdude: reading input file main.bin for flash

         with 3392 bytes in 1 section within [0, 0xd3f]

         using 7 pages and 192 pad bytes

avrdude: writing 3392 bytes flash ...



Writing | ################################################## | 100% 1.09s



avrdude: 3392 bytes of flash written

avrdude: verifying flash memory against main.bin



Reading | ################################################## | 100% 0.60s



avrdude: 3392 bytes of flash verified



avrdude done.  Thank you.





> Process Exit Code: 0

> Time Taken: 00:02

正直大変更前と見た目は全く変わらないので見栄えがしませんがいろんな人の努力で
どんどん機能がパワーアップしていくわけですね…

avrdudeの10月末最新のバイナリもアップロードしました。
こちらもどんどん使ってくださいませ～！

OpenOCD小ネタ28 -もうすぐ0.12.0になりそう-

8月の終わりに入ってから残業規制出向規制すべて解禁となったおかげで
鬼シフtじゃなくてガンガン仕事入れまくったおかげでぶろぐのネタが全く
すすんでません…

特にCodeLiteを使ったGDBデバッグ手順の公開を待ってる方もいるかも
しれませんが今やってる副業(本業は二次裏メイド)の案件がもう少しで
片付くので10月中くらいには何とかしますので耐えてください…

ということでOpenOCDが0.12.0に~~なった~~なりそうなのでちょっとめぼしい点を
2，3点かいつまんでお茶を濁します…

●SWDマルチドロップのサポート…がまだできてねぇ！
RaspberryPiPicoの復旧でOpenOCDでPicoをデバッグしたいという需要も増え、
つい最近SWDマルチドロップのサポートが強化されておりました！私もさっそく
手持ちのRaspiPicoで試してみました！

…
ファ〇ック！！！！！１１１！１

だめだぁ～～ぜんぜんまともに動いてないじゃん…

皆様ご存じとは思いますがRaspi公式のgithubで公開されているRaspiPico用の
ブランチはすでに昨年初めの時点でSWDマルチドロップられるし普通にデバッグ
できるしフラッシュも余裕で書き込み出来ちゃいます・・
OpenOCDの本家さん頑張ってくださいよ～ねむいさん多忙すぎて最近OpenOCDの
ソースから離れちゃったからねむいさん以外の人ががむばってほしい
(☝他人任せ)

しかもRaspi公式のブランチは一昔前の0.11系のやつで最悪なことにftdiなどの
interfaceの設定に使用するcfgファイルが現在の0.12系の奴と互換性がありません
かつてはPi用のOpenOCDも同梱してたのですが現在は分離しております。
ねむいさんが公開しているOpenOCDは現在本家最新のコミットとRaspiPico専用
SWDマルチドロップ対応の物の二つを紹介しております。

・本家最新コミットのビルド
・RaspiPico専用ブランチのビルド

何とか両者が統合してくれることを願うばかりですね～…ほかにもnuvotonや
ESP32などのブランチも宙ぶらりんになってるのでESP32のほうはだいぶシンクロ
してきてるようですが頑張っていただきたいですね…(他人任せ

●OSなしでデバッグ時にエラーメッセージが延々と流れるのが治ってた
読んで字のごとくです

デバッグ続行自体は可能な動作に致命的なもはないのですがステップ実行のたび
延々と"No RTOS could be auto-detected!"とエラーが垂れ流され続けるので、
ねむいさんも業を煮やして結構苦しい修正をしてました。

diff -urN b/src/rtos/rtos.c a/src/rtos/rtos.c

--- b/src/rtos/rtos.c	2018-09-09 21:28:02 +0900

+++ a/src/rtos/rtos.c	2018-09-09 21:19:18 +0900

@@ -245,6 +245,7 @@

 			/* Autodetecting RTOS - try next RTOS */

 			if (!rtos_try_next(target)) {

 				LOG_WARNING("No RTOS could be auto-detected!");

+				os->symbols = NULL;

 				goto done;

 			}

公式の修正はもうちょっとスマートですがもちろん問題も修正されスムーズに
デバッグできたので満足しております。9月末までの修正を盛り込んだOpenOCD
バイナリは上でも紹介しましたがおきぱにて公開しておりますので皆さまガンガン
お使いください！

いろいろ試す52

●CodeLite+GDBを使ったARMデバッグ環境移行加速す！

oh...myｺﾝﾌﾞ･･･とうとうこの日がやってきた…
InsightだとGCC12からサポートされたdwarf5フォーマットのelfが読めない…
ARM-GCCのバグのせいかdwarf4形式のリンカオプションつけてもdwarf5･･･

orz

というわけでねむいさんのぶろぐ旗揚げから13年間続けてきたInsightによる
デバッグ法に別れを告げ、かねてより評価中のCodeLiteによるGDBデバッグ
環境移行と同手順書作成に本腰を入れております！

移行で一番の障壁はworkspaceの概念でしたが…幸いにもディレクトリを遡る
相対アクセスが問題なくできたのでmain.elfを相対参照するようにしたら
デバッグするたびいちいち設定しなおす必要もなく同一のworkspaceファイル
の使いまわしができそうです！

CodeLite.exeはなんでかgnumake3.81から直接召喚できなかったのでwindowsの
CMDでの機能で代用しました。ちゃんと引数付きで呼び出しもできたので
ここで上で説明したworkspaceファイルを相対アクセスで開きます。

実際のデバッグ画面です。
ソースレベルでステップ実行とかの基本は当たり前の余裕ですね。

InsightではWin10では即堕ちして使いものにならなかったCPUレジスタ参照は
バリバリできています。

F7,H7の浮動小数点レジスタも楽勝です♨

…なのですがなんでかこれらレジスタ表記は10進数(一部は16進数)固定で、
進数の切り替えができません。Insightでは柔軟にできてたのでここに
ついては要改善ポインツですね。

また、周辺I/Oのレジスタ値を直接参照するIOView機能とかも一応使えます。
IOViewは周辺レジスタをconst宣言しているせいか、変数参照ウインドウから
直接値を変えられませんでした。
constでも値を自由に変えられちゃうInsightのほうが逆にダメだったのかも。

回避策としてOutputウインドウからコマンド直接入力で値を変えられます。
Outputウインドウと銘打ってますがGDBのコマンド入力も受け付けています。

そして特筆すべきはInsightとは違いGDBから完全に独立したGUIとして働くので
ARMだけではなく他のCPUコアでもそれ用のGDBさえあてがえば普通に使えます！
先月紹介したSTM8Lもご覧の通りばりばりデバッグ可能です！
ていうかSTM8Lの記事ぶん投げっぱなしですが来月がんばります！！！！

となるとESP32とAVRのデバッグ環境もCodeLiteで一括化できそうなので、特に
5年くらい放置してるESP32とかはやる気出てまた活動再開できそうな感じです☆
ARMマイコンビルド/デバッグ環境構築手順もCodeLite+GDBデバッグを主眼にした
2022年版に書き替えている最中ですのでこうご期待！

また、待ちきれない方に先んじてWin10環境下でCodeLite+GDBのデバッグ環境
対応のプロジェクトに更新しております。現在以下のものが対象です!
・STM32H7-Disco
・STM32F7-Disco
・STM32F4-Discovery
・STM32G0ベアメタル

●ARM-GCCがまたアップデートしていた。
まず、前回のいろいろ試すでアップデートされたGCCでビルドすると…

前回記事にしていたにかかわらずこれ気づかんかった…
ちゃんと検証してなかったのバレバレの私orz
これかなり致命的なバグでしたね…私のおきぱのプロジェクトがほぼビルド
不可能状態でした…すみません。
これ前回のいろいろ試すにも警告書いときます。

現行のGCC11.3ものは緊急修正が加わってちゃんとビルドできるようになってます。
が、冒頭のdwarf5の問題でInsightデバッグができなくなってますので要注意！

●AVRDUDEにパッチを投げたお話
これも9年越しの話なのですがねむいさんはJTAGKEY等のFT2232系のISP/JTAG
書き込みで、1セクタサイズ以下のサイズのバイナリを書こうとしたら正常に
書き込めないバグを見つけておりました。しかし、そんな超限定された条件、
例えば128kByteの容量を持つatmega1284p(フラッシュセクタサイズ256Byte)に
たった202バイトの容量のLチカプログラムを書き込むやつがいるだろうか？
という原因からか9年放置されていました。

が、オワコン化したかと思われたavrdudeがgithubに移行したとたんバリバリ
更新がかかりまくるようになり、9年前の問題が再び目に留まったのでわたしも
この問題に決着をつけるべく参戦を果たしました！！！
(☝お前AVR辞めたんちゃうんかいという突っ込みは一切なしで)

その後、管理者の人のコードレビューと別の修正が合体して正式にコミット
されています。

リンク先の議論にもありますがねむいさん的には符号付整数で比較を
行うと符号拡張で符号なし整数では思わぬでかい数字が入ってしまって
思ったような評価ができないのを危惧したのですが最終的に符号なし
整数同士の評価で終わるようにしてくれて実際に問題なく書き込みが
できるようになったのでよしとしましょう。

STM8Lはぢめました（まだはぢまってすらいない)

●STマイクロの8bitマイコンSTM8L

少し前に偽ATXMEGA128A1Uを掴まされた店から物のついでと同時に8Pinと
64PinのSTM8Lシリーズマイコンを購入しておりました。

かつてはVersaloonへの改造のため燃えないゴミと称してSTM8の部分は即廃棄して
いましたが、2022年の現在はまともな開発環境とかそろってそうだったので
手を出してみた次第でございます･･･しかし…

●STM8ライタ復活への道

しかし！ねむいさんはVersaloonへの改造のためにSTM8-discoveryのSTLinkの
部分をつぶしてしまっておりました！！！STM8に書き込みデバッグするために
SWIMプロトコルを持つSTLink系デバッガハードが必要です！
さすが私！やらかした！だめだこりゃ！

でも私はSTM32系のDiscovery持ってるじゃないか、あれのSTLinkの部分使えば
SWIMを引き出せられるんじゃないかと思い出し手持ちのDiscovery基板やNucleo
基板を引っ張り出して調べてみました。

改造できる条件として、STLinkのファームがSTM8用のSWIMプロトコルが実際に
使用できること、そして基板上にパタンが出て改造しやすいことです。
NUCLEO系や最近のDiscvoeryではSTLink/V2-1のファームが動いており、それらは
ファームからも回路もオミットされているためこの時点でアウチです。

選んだのはSTM32F0Discoveryです(SWIM引き出し改造済み後の撮影ですが)。
こいつはSWIM用の外部端子や構成回路こそはありませんが有り難いことに
SWIM向けに内部パタンは接続されており、最小限の配線をしてやればSWIMを
復活できるはず…！

そして根性の配線…ッ！
STM8S-DiscoveryのSWIM回路の真似して受動部品も装着です。
OpenOCDはすでにSTM8へのフラッシュ書き込みやデバッグ機能を持っているため、
ねむいさんの環境においてもたやすくできるはずです！
いざ勝負！

…
(注:STM32G0のプロジェクトになってますがmakefileをいじり、OpenOCDから
　　　STM8Lに書き込むようにしています。)
まぁ簡単にできるわけないよね。STM32F0DiscoveryのSTLink/V2のファームは
STM32のSWDに特化していてSWIMがファーム的に機能していませんorz
"STLINK V2J39S0"ってなっていますが"V2J39S0"の部分、J39がSWJのv39でS0は
SWIM機能ありませんって意味と解釈してください。

これ普通にSTLinkのアップデータでファームをあげてもJ39の部分が上がるだけ
なのでどう頑張ってもSWIMできません…

しかし…おそロシアの力を借りるとあら不思議(意味深)
STM8にも対応したデバッガーファームウエアが書き込まれてしまったでは
ありませんか！！しかもこの状態で最新ファームにもアップデート可能です！

おおっ！書き込み出来た！素晴らしい！V2J39S7となってSWIMが可能です！
もちろん従来のSTM32F0も書き込み可能！
流石モラルを真っ先に投擲機で投げ放つロシア！！おまえらのそういうとこだぞ！！
でもありがとう！！！！！

というわけで十数年前投げ捨ててしまったSTM8の書き込み機能を取り戻すため
かなりの労力を使ってしまったので肝心のSTM8ビルド環境については次回に
解説させていただきます…

XMEGAを使ってみる6 -どうしても外付けSRAMつけたかったので-

●XMEGAよ、やはりお前を救いたい
今から約10年前、ねむいさんはXMEGAをいじっておりましたがFatFsを実装し、SPIの
DMA化で力尽きました。ほんとは256kByteくらいのSRAMを外付けしたりしてやりた
かったのですが残念ながら当時購入したATXMEGA128A1ではチップ単体ではEBIを4PORT
SRAMモードで動作させてもアドレスバスに当たる一部のピンが外部に出ておらず、
SRAMを動作せしめることができませんでした(アドレスが1つだけでよいTFT-LCDとか
ならなんの問題もない)。

その後USB機能が付いたATXMEGA128A1Uが登場し、アドレスバスを別のポートに割り当て
できるようになっているとのことで手に入れようと試みて失敗したのが前回です。

この半導体不足で何とか手に入れられないものかと思案した結果、部品がだめなら
製品を買えばよい！と至って久々にAliexpressでお買い物をしました。

MCUZONE製のATXMEGA128A1Uボード。USBブートローダはちゃんと動いたので本物です!

慎重にはがして載せ替えてみました。

ちなみにATXMEGA128A1のドアップ写真を。

オリジナルATXMEGA128A1

謎の縦じまがあるぱちもん。
ATXMEGA128A1UではなくATXMEGA128A1をリマークしたもの。

本物のATXMEGA128A1U！

●外付けSRAM

今回使用する外付けのSRAMは8bitバス,2Mbit(256kByte)のCY7C1010DV33-10ZSXIです。
10年以上前にデジキでかって塩漬けにして以来の活躍です。製造メーカのCypressは
すでにInfineonに食べられてしまっていますね。

SRAMも付けたXMEGA基板の表裏はこんな感じです…
二度とバスの配線とかやりませんよもう！

●回路とコード

すみません回路図めんどくさくて10年前から書いてませんが割り振り表はあるので
まねされる方はそれを参考にしてください。
TFT-LCD駆動用にCS0をつかってしまっているのでSRAMはCS1とします。

外付けSRAM用4Port-EBIの設定です。実行する関数はmain関数より早く実行した方が
良いので".init5"セクションに配置します。

EBIの設定のほかにheap領域は外部RAMで行えるようにheapの初期設定も行います。
__malloc_heap_start__malloc_heap_endにheap領域を示すアドレスを代入します。
__malloc_heap_endってなんで固定値0xFFFFなのかについては最後に解説します

また、上記のコードで書いてあった変数"__extram_end"はリンカスクリプト内で
定義します。コード内で値の設定を行うときは&を忘れずに。

以上で外付けSRAMを使う準備ができました。

●動いた！…しかし

載せ替えたXEGAにプログラムを書き込みFatfsの動作を確認です。
チップリビジョンはATXMEGAA1Uを示す'L'になってますね。

mallocで領域確保したりちゃんとできてますね★

特筆する点はFatFsの転送スピードです！
内蔵RAMは8kByteしかないので転送用のバッファも少ししか取れずDMAの恩恵に
預かれなかったのですが、外付けで32kByteとってやると断然違います！
これだけでもわざわざATXMEGA128A1Uを手に入れた甲斐がありました！

しかし…

●立ちはだかる16bitの壁

さて、上でさらっと述べましたが何も考えないで内蔵RAMのように気軽に使用できる
のはメモリのアドレスが0xFFFFまでです。つまり最大でも64kByteまでしかだめです。
今回の作例ではメモリアドレス0x005000から開始しているので0xFFFF-0x5000=0xAFFF
で、10進数に治すと45055Byte分しか楽に使えません。

そこから先の世界に踏み出そうとすると10年以上前に頭を抱えた24bitアドレス問題に
直面することとなります。私の作例では一応24bitアドレスアクセスルーチンもテスト
の一部として入れております。DMAに関しては最初っから24bit分レジスタが用意されて
いるので心配はありません。

というわけでがんむばって256kByteのSRAMくっつけてたのがつけてから64KByte分
くらいしか得しないことを気づいてしまいましたが10年来心に抱え続けていたものに
決着をつけることができました。

世間はUPDIなAVR-DBシリーズに移行している中で盛大な寄り道をしてしまいましたが
今回頭を唸らせた経験はきっと役に立つでしょう(やばい思想にはまっている目で)。

今回の成果を反映したものをおきぱにおいておきます。忘れたころにXMEGA触る人に
少しくらい役に立つと期待しております。