死んでるのでスタバへ現実逃避。
一昨日の午後からだから丸2日間となるが、STM32H743のUART受信がhangupで爆裂死亡中。
治らん。治せん。
UARTのトラブルなんて、TXRX逆だったとか、9600bpsだったぐらいしかないもんね。1Hも掛からずに動かせるもんだ。例外はない、今までは。
ところが今、HAL₋UART₋RECIEVE₋IT()をcallすると一発百中でhangupするんだ。
H743には7〜8個のUARTが載っていて、動いてるUARTもある。
動くUART:FT232→H743(UART8)
死ぬUART:STM32G030→H743(UART7)
それならばG030原因説を想起するのが通常であるから、G030起動時に出すglitchがH743のUARTのstate machineに爪痕を残してるんじゃないかという方向性で、pullup-downやUART初期化を延々と試して来たのが今日のお昼頃までだった。しかし徒労だった。
割り込み関数でなく、blocking関数だと僅かにloop数回ぐらいなら動く。HAL₋UART₋RECIEVE()
そこでbuffer overrun系かと考え、baud rate下げたり、G030の送信を毎秒1文字に減らしてみたが徒労。ヒラサカ帰責のbuffer操作はやってないのでボクチン原因説は無いの。
また、UARTのstatus registerに何らの兆候もなく静かに発狂に至っている。
オイオイオイ、UARTなんか簡単すぎてメスを入れるところ無いんだぜ。
エラッタは見てないけどUARTなんかでなぁ......
家に帰ったら、、、
・G030を切断してFT232をつけてみる
・別のportで試してみる
fuckすぎる無間地獄
ーーーー
家にて、、、
STM32G030を撤去してもやっぱりhangupする.
RXをpullup/pulldownして試してもhangupする.
G030原因とか、FT232なら動くはずとか、そうゆう問題じゃないわこれ.
UART3,UART4,UART5,UART7を試したが全部同じ症状.portが電気的に焼けてしまったわけじゃなさそう.
ただしUART8はFT232で円満に動いてる.
ーーーー
おぼろげに見えてきたかもなこと.
H743の6個のUARTを起動している.
ただし外部と接続しているのは今のところ7と8だけ.
3456のRXTXはopenのままで、RECIEVE()とかしてない放置PLAY.
この、UARTを起動はしてるが放置PLAYな状態(ゾンビUART)がガンな気がしてきた.openなRX端子にnoiseが入ってないわけがないし.
MX_UART4_Init()などをコメントアウトしたけど挙動不審は相変わらずだった.RCCからclkが供給されてる時点で軽く起動してたりするのかな?
ちなみに3457は抜き挿し自由にしたいんだが、構想倒れか?
エグい
ゾンビUARTを削除してみたが不具合解消せず.
ーーーー
運用を変えてみたら、とりあえず動いた.
前提:G030が毎秒1byte送信するのをH743が円満に受信できるか?
従来の運用 UART8で実績あり
初回のみ、FLAGに頓着せずRECIEVE_IT()
↓
RX完了CallBackが呼ばれる①
↓
同callback内で、受信データ処理
↓
同callback内で、次の受信のためFLAGに頓着せずRECIEVE_IT() →hungup
↓
別の仕事をしつつ①を待つ
いま実験的にやってみた運用 UART7がこれで動いた
UART7 IRQが呼ばれる②
↓
同IRQ内で、受信データ有無FLAGをチェックする
↓
受信データが溜まっているならRECIEVE_IT()
↓
RX完了CallBackが呼ばれる
↓
同callback内で、受信データ処理
↓
別の仕事をしつつ②を待つ
これだとねぇ、、、RECIEVE_IT()の動作が違うんですよねぇ.
従来の運用では、
・受信データ無しなら受信するまで待って割り込み
・受信データ有りなら即時割り込み
いま実験的にやった運用では、
・受信データ無しならhangup
・受信データ有りなら即時割り込み
こんなpollingめいたことやりたくないんだけど、なんなのこの違い?
RECIEVE_IT()の動作modeを制御するuser settingがあるのではないかと考えたくもなる.
STM32cubeMXのUART設定に違いがある.
↓UART8
↓UART7いかにもこれだと思ってしまうが、しかしこれで動作が変わることは無かった迷宮.
ーーーー
3日目に突入.
上記対処で円満に動かせたかに見えたのですが、、、"hello"という文字列のうち先頭の'h'しか受信できない.
すなわち、
RECIEVE_IT(,,1) なら円満に1文字受信できるけど、
RECIEVE_IT(,,5) だと即hangup.
5文字受信無理は我慢するとして、"hello"の1文字受信ならば連続5回割り込みがかかると期待したのだけれどそうはならずに、"ello"はロストしちゃってる.あかん
ーーーー
3日目が暮れました.
シンプルなblocking関数であっても複数byte受信だと即hangupする.
万策尽きたので、初心に戻ってUARTが本当に動くのかを確かめることにした.
UART7,UART8,TIM以外のperipheralを全部削除し、sourceもUART7,UART8,TIM関連だけ残して全削除.これでUART7は正常に動くようになった.
モグラ叩きの始まり.
これから4日目に入ります.
読者
返信削除とりあえず一晩寝て考えてみる
バグっているときは気づかないこともわかることがある
ゾンビがくる!
削除ゾンビがそこまで来てる!
murasaki
返信削除UARTはハード的にはハング考えづらいですね。
ハングというのがHAL₋UART₋RECIEVE₋IT()から戻ってこないことを指しているなら関数の中で何か待ちっぱなしになっているとかですかね。あとはチャンネルごとに割り込みベクタ別になっていてそのあたりの初期化がうまくいってないとか。
TIM割込みすら効かなくなるのでどこかの無限loopとは違いそう
削除debuggerで追いかけると再現しなくて
削除まだ詰んでいます
>debuggerで追いかけると再現しなくて
削除うはは。このセリフ、
・何回聞いたかわからない
ですね・・・
※聞いたって言うか、いつも「私が」言ってるんですが(笑)
「デバッガーって何なのよ?」って、いつも思う。
こうなると、古典的な「printf 攻撃」位しか、手が無くなるんだよなー
って言うか「ワンチップマイコン」だと、その手も使えないし。
※それこそ、こんなの
https://www.youtube.com/watch?v=FWiaG3k2_D4
【朗報】マイコンの中身を丸裸にするツールが発売となりました。
使いたくなるけど、コレ使うと
・再現しなくなる
のがオチ。
冗談はさておき、何となくですが、
削除・HAL₋UART₋RECIEVE₋IT() が、複数UARTに対応してない
※勿論、そうならば「バグ」ですが、フラグが「1個」しか無くて、複数回呼ぶと「ハングアップ」するとか。ホントに「複数UART」を同時に使うアプリケーションが少ない(こんなに使い倒してるの初めて見た)ので、誰も気付かなかった、とか?
>debuggerで追いかけると再現しなくて
削除「デバッグ中」は、強制的に、
・シングルスレッド相当(人間は、複数の事象を同時には見れないから)
になってしまうので、バグが表面化ない、とか?
アリそうでコワいな・・・
でばっがアタマわるい
削除「基板設計間違えました、ぎゃふん」
みたいな投稿ってPV多いんですよね
人の不幸で楽しんでいる読者がたくさんいる(ひら調べ)
>debuggerで追いかけると再現しなくて
削除・じゃぁ、ずっと「開発環境で動かせば」いいじゃん!
といって、納品機(PC)に「開発環境ごと」納品されてる装置を私は知ってます。
※私はこう言うのが許せないので、自分が開発したモノではそういうことはやったことがありませんが。
つか、そもそも、ふつーの「組込みワンチップマイコン」では出来ませんね。
※かつて某企業が開発したワンチップマイコンに、「量産チップにもデバッグ機能がある」というのがありましたが。
コレは当時は画期的でしたが、独自構成だったので、広がらなかった。
今では「一番安いチップ」でも、「デバッグ機能(SWD みたいなの)」が乗ってるので、ある意味「当たり前な機能」と化してますが。
「パソコンとセットになっている」システムでは「不可能ではない」ですね。(開発環境のライセンスとかは知らん)
それすごい
削除中割りせずにアニメを納品してしまうようなもん
線画でアニメを放送してしまうようなもん
↑う~ん記憶にあるなぁ
>線画でアニメを放送してしまうようなもん
削除イマドキの、CGアニメなら、
・開発画面の動画をそのままキャプチャして、納品
でしょうかね・・・
(技術的には、可能なんだよな。恐ろしや。)
預言である
削除CGアニメのレイアウト作業画面を放送で見る日は近づく
某アニメで、
削除・VSCode の画面ぽいモノ
が、出てきたのがありましたが。
※一部界隈で話題になってた。
なんだっけか
削除女性上司がプログラマ部下のwork folderを監視してる風
主人公はプログラマ
murasaki
返信削除あとは、RX入力がLO固定になっていると連続受信状態(スタートビット入りっぱなし)になるので、受信処理から出てこられなくなるかも。
murasaki
削除受信しっぱなしの場合はステータスレジスタにオーバーランフラグが立つと思いますので、ステータスレジスタに異常がなければLO固定は無いかもですね。
G030のportはLO固定じゃないのはオシロでかくにん!
削除overrun FLAGはしずかちゃん
読者
削除モデムみたいに
ステータスLEDをぴかぴかさせましょう
無駄にLEDをぴかぴかさせるUS製コンピュータ
みたいでかっこいい(あれはどうさ確認だったのか)
そういえば、
削除電源indicatorをわたしは必ずつけますが、
そうゆうのをつけたがらない設計者もいるようです
>電源indicator
削除私は、(予算が許すなら)
・付ける派
ですが。「BlackBox」が、一番コワい。
自分も電源LEDはつける派です。5Vと3.3Vある時は両方つけます。電源入れても何も反応が無いとなんか嫌なのと、電源クロック、リセットあたりの基本的なところの確認を怠って何度も時間を無駄にしているので。
削除あと、どこかショートしていたりすると電源がドロップするので早め異常に気がつけるとか。
受信CallBackの先で次の受信処理をいじるのは直観的にコワイかもですね~。一旦CallBackから抜けて次の受信処理をするのが吉な感じがします。そのCPU向けのシステムを作った受信CallBackの中ではユーザー側のバッファに受信データ移して直ぐに抜けるだろう的な想定しているかもですね。
削除なんとなく昔からの暗黙の了解で、割込み処理やCallBack処理の中ではなるべく仕事を減らすことになっているかも。
多重割込みが有効になっていない場合は、割込み処理やCallBack処理終わってから次の割込みを有効にしている可能性もあるかもです。
+3、+5、+12、-12のANDで電源INDを点灯させたいくらいですわ
削除あとCPUにはLチカをさせる
TIMER直出しではなくて、割込みでLチカさせる
果てしなく長い割込み処理 →ワープの入り口
削除>割込み処理やCallBack処理の中ではなるべく仕事を減らすことになっている
削除Windows の デバイスドライバ作成者の間では有名な話ですが、まさに Windows には、コレに起因した有名なエラーで、
・割り込み処理中に、また割り込みが掛かったので、終了します
と言う意味のエラーがある。
※規定時間内に、割り込み処理が終了しないと「もう次の割り込みが来ちゃったんで、処理できないよー!!」と言って、
・ブルースクリーンになって
死亡します。
※一種の「想定外の事項」だから、仕方ないと言えばそうだが、デバドラでこれが起こると、まあしょうがないとは思う。
「低レベルIO」だと、「メッセージボックス出す」ワケにも行かないし。
ちょっと前まで、よく「(出来の悪い)ビデオドライバ」で、コレが出てた記憶がある。
※今気づいたけど、最近コレ見なくなった代わりに、
・画面に「ゴミ」(以前の描画の残像とか)が出る
ようになった気がする。昔は描画が間に合わないと「律儀に」メッセージを出してたけど、いまは、
・ブルスクよりはマシ
と言って、「画面にゴミ」が、残るのかも知れない。
(そういう奴は、しばらく使ってると「ホントにブルスク」に、なるときもあるな・・・)
役所の待合所の、
削除誰も見てない市政案内みたいな画面がブルスクになってると侘しい気分になるのって俺だけなのかなぁ....
悲しいなぁ....
神奈川県人
返信削除問題が起きている場所が原因ではなく、周辺の影響を受けている時がある・・・・・かな?
昔ICをデバッグしていたら、どうも動きがおかしい。
途中までは動くけど中途半端に不安定・・・・・。
で、その時の原因は・・・・・電源が接続されていませんでした。
電源フィルタを入れてたのですが、部品が欠品して電源が供給されていませんでした。
電源がなくても動くのはすごいですね。
また他の不安定問題の時は、ピン設定ミス・・・・・でした。
はい、入力ピンがプルアップもプルダウンもされずにフロート状態でした。
その時の教訓:空いているピンはとりあえず出力しとけ・・・。
入力専用ピンはプルアップかプルダウンやっときましょう。
ゾンビUARTを削除してみましたが、仮説倒れだった感じがしています
削除FLAG関係を調べているところです
読者
削除電源問題はよくある
全波整流だけで平滑回路なしのACアダプタだったことで
悩んだことある
〇:FT232→H743(UART8)
x:STM32G030→H743(UART7)
UART7 に FT232を接続して
動くかどうかでしょうか?
STM32G030 にFT232 は接続して
動くでしょうか
UART8 にSTM32G030を接続して動くでしょうか
使えるUARTは8だけとか UARTポートの制限があるとか
https://www.family.co.jp/goods/charakuji/6392260.html
削除ファミマ ガールズバンドクライ アクリルスタンド
10時からやってますね 1600yen
あのファミマグッズは高価ですよね なんだかなー
削除トゲトゲメンバーが変なジャケットを着ています
従来の運用だと再帰呼び出しでStack Overflowになっているような……。
返信削除そう懸念したくなりますが、
削除そうならない仕組みになっています
ちな、再帰呼びしたらしたで発狂するのは確認済
ライブラリが、内部で「見るフラグを間違えている」に、一票。
削除※これは、いくら「IDEの設定を見直しても」分からない。
ライブラリのソース(ここで既に「バージョン不一致」がよく起こる 笑)を、「くまなく捜査しないと」分からない。
※FLAGに頓着せずRECIEVE_IT() で、死ぬなら、内部のフラグが、
UARTxで、「テレコ」(Or シャッフル)になってる?
全部「均等」に使ってると気づかない(開発側のテストは、これで合格(笑)とか、UARTxは、UARTyのフラグを見ている、とか・・・
(考え出したら、夜も眠れなくなる・・・もう朝ですが(笑)
※いずれにしても、「特定条件下のエラッタ」の気がするんだけどな。ハード起因カモだし。(IC内部の配線ミスで、同様の事が起きてるとか。)
>baud rate下げたり
削除「一定以下の baud rate だと起こる不具合」
(常に「高速で走ってない」と、不具合が起きる・・・走り屋かよ(笑)
とかあったりして。(ネタなので、真に受けないでください。っと、ホントにあったりしてね。)
ドライバソースは、
削除レジスタ設定してkickしてするっと抜けてる感じ
わかんねー
こう言うことがあるから、
返信削除・組込み系でも Python
なんだろうか・・・
※Pythonは、開発環境=実行環境みたいなもんだから。node.js とかも同じですが。
たしかにそれはいえてる
削除STM32H743 errata sheet
返信削除https://www.st.com/resource/en/errata_sheet/es0392-stm32h742xig-stm32h743xig-stm32h750xb-stm32h753xi-device-errata-stmicroelectronics.pdf
を見てたのですが、
2.20.4 DMA stream locked when transferring data to/from USART
の、Workaround のところに、
・This bit is reserved in the documentation ・・・
というのがあって、まさに、
・コレ、ナイショなんですが、こういう時の為に・・・
って感じの、「秘密の裏口」が、仕掛けてあるんかい!と思った。
※今回の件に関係あるかは知りません
This bit is reserved in the documentation and must be used only on the stream ........
削除ひみつちゃんですね
こんなのもあった。これも、今回の件に関係あるかは知りません
返信削除https://github.com/zephyrproject-rtos/zephyr/issues/57219
drivers: spi: stm32: STM32H7 SPI don't work when when the core clock is high (>200Mhz)
へーこりゃこんなのあるんですね
削除SPIを使ってないので遭遇したことないけど、本当にSPIだけなのかな あははー
ちなみにclockは最高速度で使ってまぁす 480MHz
ねむいさんのブログで、
返信削除https://nemuisan.blog.bai.ne.jp/?eid=244049
>なお、STM32H743のようにバグだらけのRev.Yと修正版のRev.V以降では
まったくの別物になっていた
とかあるし・・・・
※以前に、外人が、
・いいかげんにしろやぁ!>STM32
って、怒ってたのも、さもありなん。
つか、タイトル自体が、
削除>STM32H5を使ってみる2 -フラッシュ書き込み&デバッグ環境作るだけで疲労困憊-
ってな感じで、もう、使うだけで、
・体力勝負
ってのがスゴイ・・・
※やはり、現代の科学技術は、
・先人の、死屍累々の死闘の上に成り立って居る
のだなー、と思った・・・ヲイヲイ
ぎくっ!!
削除ワシのH743はrev.Vだった
胸をなでおろす(ぬかよろこび)
>ワシのH743はrev.Vだった
削除で、
・新バージョンにも、「何が仕掛けられてるか分からない・・・」
って、なってますが。
正しくは、
削除>Revが上がっていったらとんでもない地雷が待ち受けているかもしれません
ですね・・・
rev.Aから始まってYとかVっていうとかなり長い道のり
削除rev.Z まで行ったら、
削除・rev.AA
から、はじまるのかな?(Excel 脳)
>バグだらけのRev.Yと修正版のRev.V以降ではまったくの別物になっていた
削除今気づいたんですが、
・Rev.Y
より、
・Rev.V
のほうが「新しい」ってこと!?順番狂って無いですか?
※単に、ねむいさんが「ねむいので」間違えただけ?
(バグだらけのRev.Vと修正版のRev.Y以降、のつもりだった?)
のか、ホントに、
・Rev.Y より Rev.V のほうが「新しい」
のでしょうか?
謎が謎を呼ぶ・・・・
>ワシのH743はrev.Vだった
削除だとすると「改良版」の、
・Rev.Y
があるのかな・・・?
(でも「バグ」だらけ?)
データシートの Revison history 見てると、時系列的には、
削除・rev Y → rev V
みたいですね。
※というか、変わってるのは「電気的特性」だけで、単に、
・2ロットある?
ダケかもしれません。
※ファブの識別してるだけカモ?歩留まりの良いファブと、そうでないファブがあるのかな?
この際アルファベチカルはやめちゃって、
削除Yesterday →Value line →Exodus →gotoHell
とかにして、
「まだVかぁ」と悟りを開くUser目線
「Y」とか「V」って、
削除・ファブ(製造工場)の、頭文字
じゃないのかなー、と思ってきた。
※なんか違うみたい。Y/V で始まる地名は無い。
ちなみに、調べたら、中国の Shenzhen にも、工場があるみたいです。
iPhoneのSOCにも、桃園fabとKOREAfabがあって、桃園が良いとかいわれてませんでしたっけ?
削除rev.M
rev.K
>iPhoneのSOC
削除ああ、昔なんかありましたね。Kは「発熱が酷い」から、ハズレ、とか。
マジメな話、同じマスクでも、FETの特性が違う
削除(「漏れ電流」が大きいと、発熱する。不純物濃度が違うのかな?)
とか、言われてましたね。
「不純物濃度」の、コントロールが上手く行ってるのと、そうでないので違う、だったかな。
削除なんか、昨日(から、今日にかけて)
返信削除・山手線が、半分止まったり(内回り/外回りが両方あって良かった)
・すんずろうが「農水大臣」になったり
するのを見てて思ったのは、「日本の安全神話」って、結局、
・単にシステムが「単純」だったから、出来てただけ
のような気がしてきた。
日本の列車が「正確に運行している」なんて、もはや、
・過去の話
に、なっちまったよなー、と思った。
※列車運行システムも、「Windows 化」された途端に「しょっちゅう停止」とか、起きてたりして。
「STM32H743」のデータシート見てて、こんだけ機能があれば、
・Windows 3.1 くらいなら、余裕で動くよなー
(多分、linux は動くと思いますが)
と思った。まぁ、これだけシステムが複雑なら、
・UART の、一つや二つ、動かなくても不思議はない
と思った(ヲイヲイ)
結局、人間の脳は「単細胞」だから、複雑なことに付いていけない、のだろうな、と思った。
※「そこでAIですよ!」と、したり顔で言う奴が出てくると思うが、それは結局、
・人類が、AIに「使われるようになる」未来
しか見えないんだが。合掌
1)後期高齢者という昆虫レベルの愚脳しか持たない愚民が死ぬのが先か
削除2)世界史の流転で日本もEUのような移民に荒らされるのが先か
どうやら答えは、2が勝つようです(スガさんのせい)
1が10年遅かったな
JAPにとっては、自ら家畜化されることこそ至福であり安寧なんです
削除>日本もEUのような移民に荒らされる
削除結局、「人間の流動化」を、世界レベルでやれば、エントロピーの法則によって、
・ドンドン、エントロピーが増大していく(世界がランダム化(混乱)していく)
のは、もはや「物理法則」の必定なんだよなー
※いくら、DSがそれに抗おうとして、「コンピュータ管理化」とか進めても、本質的には、なんにもならない。
コンピュータを使うには「それなりの知能」が必要で、全員が「使いこなせる」くらいなら、初めから、
・エントロピーの増大
なんかしない(笑)
まさに、「早いか遅いか」なだけ。
スガさん諸悪の根源
削除昨日停まってたんですか? へー
返信削除おれかんけーねー
読者
返信削除年金法案の陽動作戦っぽい
年金増額はなかったことにした
ニュースはぱったり消えた
日本人を羊の集団と定義して静かに殺すのが自民公明維新立憲の仕事です
返信削除読者
返信削除ラズパイPICO 高性能な時代に
安いからと言って
z80基板が2000円で流行っているので
買おうかと思っているのですよ
コンパイラ1000円
ROM1000円
合計4000円
なので 今週はやめておこう
フロッピー基板作って
FDDをつなぐくらいしか
やることがないんですけど
μPD765 FDC とか
つなげばいいのかしら
8インチFDDユニットつなぐとか
1.2MBのFDDでもいいのかしら?
と夢はひろがる
読者
削除VFOがきもらしいです
いいVFOが手にはいらず苦戦するらしい
中華製しかないそうで
ハードオフに流れていれば
いいものがあるのか(20年前ならともかくいまどき枯渇)
売ってたらすごい8inch FD
削除読者
返信削除たてみんとーが
こーせいねんきん流用で賛成とかいっていて
ものすごく給料の2割まで天引き年金とられて
それをもらえず国民年金に使うとか
消費税をつかうはずが まあ しずかにおだぶつされるのか
神奈川県人
返信削除8inch FDなんてドライブもメディアも今手に入るんですか?
たぶん20~30年くらい前に秋葉原のジャンク屋で8inchドライブを購入する人がいました。
今は知りませんが、製鉄所の制御で使っていたみたいです。
古いシステムを使っていると置き換えができないため使い続けるしかない場合があります。
そのため、PC98シリーズの中古ははやっていると聞いたことがだいぶ昔にありました。
ATボードはマザボのコンデンサが破裂するのはよくあるのと同じように、PC98も電解コンデンサがお亡くなりになって死ぬパターンがあるみたいです。
さすがにニコイチでだましだまし使っても、死ぬ場所は似通ってくるので、まじめなリサイクル業者は、予防処置としてとりあえず電解コンデンサを交換しておいてくれるみたいです。
(苑分お値段は勉強しているみたいです)
ちなみに我が家には置物と貸している5インチFDの外付けドライブがあります。
>予防処置としてとりあえず電解コンデンサを交換
削除素晴らしく良心的です
8inchFDはガコンガコンガッガッという音を愉しめました
かな漢字変換のためにxfer keyを押すと8inchFDがガッガッと音をたてて候補文字を表示してくれるよなかんじ
秘書さんがやってるのを裏山で見てただけですが
dot impact printerも甲高い音をたてていました
PCが回らなくて叩かなくなってしまって静かになってしまったのが残念です
いまどきのパーテーションで区切られた、電話もかかってこないofficeは静かすぎていけねぇや
マウスのクリック音すら気にするとか、静かすぎていけねぇ
削除