Stlink: STM32L052K8 にフラッシュしようとすると、フラッシュ メモリが破損します。

これは奇妙な問題で、何が問題の原因なのかすぐにはわかりませんでした。 L1ローダーはL0チップとほぼ同じなので互換性があると思います。

少し奇妙に思えます - 詳細情報を提供するためにオンにする必要があるデバッグ フラグや何かがあれば教えてください。

フラット バイナリを elf ではなく st-flash でフラッシュしてみてください。

フラッシュをファイルに読み戻し、gdb または例で比較または検査してみてください。
x/32x 0x8000000

ベクター テーブルの開始が表示されます...
あなたのバイナリはどこから来たのですか?

また、アドレスが RAM にあるように見える場合、BOOT ピンの状態はどうなっていますか?

見てみましょう - とにかく、デバッガーで .elf をアップロードする代わりに、.bin ファイルをフラッシュする方法を学びたいと思っていました。

コードは ST の例の 1 つでしたが、ベクター テーブルの場所をもう一度見てみましょう。

BOOT0 ピンはグラウンドに引き下げられているため、RAM から起動する必要はないと思います。

これらの質問には 1 日か 2 日以内に返信します - アドバイスありがとうございます。

さて、L0 テスト プログラム (具体的には、ST の LSI 初期化の例) を L031K6 Nucleo-32 ボードにフラッシュしてみましたが、うまくいきました。

ただし、L051K8 ではまだ問題が発生しています。 主な違いは、汎用 USB ドングルを使用して L051K8 ボードをプログラムし、L031K6 Nucleo ボード用のオンボード ST-Link/V2-1 デバッガーを使用していることです。 USB デバッガーでファームウェアを更新しようとしましたが、役に立ちませんでした。

どちらの場合もarm-eabi-none-nmでベクトル テーブルが正しく配置されていることを確認しました: 08000000 R g_pfnVectors

st-flash write main.bin 0x08000000を使用して .bin ファイルを L051K8 にフラッシュすると、エラーがスローされますが、引き続き成功が報告されます。 ただし、後でチップに接続すると、プログラムが 0xFFFFFFFE で止まっていることがわかります。

st-flashからの出力は次のとおりです。

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

しかし、ST の GUI ユーティリティでフラッシュ メモリを見ると、.bin ファイルの 16 進数が 0x08000000 から始まっていることがわかります。 プログラムの最初のベクター テーブルのように見えます。 また、書き込まれたメモリは 0x080047E0 で終わるように見えますが、これはプログラムのサイズに適しているようです。

わかりません。これが他の誰かが複製できるものでない場合、それは私が使用しているチップまたはボードである可能性があります。

こんにちは、

ブルーピル ボード (STM32F103C8X) と同じ問題
「arm-none-eabi-gdb」を使用したすべてのプログラムの後、私は成功し、プログラムはボードでうまく動作しますが、もう一度プログラムしようとすると、次の問題が発生します。

st-util

[ abdullatif@Host-001 ~]$ st-util
st-util 1.5.0
2018-05-04T23:47:27 INFO common.c: デバイス パラメータを読み込んでいます...
2018-05-04T23:47:27 警告 common.c: 無効なフラッシュ タイプ、デバイス宣言を確認してください
2018-05-04T23:47:27 INFO gdb-server.c: チップ ID は 00000000、コア ID は 00000000 です。
2018-05-04T23:47:27 INFO gdb-server.c: *:4242 でリッスンしています...
2018-05-04T23:47:40 INFO gdb-server.c: 0 hw ブレークポイント レジスタが見つかりました
2018-05-04T23:47:40 INFO gdb-server.c: GDB が接続されました。

gdb

[ abdullatif@Host-001ビルド]$ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
Copyright (C) 2018 フリーソフトウェア財団, Inc.
ライセンス GPLv3+: GNU GPL バージョン 3 以降http://gnu.org/licenses/gpl.html
これはフリー ソフトウェアです。自由に変更および再配布できます。
法律で許可されている範囲で、保証はありません。 「ショーコピー」と入力
詳細については、「保証を表示」を参照してください。
この GDB は「--host=x86_64-pc-linux-gnu --target=arm-none-eabi」として設定されました。
構成の詳細については、「show configuration」と入力してください。
バグ レポートの手順については、次を参照してください。
http://www.gnu.org/software/gdb/bugs/ 。
次の Web サイトで GDB マニュアルおよびその他のドキュメント リソースをオンラインで検索してください。
http://www.gnu.org/software/gdb/documentation/ .
ヘルプについては、「ヘルプ」と入力してください。
「apropos word」と入力して、「word」に関連するコマンドを検索します...
Stm32blink.elf からのシンボルの読み取り...完了。
(gdb) ターゲット拡張リモート:4242
:4242 を使用したリモート デバッグ
0x00000000 in ?? ()
(gdb) ロード
ロード セクション .isr_vector、サイズ 0x10c lma 0x8000000
ロードに失敗しました
(gdb)

ボードが再び動作するようにするには、「st-flash」でブートローダーをフラッシュする必要があります。

その F103 の問題が私が見てきたものと同じであるとは確信が持てません。 このツールではかなり適切にサポートされているようで、L0 の問題は空のチップでも発生します。

この号の元のタイトルは間違っていました。 この現象は、次の 2 つのデバイスで発生します。

• STM32L052K8

• STM32L082KZ

src/chipid.cを見ると、L0x1 および L0x3 チップのリファレンス マニュアルのみが設定について参照されていることがわかりました。 L0x2 チップに大きな違いはありますか?

次の diff は、この問題を (STM32L052K8 を使用して) 完全に解決しているように見えますが、理想的な解決策ではないと推測しています。

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

この変更により、ID 0x0417関連付けられた一般的なL0x3ラベルで識別されるチップからの一括消去のL0固有の動作が削除されます。

L0固有のロジックがこれらの「Category-3」 L0x2チップで問題を引き起こしている理由がわかりません。 チップの ID が0x0425で、「Category-2」デバイスとして識別される STM32L031 Nucleo ボードでは問題なく動作するようです。

STM32L151CC でも同様の問題が発生します。
同じエラーがスローされ、検証ステップで失敗します。
ST-Link ユーティリティを使用して手動でメモリを検証すると、フラッシュが正しく書き込まれていることがわかります。
デバイスに読み取り/書き込み保護が設定されていません。

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff : 問題がリリース v1.5.1 でまだ存在するかどうかを確認してください。

もちろん、STM32L0 カテゴリ 2 チップでもこれが発生するかどうかを確認できてうれしいです。

ただし、私のボードのほとんどはATMに保管されているので、5月に引っ越しが完了するまではおそらくそれを行うことはできません. すみません。

@WRansohoff : これに関する最新情報はありますか?

こんにちは、STM32L433RC でも同じ問題があります。
私は st-util 1.6.1 を使用しています

MCU のフラッシュを消去してみてください
この記事を使用してください: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

STM32Cube で SWD /JTAG ピンをマークするのを忘れたかもしれません。