Stlink: محاولة الوميض إلى STM32L052K8 يفسد ذاكرة الفلاش

هذه مشكلة غريبة ، لم أستطع تحديد سبب المشكلة على الفور. أعتقد أن اللودر L1 متوافق مع شرائح L0 لأنها متشابهة تقريبًا.

يبدو غريباً بعض الشيء - يُرجى إعلامي إذا كانت هناك أي علامات تصحيح أو شيء يجب تشغيله لتوفير مزيد من المعلومات.

حاول وميض ثنائي مسطح باستخدام st-flash بدلاً من قزم.

حاول إعادة قراءة الفلاش إلى ملف ومقارنته أو فحصه باستخدام gdb أو مثال
x / 32x 0x8000000

يجب أن ترى بداية جدول المتجه الخاص بك ...
من أين أتى نظامك الثنائي ، وكيف تعرف أنه جيد؟

أيضًا نظرًا لأن عنوانك يبدو في ذاكرة الوصول العشوائي ، فما حالة رقم تعريف BOOT الخاص بك؟

سألقي نظرة - كنت أقصد تعلم كيفية وميض ملفات .bin بدلاً من تحميل ملف .elf باستخدام مصحح أخطاء ، على أي حال.

كان الرمز أحد أمثلة ST ، لكنني سألقي نظرة أخرى على مكان وجود جدول المتجه.

تم سحب دبوس BOOT0 إلى الأرض ، لذلك لا أعتقد أنه يجب تشغيله في ذاكرة الوصول العشوائي.

سأعود على هذه الأسئلة في غضون يوم أو يومين - شكرًا لك على النصيحة!

حسنًا ، لقد حاولت وميض برنامج اختبار L0 (على وجه التحديد ، مثال تهيئة LSI الخاص بـ ST) إلى لوحة L031K6 Nucleo-32 ، وهذا يعمل بشكل جيد.

ومع ذلك ، ما زلت ألاحظ المشكلة في L051K8. الاختلاف الرئيسي هو أنني أستخدم دونجل USB عام لبرمجة لوحة L051K8 ، ومصحح الأخطاء ST-Link / V2-1 للوحة L031K6 Nucleo. حاولت تحديث البرنامج الثابت على مصحح أخطاء USB ، لكن ذلك لم يساعد.

لقد تحققت من وضع جدول المتجه بشكل صحيح مع arm-eabi-none-nm في كلتا الحالتين: 08000000 R g_pfnVectors

يؤدي وميض ملف .bin إلى L051K8 باستخدام st-flash write main.bin 0x08000000 حدوث خطأ ولكن لا يزال يتم الإبلاغ عن النجاح. يُظهر الاتصال بالشريحة بعد ذلك أن البرنامج عالق عند 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 ، أرى أن ملف .bin السداسي يبدأ من 0x08000000 ؛ يبدو مثل جدول المتجه في بداية البرنامج. ويبدو أن الذاكرة المكتوبة تنتهي عند 0x080047E0 ، والتي تبدو مناسبة لحجم البرنامج.

لا أعلم - إذا لم يكن هذا شيئًا يمكن لأي شخص آخر تقليده ، أفترض أنه يمكن أن يكون الرقائق أو الألواح التي أستخدمها.

أهلا،

نفس المشكلة مع لوحة الحبة الزرقاء (STM32F103C8X)
بعد كل برنامج يحتوي على "arm-none-eabi-gdb" ، نجحت ، ويعمل البرنامج جيدًا في اللوحة ، لكن عندما أحاول برمجته مرة أخرى ، واجهت أطروحات المشكلات:

ش-استخدام

[ abdullatif @ Host-001 ~] $ st-util
st- استخدام 1.5.0
2018-05-04T23: 47: 27 INFO common.c: تحميل معلمات الجهاز ....
2018-05-04T23: 47: 27 WARN common.c: نوع فلاش غير صالح ، يرجى التحقق من بيان الجهاز
2018-05-04T23: 47: 27 INFO gdb-server.c: معرف الشريحة هو 00000000 ، معرف النواة هو 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 build] $ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1.0 تحديث
حقوق النشر (C) 2018 Free Software Foundation، Inc.
الترخيص GPLv3 +: GNU GPL الإصدار 3 أو أحدث http://gnu.org/licenses/gpl.html
هذا برنامج مجاني: أنت حر في تغييره وإعادة توزيعه.
لا يوجد ضمان ، إلى الحد الذي يسمح به القانون. اكتب "إظهار النسخ"
و "إظهار الضمان" للحصول على التفاصيل.
تم تكوين GDB هذا كـ "--host = x86_64-pc-linux-gnu --target = arm-none-eabi".
اكتب "عرض التكوين" للحصول على تفاصيل التكوين.
للحصول على إرشادات الإبلاغ عن الأخطاء ، يرجى الاطلاع على:
http://www.gnu.org/software/gdb/bugs/ .
ابحث عن دليل GDB وموارد التوثيق الأخرى عبر الإنترنت على:
http://www.gnu.org/software/gdb/documentation/ .
للحصول على المساعدة ، اكتب "help".
اكتب "apropos word" للبحث عن الأوامر المتعلقة بـ "word" ...
قراءة الرموز من Stm32blink.elf ... تم.
(gdb) الهدف البعيد البعيد: 4242
التصحيح عن بعد باستخدام: 4242
0x00000000 بوصة ؟؟ ()
(gdb) تحميل
قسم التحميل. isr_vector ، الحجم 0x10c lma 0x8000000
فشل التحميل
(gdb)

لا بد لي من وميض أداة تحميل التشغيل باستخدام "st-flash" إذا كنت أريد عمل اللوحة مرة أخرى.

لست مقتنعًا بأن مشكلة F103 هي نفسها ما كنت أراه ؛ يبدو أنه مدعوم جيدًا من هذه الأداة ، وتحدث مشكلة L0 حتى على شريحة فارغة.

العنوان الأصلي لهذه المشكلة كان غير صحيح ، آسف ؛ يحدث السلوك على الجهازين التاليين:

• STM32L052K8

• STM32L082KZ

نظرت إلى src/chipid.c ووجدت أنه تمت الإشارة فقط إلى الأدلة المرجعية لرقائق L0x1 و L0x3 للإعدادات ؛ هل يمكن أن يكون لرقائق L0x2 أي اختلافات كبيرة؟

يبدو أن الفرق التالي يحل هذه المشكلة تمامًا بالنسبة لي (باستخدام 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++) {

يزيل هذا التغيير السلوك المحدد L0 للمسح الجماعي من الرقائق المحددة بعلامة L0x3 المرتبطة بالمعرف 0x0417 .

لا أعرف لماذا قد يتسبب المنطق الخاص L0 حدوث مشكلات مع رقائق "الفئة -3" L0x2 ؛ يبدو أنه يعمل بشكل جيد مع STM32L031 Nucleo board ، حيث تحتوي الشريحة على معرف 0x0425 والذي يُعرّف بأنه جهاز "Category-2".

تواجه مشكلات مماثلة مع STM32L151CC.
لقد ألقى نفس الخطأ وفشل في خطوة التحقق.
يوضح التحقق من صحة الذاكرة يدويًا باستخدام ST-Link Utility أن الفلاش مكتوب بشكل صحيح.
لم يتم تعيين حماية للقراءة / الكتابة على الجهاز.

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.

معظم لوحاتي في أجهزة الصراف الآلي ، لذلك ربما لن أتمكن من القيام بذلك حتى أنتهي من الانتقال في مايو. اسف بشأن ذلك.

WRansohoff : أي تحديث لهذا؟

مرحبًا ، لدي نفس المشكلة مع STM32L433RC.
أنا أستخدم st-util 1.6.1

حاول محو وميض MCU الخاص بك
استخدم هذه المقالة: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

ربما نسيت وضع علامة على دبابيس SWD / JTAG في STM32Cube