एक कॉर्टेक्स- M0 / M3 / M4 / M7 पर मेमोरी पतों को मान्य करना

नमस्कार, हेब्र!

दूसरे दिन शासन की शिथिलता के बारे में, एक पड़ोसी पोस्ट की टिप्पणियों में आक्रोश कि माइक्रोकंट्रोलर के बारे में लेख सभी एलईडी द्वारा ही पलक झपक रहे हैं, और मेरे मानक ब्लॉग की असामयिक मृत्यु भी है, जो बहाल करने के लिए बहुत आलसी है, मैं यहां एक अफसोसजनक छोटी रोशनी के बारे में उपयोगी सामग्री स्थानांतरित करूंगा। कोर्टेक्स-एम कोर के साथ काम करने में एक प्रेस ट्रिक - वैधता के लिए यादृच्छिक पते की जांच करना।


कॉर्टेक्स-एम माइक्रोकंट्रोलर्स (सभी) में कहीं भी वर्णित नहीं किए गए कुछ कारण से तैयार सुविधाओं के लिए बहुत उपयोगी और एक ही समय में स्मृति में पते की शुद्धता की जांच करने की क्षमता है। इसके साथ, आप फ्लैश, रैम और ईईप्रॉम के आकार को निर्धारित कर सकते हैं, विशिष्ट बाह्य उपकरणों और रजिस्टरों के एक विशेष प्रोसेसर पर उपस्थिति का निर्धारण कर सकते हैं, ओएस के समग्र स्वास्थ्य को बनाए रखते हुए गिर प्रक्रियाओं को हरा सकते हैं, आदि।

सामान्य मोड में, जब आप कॉर्टेक्स-एम 3 / एम 4 / एम 7 पर गैर-मौजूद पते पर जाते हैं, तो बसफॉल्ट अपवाद को फेंक दिया जाता है, और इसके हैंडलर की अनुपस्थिति में, यह हार्डफॉल्ट को आगे बढ़ाता है। कॉर्टेक्स-एम 0 पर कोई "विस्तृत" अपवाद नहीं हैं (मेमफॉल्ट, बसफॉल्ट, यूसेजफॉल्ट), और कोई भी विफलता हार्डफॉल्ट के तुरंत आगे बढ़ती है।

सामान्य तौर पर, आप हार्डफॉल्ट को अनदेखा नहीं कर सकते - यह एक हार्डवेयर विफलता का परिणाम हो सकता है, उदाहरण के लिए, और डिवाइस का आगे का व्यवहार अप्रत्याशित हो जाएगा। लेकिन विशेष मामले में यह किया जा सकता है और किया जाना चाहिए।

कोर्टेक्स-एम 3 और कोर्टेक्स-एम 4: अधूरी बसफॉल्ट

कोर्टेक्स-एम 3 और उच्चतर पर, पते की वैधता की जाँच करना काफी सरल है - आपको FAULTMASK रजिस्टर के माध्यम से सभी अपवादों (अपवादों को छोड़कर, स्पष्ट रूप से, गैर-मुखौटा) को प्रतिबंधित करना होगा, विशेष रूप से BusFault प्रसंस्करण को अक्षम करें, और फिर चेक किए जा रहे पते पर प्रहार करें और देखें कि BFAR रजिस्टर में BFARVALID झंडा है या नहीं। , यानी बस गलती का पता रजिस्टर। यदि आपने इसे ले लिया है, तो आपके पास बसफॉल्ट था, अर्थात पता गलत है।

कोड इस तरह दिखता है, मानक (गैर-विक्रेता) CMSIS से सभी परिभाषित और कार्य करता है, इसलिए इसे किसी भी M3, M4 या M7 पर काम करना चाहिए:

bool cpu_check_address(volatile const char *address) { /* Cortex-M3, Cortex-M4, Cortex-M4F, Cortex-M7 are supported */ static const uint32_t BFARVALID_MASK = (0x80 << SCB_CFSR_BUSFAULTSR_Pos); bool is_valid = true; /* Clear BFARVALID flag by writing 1 to it */ SCB->CFSR |= BFARVALID_MASK; /* Ignore BusFault by enabling BFHFNMIGN and disabling interrupts */ uint32_t mask = __get_FAULTMASK(); __disable_fault_irq(); SCB->CCR |= SCB_CCR_BFHFNMIGN_Msk; /* probe address in question */ *address; /* Check BFARVALID flag */ if ((SCB->CFSR & BFARVALID_MASK) != 0) { /* Bus Fault occured reading the address */ is_valid = false; } /* Reenable BusFault by clearing BFHFNMIGN */ SCB->CCR &= ~SCB_CCR_BFHFNMIGN_Msk; __set_FAULTMASK(mask); return is_valid; } 

Cortex-M0 और Cortex-M0 +

Cortex-M0 और Cortex-M0 + के साथ, सब कुछ अधिक जटिल है, जैसा कि मैंने ऊपर कहा था, उनके पास BusFault और सभी संबंधित रजिस्टर नहीं हैं, और अपवादों को तुरंत HardFault तक बढ़ा दिया गया है। इसलिए, केवल एक ही रास्ता है - हार्डफॉल्ट हैंडलर को यह समझने में सक्षम बनाने के लिए कि अपवाद जानबूझकर किया गया था, और उस फ़ंक्शन को वापस करने के लिए जिसने इसे कॉल किया, वहां एक झंडा गुजर रहा था जो दर्शाता है कि हार्डफॉल्ट वहां था।

यह पूरी तरह से असेंबलर में किया जाता है। नीचे दिए गए उदाहरण में, रजिस्टर R5 को 1 पर सेट किया गया है, और रजिस्टरों R1 और R2 को दो "मैजिक नंबर" लिखे गए हैं। यदि हार्डफॉल्ट चेक किए जा रहे पते पर मान को लोड करने की कोशिश करने के बाद होता है, तो उसे आर 1 और आर 2 के मूल्यों की जांच करनी चाहिए, और यदि वे आवश्यक संख्याएं पाते हैं, तो आर 5 को शून्य पर सेट करें। R5 का मान एक विशेष चर के माध्यम से syshech कोड में स्थानांतरित किया जाता है जो कि इस रजिस्टर से पूरी तरह से बंधा हुआ है, कोडांतरक में इकट्ठे होने का पता निहित है, हम सिर्फ यह जानते हैं कि arm-none-eabi में फ़ंक्शन का पहला पैरामीटर R0 में रखा गया है।

 bool cpu_check_address(volatile const char *address) { /* Cortex-M0 doesn't have BusFault so we need to catch HardFault */ (void)address; /* R5 will be set to 0 by HardFault handler */ /* to indicate HardFault has occured */ register uint32_t result __asm("r5"); __asm__ volatile ( "ldr r5, =1 \n" /* set default R5 value */ "ldr r1, =0xDEADF00D \n" /* set magic number */ "ldr r2, =0xCAFEBABE \n" /* 2nd magic to be sure */ "ldrb r3, [r0] \n" /* probe address */ ); return result; } 

अपने सरलतम रूप में हार्डफॉल्ट हैंडलर का कोड इस तरह दिखता है:

 __attribute__((naked)) void hard_fault_default(void) { /* Get stack pointer where exception stack frame lies */ __asm__ volatile ( /* decide if we need MSP or PSP stack */ "movs r0, #4 \n" /* r0 = 0x4 */ "mov r2, lr \n" /* r2 = lr */ "tst r2, r0 \n" /* if(lr & 0x4) */ "bne use_psp \n" /* { */ "mrs r0, msp \n" /* r0 = msp */ "b out \n" /* } */ " use_psp: \n" /* else { */ "mrs r0, psp \n" /* r0 = psp */ " out: \n" /* } */ /* catch intended HardFaults on Cortex-M0 to probe memory addresses */ "ldr r1, [r0, #0x04] \n" /* read R1 from the stack */ "ldr r2, =0xDEADF00D \n" /* magic number to be found */ "cmp r1, r2 \n" /* compare with the magic number */ "bne regular_handler \n" /* no magic -> handle as usual */ "ldr r1, [r0, #0x08] \n" /* read R2 from the stack */ "ldr r2, =0xCAFEBABE \n" /* 2nd magic number to be found */ "cmp r1, r2 \n" /* compare with 2nd magic number */ "bne regular_handler \n" /* no magic -> handle as usual */ "ldr r1, [r0, #0x18] \n" /* read PC from the stack */ "add r1, r1, #2 \n" /* move to the next instruction */ "str r1, [r0, #0x18] \n" /* modify PC in the stack */ "ldr r5, =0 \n" /* set R5 to indicate HardFault */ "bx lr \n" /* exit the exception handler */ " regular_handler: \n" /* here comes the rest of the fucking owl */ ) 

अपवाद हैंडलर छोड़ने के क्षण में, कोर्टेक्स रजिस्टरों को फेंकता है, जो कि स्टैक पर हैंडलर (R0-R3, R12, LR, PC ...) द्वारा दूषित होने की गारंटी है। पहला टुकड़ा - यह पहले से ही सबसे अधिक तैयार हार्डफॉल्ट हैंडलर में है, शुद्ध नंगे धातु के नीचे लिखे गए लोगों को छोड़कर - यह निर्धारित करता है कि कौन सा स्टैक: ओएस में काम करते समय, यह या तो एमएसपी या पीएसपी हो सकता है, और उनके पास अलग-अलग पते हैं। नंगे धातु परियोजनाओं में, एमएसपी स्टैक (मेन स्टैक पॉइंटर) आमतौर पर एक प्राथमिकता स्थापित की जाती है, बिना जाँच के - क्योंकि PSP (प्रोसेस स्टैक पॉइंटर) प्रक्रियाओं की कमी के कारण नहीं हो सकता है।

वांछित स्टैक निर्धारित करने और R0 में इसका पता लगाने के बाद, हमने इसमें से मानों R1 (ऑफसेट 0x04) और R2 (ऑफसेट 0x08) को पढ़ा, जादू शब्दों से इसकी तुलना करें, यदि दोनों मैच - हम स्टैक से पीसी मान (ऑफसेट 0x18) पढ़ते हैं, 2 जोड़ें (2 बाइट्स - कोर्टेक्स-एम * पर निर्देश का आकार) और इसे वापस स्टैक पर सहेजें। यदि ऐसा नहीं किया जाता है, जब हम हैंडलर से लौटते हैं, तो हम खुद को उसी निर्देश पर पाएंगे जो वास्तव में अपवाद का कारण था, और हम हमेशा हलकों में चलेंगे। परिशिष्ट 2 हमें वापसी के समय अगले निर्देश पर ले जाता है।

* अद्यतन। टिप्पणियों में, कॉर्टेक्स-एम पर निर्देशों के आकार के बारे में सवाल उठाया गया था, मैं यहां सही उत्तर दूंगा: इस मामले में, दुर्घटना का कारण एलडीआरबी निर्देश है, जो दो संस्करणों - 16-बिट और 32-बिट में ARMv7-M आर्किटेक्चर में उपलब्ध है। कम से कम एक शर्त पूरी होने पर दूसरा विकल्प चुना जाएगा:

• लेखक ने LDRB के बजाय स्पष्ट रूप से निर्देश LDRB को इंगित किया। (हम नहीं करते)
• R7 के ऊपर के रजिस्टरों का उपयोग किया जाता है (हमारे लिए - R0 और R3)
• 31 बाइट्स से अधिक ऑफसेट निर्दिष्ट किया गया है (हमारे पास ऑफ़सेट नहीं है)

अन्य सभी मामलों में (अर्थात, जब ऑपरेशन्स निर्देश के 16-बिट संस्करण के प्रारूप को फिट करते हैं), कोडांतरक को 16-बिट संस्करण का चयन करना होगा ।

इसलिए, हमारे मामले में, हमेशा एक 2-बाइट अनुदेश होगा जिसे ऊपर ले जाने की आवश्यकता होती है, लेकिन यदि आप कोड को दृढ़ता से संपादित करते हैं, तो विकल्प संभव हैं।

अगला, आर 5 में 0 लिखें, जो हार्डफॉल्ट में आने के संकेतक के रूप में कार्य करता है। R3 के बाद के रजिस्टरों को विशेष रजिस्टरों से पहले स्टैक में सहेजा नहीं जाता है, और जब हैंडलर से बाहर निकलते हैं, तो उन्हें किसी भी तरह से बहाल नहीं किया जाता है, इसलिए इसे खराब करने या खराब करने के लिए हमारा विवेक नहीं है। इस मामले में, हम R5 को 1 से 0 तक उद्देश्यपूर्ण रूप से बदलते हैं।

इंटरप्ट हैंडलर से वापसी बिल्कुल एक तरीके से की जाती है। हैंडलर में प्रवेश करते समय, एक विशेष मान LRC में लिखा जाता है जिसे EXC_RETURN कहा जाता है, जो हैंडलर से बाहर निकलने के लिए पीसी पर लिखना आवश्यक है - और न केवल इसे लिखें, बल्कि इसे POP या BX कमांड के साथ करें (अर्थात, "mov pc, lr, उदाहरण के लिए, काम नहीं करता है")। , हालांकि पहली बार यह आपको लग सकता है कि यह काम करता है)। बीएक्स एलआर एक अर्थहीन पते पर जाने की कोशिश की तरह दिखता है (एलआर में 0xFFFFFFF1 की तरह कुछ होगा जिसका उस प्रक्रिया के वास्तविक पते से कोई लेना-देना नहीं है जो हमें वापस करने की आवश्यकता है), लेकिन वास्तव में प्रोसेसर पीसी पर इस मान को देखता है (जहां यह जाएगा) स्वचालित रूप से), यह स्टैक से रजिस्टरों को बहाल करेगा और हमारी प्रक्रिया को निष्पादित करना जारी रखेगा - हार्डफॉल्ट को कॉल करने के बाद अगली प्रक्रिया के साथ इस तथ्य के कारण कि हमने मैन्युअल रूप से इस स्टैक में पीसी को 2 से बढ़ा दिया है।

आप निश्चित रूप से , जहां सभी कार्यालयों और आदेशों के बारे में स्पष्ट रूप से पढ़ सकते हैं।

ठीक है, या यदि मैजिक नंबर दिखाई नहीं दे रहे हैं, तो सब कुछ regular_handler पर जाएगा, जिसके बाद सामान्य हार्डफॉल्ट प्रोसेसिंग प्रक्रिया इस प्रकार है - एक नियम के रूप में, यह एक फ़ंक्शन है जो कंसोल को मान रजिस्टर करता है, प्रोसेसर के साथ आगे क्या करना है, आदि का फैसला करता है।

रैम आकार का निर्धारण

इस सबका उपयोग सरल और सीधा है। हम एक फर्मवेयर लिखना चाहते हैं जो कई माइक्रोकंट्रोलर्स पर विभिन्न मात्रा में रैम के साथ काम करता है, जबकि हर बार एक पूर्ण कार्यक्रम में रैम का उपयोग करते हुए?

हाँ आसान:

 static uint32_t cpu_find_memory_size(char *base, uint32_t block, uint32_t maxsize) { char *address = base; do { address += block; if (!cpu_check_address(address)) { break; } } while ((uint32_t)(address - base) < maxsize); return (uint32_t)(address - base); } uint32_t get_cpu_ram_size(void) { return cpu_find_memory_size((char *)SRAM_BASE, 4096, 80*1024); } 

यहां अधिकतम जरूरत है ताकि इसके और पते के अगले ब्लॉक के बीच रैम की अधिकतम संभव मात्रा पर कोई अंतराल न हो, जिस पर cpu_check_address टूट जाएगा। इस उदाहरण में, यह 80 KB है। सभी पतों की जांच करने का भी कोई मतलब नहीं है - बस दो नियंत्रक मॉडल के बीच न्यूनतम संभव कदम क्या है, इसे देखने के लिए डेटाशीट को देखें और इसे ब्लॉक के रूप में सेट करें।

बूटलोडर को प्रोग्रामेटिक संक्रमण कहीं नहीं के बीच में स्थित है

कभी-कभी आप और भी अधिक मुश्किल चालें कर सकते हैं - उदाहरण के लिए, कल्पना करें कि आप अपने बूटलोडर को लिखने के लिए परेशान किए बिना UART या USB के माध्यम से फर्मवेयर अपडेट मोड में स्विच करने के लिए प्रोग्राम फैक्ट्री के बूटलोडर STM32 पर कूदना चाहते हैं।

STM32 बूटलोडर सिस्टम मेमोरी नामक क्षेत्र में स्थित है, जिसे आपको जाने की आवश्यकता है, लेकिन एक समस्या है - इस क्षेत्र में न केवल प्रोसेसर की विभिन्न श्रृंखलाओं पर अलग-अलग पते हैं, बल्कि एक ही श्रृंखला के विभिन्न मॉडलों (एक महाकाव्य प्लेट AN2606 पर मिल सकती है) पेज 22 से 26)। जब आप सामान्य रूप से प्लेटफ़ॉर्म पर संबंधित कार्यक्षमता को जोड़ते हैं, और केवल एक विशिष्ट उत्पाद के लिए नहीं, तो आप बहुमुखी प्रतिभा चाहते हैं।

CMSIS फ़ाइलों में, सिस्टम मेमोरी का प्रारंभ पता भी गायब है। बूटलोडर आईडी द्वारा इसे निर्धारित करना संभव नहीं है, क्योंकि यह एक चिकन और अंडे की समस्या है - बूटलोडर आईडी सिस्टम मेमोरी के अंतिम बाइट में निहित है, जो हमें पते के सवाल पर वापस लाती है।

हालाँकि, अगर हम STM32 मेमोरी कार्ड को देखते हैं, तो हम कुछ इस तरह देखेंगे:


इस मामले में, हम सिस्टम मेमोरी वातावरण में रुचि रखते हैं - उदाहरण के लिए, शीर्ष पर एक बार-प्रोग्राम योग्य क्षेत्र है (सभी एसटीएम 32 में नहीं) और विकल्प बाइट्स (सभी में)। यह संरचना न केवल विभिन्न मॉडलों में, बल्कि विभिन्न एसटीएम 32 लाइनों में भी देखी जाती है, जिसमें ओटीपी की उपस्थिति और सिस्टम मेमोरी और विकल्पों के बीच के पतों की उपस्थिति में अंतर होता है।

लेकिन हमारे लिए इस मामले में, सबसे महत्वपूर्ण बात यह है कि विकल्प बाइट्स का प्रारंभ पता नियमित CMSIS हेडर में है - इसे वहां OB_BASE कहा जाता है।

आगे सरल है। हम पहले वैध या अमान्य पते को खोजने के लिए फ़ंक्शन लिखते हैं या निर्दिष्ट एक से नीचे:

 char *cpu_find_next_valid_address(char *start, char *stop, bool valid) { char *address = start; while (true) { if (address == stop) { return NULL; } if (cpu_check_address(address) == valid) { return address; } if (stop > start) { address++; } else { address--; } }; return NULL; } 

और ऑप्शन बाइट्स से नीचे देखें, या तो सिस्टम मेमोरी का अंत, या इससे सटे OTP का, और फिर सिस्टम मेमोरी की शुरुआत दो पास में:

 /* System memory is the valid area next _below_ Option bytes */ char *a, *b, *c; a = (char *)(OB_BASE - 1); b = 0; /* Here we have System memory top address */ c = cpu_find_next_valid_address(a, b, true); /* Here we have System memory bottom address */ c = cpu_find_next_valid_address(c, b, false) + 1; 

और बहुत कठिनाई के बिना, हम इसे एक फ़ंक्शन में व्यवस्थित करते हैं जो सिस्टम मेमोरी की शुरुआत पाता है और उस पर कूदता है, अर्थात, यह बूटलोडर को लॉन्च करता है:

 static void jump_to_bootloader(void) __attribute__ ((noreturn)); /* Sets up and jumps to the bootloader */ static void jump_to_bootloader(void) { /* System memory is the valid area next _below_ Option bytes */ char *a, *b, *c; a = (char *)(OB_BASE - 1); b = 0; /* Here we have System memory top address */ c = cpu_find_next_valid_address(a, b, true); /* Here we have System memory bottom address */ c = cpu_find_next_valid_address(c, b, false) + 1; if (!c) { NVIC_SystemReset(); } uint32_t boot_addr = (uint32_t)c; uint32_t boot_stack_ptr = *(uint32_t*)(boot_addr); uint32_t dfu_reset_addr = *(uint32_t*)(boot_addr+4); void (*dfu_bootloader)(void) = (void (*))(dfu_reset_addr); /* Reset the stack pointer */ __set_MSP(boot_stack_ptr); dfu_bootloader(); while (1); } 

यह विशिष्ट प्रोसेसर मॉडल पर निर्भर करता है ... कुछ भी निर्भर नहीं करता है। तर्क उन मॉडलों पर काम नहीं करेगा जिनके पास ओटीपी और सिस्टम मेमोरी के बीच एक छेद है - लेकिन मैंने जांच नहीं की है कि क्या कोई भी है। सक्रिय रूप से ओटीपी - चेक के साथ काम करेगा।

अन्य ट्रिक्स आपके कोड से बूटलोडर को कॉल करने के लिए केवल सामान्य प्रक्रिया पर लागू होते हैं - स्टैक पॉइंटर को रीसेट करने के लिए मत भूलना और बाह्य उपकरणों को शुरू करने से पहले बूटलोडर को छोड़ने की प्रक्रिया को कॉल करें, घड़ी की गति, आदि। इसकी अतिसूक्ष्मवाद के कारण, बूटलोडर पर रोक सकता है परिधि को इनिशियलाइज़ करें और उम्मीद करें कि यह डिफ़ॉल्ट स्थिति में है। अपने प्रोग्राम में किसी अनियंत्रित स्थान से बूटलोडर को कॉल करने का एक अच्छा विकल्प आरटीसी बैकअप रजिस्टर या केवल एक जादू नंबर की याद में एक ज्ञात पते पर लिखना है, इस नंबर को आरम्भ करने के पहले चरणों में प्रोग्राम रिबूट और जांचें।

PS चूंकि प्रोसेसर मेमोरी कार्ड के सभी पते 4 से सबसे खराब स्थिति में संरेखित किए गए हैं, इसलिए उपरोक्त प्रक्रिया को एक के बजाय 4 बाइट के वेतन वृद्धि में उनके माध्यम से कदम बढ़ाने के विचार से तेज किया जाएगा।

महत्वपूर्ण सूचना

एनबी: कृपया ध्यान दें कि किसी विशिष्ट नियंत्रक पर किसी विशिष्ट पते की वैधता जरूरी नहीं है कि उस पते पर स्थित कार्यक्षमता की वास्तविक उपस्थिति का संकेत हो। उदाहरण के लिए, कुछ वैकल्पिक परिधीय ब्लॉक को नियंत्रित करने वाले रजिस्टर का पता मान्य हो सकता है, हालांकि ब्लॉक स्वयं इस मॉडल में अनुपस्थित है। निर्माता की ओर से, सबसे दिलचस्प चालें संभव हैं, आमतौर पर विभिन्न प्रोसेसर मॉडल के लिए एक ही क्रिस्टल के उपयोग में निहित हैं। हालांकि, ज्यादातर मामलों में, ये प्रक्रियाएं काम करती हैं और बहुत उपयोगी साबित होती हैं।