Stlink: Mencoba mem-flash ke STM32L052K8 merusak memori flash

Itu masalah yang aneh, saya tidak bisa langsung mengatakan apa yang menyebabkan masalah. Saya pikir pemuat L1 kompatibel dengan chip L0 karena hampir sama.

Kelihatannya agak aneh - beri tahu saya jika ada tanda debug atau sesuatu yang harus saya aktifkan untuk memberikan informasi lebih lanjut.

Coba flash biner datar dengan st-flash daripada elf.

Coba baca kembali flash ke file dan bandingkan, atau periksa dengan gdb, atau contoh
x/32x 0x8000000

Anda akan melihat awal dari tabel vektor Anda...
Dari mana biner Anda berasal, dan bagaimana Anda tahu itu bagus?

Juga mengingat bahwa alamat Anda tampaknya ada di RAM, bagaimana status pin BOOT Anda?

Saya akan melihatnya - Saya sudah lama ingin mempelajari cara mem-flash file .bin alih-alih mengunggah file .elf dengan debugger.

Kode adalah salah satu contoh ST, tapi saya akan melihat lagi di mana tabel vektor berada.

Pin BOOT0 ditarik ke ground, jadi saya tidak berpikir itu harus boot ke RAM.

Saya akan menjawab pertanyaan itu dalam satu atau dua hari - terima kasih atas sarannya!

Baiklah, saya mencoba mem-flash program uji L0 (khususnya, contoh inisialisasi LSI ST) ke papan L031K6 Nucleo-32, dan itu berfungsi dengan baik.

Namun, pada L051K8, saya masih mengamati masalahnya. Perbedaan utamanya adalah saya menggunakan dongle USB generik untuk memprogram papan L051K8, dan debugger ST-Link/V2-1 onboard untuk papan Nucleo L031K6. Saya mencoba memperbarui firmware pada debugger USB, tetapi itu tidak membantu.

Saya memverifikasi bahwa tabel vektor ditempatkan dengan benar dengan arm-eabi-none-nm dalam kedua kasus: 08000000 R g_pfnVectors

Mem-flash file .bin ke L051K8 dengan st-flash write main.bin 0x08000000 menimbulkan kesalahan tetapi masih melaporkan keberhasilan. Menghubungkan ke chip setelahnya menunjukkan bahwa program macet di 0xFFFFFFFE.

Berikut adalah output dari 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!

Tapi melihat memori Flash dengan utilitas GUI ST, saya melihat hex file .bin mulai dari 0x08000000; sepertinya tabel vektor di awal program. Dan memori tertulis sepertinya berakhir pada 0x080047E0, yang sepertinya cocok untuk ukuran program.

Saya tidak tahu - jika ini bukan sesuatu yang bisa ditiru orang lain, saya kira itu bisa jadi chip atau papan yang saya gunakan.

Hai,

Masalah yang sama dengan papan pil biru (STM32F103C8X)
Setelah setiap program dengan 'arm-none-eabi-gdb', saya berhasil, program berjalan dengan baik di papan tetapi ketika saya mencoba memprogramnya lagi saya mendapat masalah tesis:

st-util

[ abdullatif@Host-001 ~]$ st-util
st-util 1.5.0
2018-05-04T23:47:27 INFO common.c: Memuat parameter perangkat....
2018-05-04T23:47:27 PERINGATAN common.c: Jenis flash tidak valid, harap periksa deklarasi perangkat
05-04T23:47:27 INFO gdb-server.c: ID Chip adalah 00000000, ID Inti adalah 00000000.
2018-05-04T23:47:27 INFO gdb-server.c: Mendengarkan di *:4242...
2018-05-04T23:47:40 INFO gdb-server.c: Ditemukan 0 register breakpoint hw
05-04-2018T23:47:40 INFO gdb-server.c: GDB tersambung.

gdb

[ abdullatif@Host-001 build]$ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
Hak Cipta (C) 2018 Free Software Foundation, Inc.
Lisensi GPLv3+: GNU GPL versi 3 atau yang lebih baru http://gnu.org/licenses/gpl.html
Ini adalah perangkat lunak gratis: Anda bebas mengubah dan mendistribusikannya kembali.
TIDAK ADA GARANSI, sejauh diizinkan oleh hukum. Ketik "tampilkan penyalinan"
dan "tunjukkan garansi" untuk detailnya.
GDB ini dikonfigurasi sebagai "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Ketik "tampilkan konfigurasi" untuk detail konfigurasi.
Untuk petunjuk pelaporan bug, silakan lihat:
http://www.gnu.org/software/gdb/bugs/ .
Temukan manual GDB dan sumber dokumentasi lainnya secara online di:
http://www.gnu.org/software/gdb/documentation/ .
Untuk bantuan, ketik "bantuan".
Ketik "apropos word" untuk mencari perintah yang terkait dengan "word"...
Membaca simbol dari Stm32blink.elf...selesai.
(gdb) target jarak jauh diperpanjang: 4242
Debug jarak jauh menggunakan: 4242
0x00000000 masuk ?? ()
(gdb) memuat
Memuat bagian .isr_vector, ukuran 0x10c lma 0x8000000
Pemuatan gagal
(gdb)

Saya harus mem-flash bootloader dengan 'st-flash' jika saya ingin agar board berfungsi kembali.

Saya tidak yakin bahwa masalah F103 sama dengan apa yang saya lihat; tampaknya cukup didukung oleh alat ini, dan masalah L0 terjadi bahkan pada chip kosong.

Judul asli masalah ini salah, maaf; perilaku terjadi pada dua perangkat berikut:

• STM32L052K8

• STM32L082KZ

Saya melihat src/chipid.c dan melihat bahwa hanya manual referensi untuk chip L0x1 dan L0x3 yang dirujuk untuk pengaturan; dapatkah chip L0x2 memiliki perbedaan besar?

Perbedaan berikut tampaknya benar-benar menyelesaikan masalah ini untuk saya (dengan STM32L052K8), tetapi saya menduga itu bukan solusi yang ideal:

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++) {

Perubahan itu menghapus L0 -perilaku khusus untuk penghapusan massal dari chip yang diidentifikasi dengan label L0x3 generik yang terkait dengan ID 0x0417 .

Saya tidak tahu mengapa logika L0 -spesifik mungkin menyebabkan masalah dengan chip 'Category-3' L0x2 ; tampaknya berfungsi dengan baik dengan papan Nucleo STM32L031, di mana chip tersebut memiliki ID 0x0425 yang mengidentifikasi sebagai perangkat 'Kategori-2'.

Memiliki masalah serupa dengan STM32L151CC.
Itu melempar kesalahan yang sama dan gagal pada langkah verifikasi.
Memvalidasi memori secara manual dengan ST-Link Utility menunjukkan bahwa flash ditulis dengan benar.
Tidak ada perlindungan baca/tulis yang diatur pada perangkat.

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 : Harap verifikasi apakah masalah masih ada di Rilis v1.5.1.

Tentu, senang untuk memeriksa apakah ini masih terjadi dengan chip kategori-2 STM32L0.

Sebagian besar papan saya ada di atm penyimpanan, jadi saya mungkin tidak akan dapat melakukannya sampai saya selesai pindah pada bulan Mei. Maaf tentang itu.

@WRansohoff :

Hai, saya memiliki masalah yang sama dengan STM32L433RC.
Saya menggunakan st-util 1.6.1

Coba hapus flash MCU Anda
Gunakan artikel ini: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

Mungkin Anda lupa menandai pin SWD /JTAG di STM32Cube