Stlink: STM32L052K8 पर फ्लैश करने का प्रयास फ्लैश मेमोरी को दूषित करता है

यह एक अजीब समस्या है, मैं तुरंत यह नहीं बता सका कि समस्या का कारण क्या है। मुझे लगता है कि L1 लोडर L0 चिप्स के साथ संगत है क्योंकि वे लगभग समान हैं।

यह थोड़ा अजीब लगता है - मुझे बताएं कि क्या कोई डिबग फ़्लैग है या ऐसा कुछ है जिसे मुझे अधिक जानकारी प्रदान करने के लिए चालू करना चाहिए।

एक योगिनी के बजाय सेंट-फ्लैश के साथ एक फ्लैट बाइनरी फ्लैश करने का प्रयास करें।

किसी फ़ाइल में फ़्लैश को वापस पढ़ने का प्रयास करें और जीडीबी, या उदाहरण के साथ इसकी तुलना या जांच करें
एक्स/32x 0x8000000

आपको अपनी वेक्टर तालिका की शुरुआत देखनी चाहिए...
आपका बाइनरी कहां से आया, और आप कैसे जानते हैं कि यह अच्छा है?

यह भी देखते हुए कि आपका पता RAM में है, आपके BOOT पिन की स्थिति क्या है?

मैं एक बार देख लूंगा - मेरा मतलब है कि .elf को डीबगर के साथ अपलोड करने के बजाय .bin फ़ाइलों को कैसे फ्लैश करना है, वैसे भी।

कोड एसटी के उदाहरणों में से एक था, लेकिन मैं एक और नज़र डालूंगा कि वेक्टर टेबल कहाँ स्थित है।

BOOT0 पिन को जमीन पर खींचा गया है, इसलिए मुझे नहीं लगता कि इसे RAM में बूट करना चाहिए।

मैं एक या दो दिनों में उन प्रश्नों पर वापस आऊंगा - सलाह के लिए धन्यवाद!

ठीक है, मैंने L0 परीक्षण कार्यक्रम (विशेष रूप से, ST का LSI आरंभीकरण उदाहरण) को L031K6 न्यूक्लियो -32 बोर्ड में चमकाने की कोशिश की, और यह ठीक काम करता है।

L051K8 पर, हालांकि, मैं अभी भी इस मुद्दे का निरीक्षण करता हूं। मुख्य अंतर यह है कि मैं L051K8 बोर्ड को प्रोग्राम करने के लिए एक सामान्य USB डोंगल का उपयोग कर रहा हूं, और L031K6 न्यूक्लियो बोर्ड के लिए ऑनबोर्ड ST-लिंक/V2-1 डीबगर का उपयोग कर रहा हूं। मैंने यूएसबी डीबगर पर फर्मवेयर अपडेट करने का प्रयास किया, लेकिन इससे मदद नहीं मिली।

मैंने सत्यापित किया है कि वेक्टर तालिका दोनों ही मामलों में arm-eabi-none-nm साथ सही ढंग से रखी गई है: 08000000 R g_pfnVectors

L051K8 पर st-flash write main.bin 0x08000000 साथ .bin फ़ाइल को फ्लैश करने से एक त्रुटि होती है लेकिन फिर भी सफलता की रिपोर्ट करता है। चिप को बाद में कनेक्ट करने से पता चलता है कि प्रोग्राम 0xFFFFFFFFFE पर अटका हुआ है, हालाँकि।

यहाँ से आउटपुट है 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!

लेकिन एसटी की जीयूआई उपयोगिता के साथ फ्लैश मेमोरी को देखते हुए, मुझे .bin फ़ाइल का हेक्स 0x08000000 से शुरू होता है; यह प्रोग्राम की शुरुआत में वेक्टर टेबल जैसा दिखता है। और लिखित मेमोरी 0x080047E0 पर समाप्त होती है, जो प्रोग्राम के आकार के लिए सही लगती है।

मुझे पता नहीं - अगर यह ऐसा कुछ नहीं है जिसे कोई और दोहरा सकता है, तो मुझे लगता है कि यह चिप्स या बोर्ड हो सकता है जिसका मैं उपयोग कर रहा हूं।

नमस्ते,

ब्लू-पिल बोर्ड (STM32F103C8X) के साथ एक ही समस्या
'आर्म-नोन-ईबी-जीडीबी' के साथ हर कार्यक्रम के बाद, मैं सफल हुआ, कार्यक्रम बोर्ड में अच्छी तरह से चलता है लेकिन जब मैं इसे फिर से प्रोग्राम करने की कोशिश करता हूं तो मुझे थीसिस मुद्दे मिलते हैं:

सेंट-उपयोग

[ abdullatif@Host-001 ~]$ सेंट-उपयोग
सेंट-उपयोग 1.5.0
2018-05-04T23:47:27 INFO common.c: डिवाइस पैरामीटर लोड हो रहा है....
2018-05-04T23:47:27 WARN common.c: अमान्य फ्लैश प्रकार, कृपया डिवाइस घोषणा की जांच करें
2018-05-04T23:47:27 जानकारी gdb-server.c: चिप आईडी 00000000 है, कोर आईडी 00000000 है।
2018-05-04T23:47:27 जानकारी gdb-server.c: *:4242 पर सुन रहा है...
2018-05-04T23:47:40 जानकारी gdb-server.c: 0 hw ब्रेकप्वाइंट रजिस्टर मिले
2018-05-04T23:47:40 जानकारी gdb-server.c: GDB कनेक्टेड।

जीडीबी

[ abdullatif@Host-001 बिल्ड]$ arm-none-eabi-gdb Stm32blink.elf
जीएनयू जीडीबी (जीडीबी) 8.1
कॉपीराइट (सी) 2018 फ्री सॉफ्टवेयर फाउंडेशन, इंक।
लाइसेंस 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/ ।
मदद के लिए, "सहायता" टाइप करें।
"शब्द" से संबंधित कमांड खोजने के लिए "एप्रोपोस वर्ड" टाइप करें...
Stm32blink.elf... से प्रतीकों को पढ़ना हो गया।
(जीडीबी) लक्ष्य विस्तारित-रिमोट :424242
रिमोट डिबगिंग का उपयोग कर :4242
0x00000000 में ?? ()
(जीडीबी) लोड
लोड हो रहा है अनुभाग .isr_vector, आकार 0x10c lma 0x8000000
लोड विफल हो गया
(जीडीबी)

अगर मैं बोर्ड को फिर से काम करने के लिए बूटलोडर को 'सेंट-फ्लैश' के साथ फ्लैश करना चाहता हूं।

मुझे विश्वास नहीं हो रहा है कि 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 ID से संबद्ध लेबल 0x0417 ।

मुझे नहीं पता कि L0 -विशिष्ट तर्क इन 'श्रेणी-3' L0x2 चिप्स के साथ समस्याएँ क्यों पैदा कर रहा है; ऐसा लगता है कि यह STM32L031 न्यूक्लियो बोर्ड के साथ ठीक काम करता है, जहां चिप में 0x0425 की एक आईडी होती है जो 'श्रेणी-2' डिवाइस के रूप में पहचान करती है।

STM32L151CC के साथ समान समस्याएँ होना।
यह वही त्रुटि फेंकता है और सत्यापन चरण पर विफल रहता है।
एसटी-लिंक यूटिलिटी के साथ मेमोरी को मैन्युअल रूप से सत्यापित करने से पता चलता है कि फ्लैश सही ढंग से लिखा गया है।
डिवाइस पर कोई पठन/लेखन सुरक्षा सेट नहीं है।

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 के साथ भी यही समस्या है।
मैं सेंट-उपयोग 1.6.1 . का उपयोग कर रहा हूँ

अपने MCU के फ़्लैश को मिटाने का प्रयास करें
इस लेख का प्रयोग करें: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

हो सकता है कि आप STM32Cube पर SWD/JTAG पिन चिह्नित करना भूल गए हों