كما تعلم ، فإن التوافق مع أدوات GNU ودعم GDB يجعل أي بيئة تطوير شائعة تقريبًا مناسبة لتصحيح مجموعة كبيرة من المنصات المدمجة ، في الغالب مجانًا وبشكل قانوني. نظريا.
ما يحدث عمليًا عند محاولة تكوين صداقات مع STM32 و NetBeans ، وهل من الممكن ، من حيث المبدأ ، الحصول على نظام عملي يدعم أحدث الأحجار - تحت القطع.
بعض كلمات الأغاني
أنا حقاً لا أريد ترك الرقاقة. ومع ذلك ، بعد الشراء من قبل Atmela ، غطوا أولاً ، ربما ، واحدة من أكثر العائلات الواعدة في محفظة الشركة - PIC32MM ، ثم خط MIPS بأكمله. أصبح من الواضح أنه في المستقبل المنظور ، فإن الانتقال إلى ARM أمر لا مفر منه ، لأن الرقاقة الدقيقة لمدة عامين لم تدمج دعم وحدات تحكم Atmelovsk في نظامها البيئي ، ولم تقدم أي مزايا لـ "البقاء معنا". على العكس من ذلك ، جعلت سياسة التسعير التصاعدي والصعوبات التنظيمية التقليدية للاندماج Atmelovskiye AWPs أقل جاذبية. في نفس الوقت ، ظهر مشروع تعثرت عليه PIC32MZ. تم اكتساب كتلة حرجة.
لماذا STM: تغطية واسعة للسوق ، تصحيح الميزانية ، بيئة مفتوحة المصدر مجانية كاملة المواصفات تعتمد على المصدر المفتوح SW4STM32 ، حسنًا ، الجانب السياسي - يتم دعم ST Microelectronics من قبل الحكومة الفرنسية كمورد استراتيجي ، لذلك يبدو أن الخروج المفاجئ من السوق أو الاستحواذ ليس مهددًا.
التصحيح - الانطباعات الأولى
تم تثبيت SW4STM32 بالطريقة التقليدية - بالضغط المتكرر على الزر التالي> (* فيما يلي ، يتم إجراء جميع التجارب على Win7 x64). تمت إزالة مشروع تجريبي مناسب لاختبار الوظيفة المطلوبة من حزمة البرامج الثابتة STM32Cube ، وعمل كل شيء بشكل أو بآخر خارج الصندوق. تركت البداية الأولى لمحاكي JTAG انطباعًا: يمكن أن تتناسب الدورة الكاملة للدخول في وضع التصحيح ، بدءًا من الاتصال وتنتهي مع التوقف في بداية main () مع تحديث السياق ، كما يتبين ، في غضون ثانيتين. بالمقارنة مع المصححين بالرقائق الدقيقة (حتى REAL ICE لنصف نصف) ، فإن الفرق في السرعة هو متعدد!
ومع ذلك ، فاجأ شيء غير سارة.
ما هو الخطأ في Eclipse / SW4STM32
عدد لا يحصى من الإعدادات والتنظيم غير المنطقي ، وعناصر القائمة المخفية ، والمنظورات ، وأخطاء الواجهة والتحف البصرية ، والأزرار والوظائف الساخنة الشائعة الاستخدام على شريط الأدوات ، والرسوم التوضيحية الصغيرة الخرقاء ، وغير القابلة للقراءة ، وغياب "Find Usages" ذاتيًا جزئيًا ، ويمكنك التكيف إذا أردت . ولكن: ينسى بانتظام حفظ الملفات المعدلة قبل التجميع ، على الرغم من جميع علامات الاختيار عند الضرورة ؛ مع الحفظ اليدوي القسري ، لا يرى تغييرات ، ويتضح أن التجمع المتزايد غير ذي صلة ؛ لا يوجد إعادة بناء كاملة (التنظيف والبناء) كفريق واحد ، وبعد التنظيف القسري من خلال Clean Project ، يفشل التجميع (الوصول إلى الملفات؟) ويكتمل بنجاح فقط بعد المحاولة الرابعة - لم يعد من الممكن تفسير ذلك بشكل معقول. حتى إصدارات MPLAB X Beta المبنية على NetBeans 6.xx القديمة لم تواجه نفس المشاكل منذ 10 سنوات مثل بيئة التطوير المدعومة رسميًا لـ STM32 اليوم.
بالإضافة إلى ذلك ، مع SW4STM32 ، تم بالفعل طلب 3 نسخ من IDE النموذجية في النظام ، لأنه إلى جانب ذلك لا يزال هناك MPLAB X مسمرًا بقوة إلى NetBeans 8.0.1 ومحدود إلى حد ما (أي أنه من المستحيل استخدامه للغات / منصات أخرى) ، و NetBeans 8.2 لـ Java و C / C ++.
اتضح أن إعداد NetBeans 8.2 للعمل مع STM32 سيزيل مشاكل Eclipse العملية الموصوفة ، ويقلل عدد نسخ IDE ، ويقللها إلى منصة واحدة ، وإن كانت إصدارات مختلفة قليلاً.
أدوات NetBeans 8.2 و GNU ARM
من الأفضل استخدام NetBeans 32 بت ، لأنه بالإضافة إلى مضاعفة استهلاك الذاكرة ، تعذر العثور على الاختلافات في إصدار 64 بت.
عثرت Google بسرعة على
دليل الإعداد . كان الاختلاف الأساسي فقط في نظام التشغيل (لديهم لينكس ضد Win7 x64 بالنسبة لي) ، لذا أصبح تثبيت * nix-environment MSYS ، وهو جزء من حزمة MinGW ، لعبة جوائز. يجب أن تبدو إعدادات Toolchain على النحو التالي:
نقطة مهمة - عند إضافة سلسلة أدوات GNU ARM ، حدد عائلة "GNU MinGW" ، وفي هذه الحالة ستقوم NetBeans باستدعاء MSYS بشكل صحيح. إذا كان Cygwin مثبتًا بالفعل على الجهاز ، فسيكون من المنطقي استخدامه ؛ وبناءً على ذلك ، يجب على عائلة GNU ARM تحديد "GNU Cygwin".
لم يكن تحقيق تجميع ناجح أمرًا سهلاً ، ولكنه بسيط جدًا. نظرًا لأن SW4STM32 يستخدم نفس المحول البرمجي ، فإن النظر في سطر أوامر استدعاء المحول البرمجي في SW4STM32 ونسخ المفاتيح المفقودة في خصائص المشروع → مترجم C → خيارات إضافية
نحصل على نفس نتيجة المخرجات بالضبط ، ولكن مع وجود اختلاف عملي مهم - يتم جمع كل شيء في المرة الأولى ، هناك Clean and Build ويعمل بشكل جيد:
ولكن يمكن أيضًا تحسين هذه النتيجة عن طريق إضافة معالجة اختيارية لما بعد البناء. افتح ملف Makefile ، وفي القسم .build-post: .build-impl أضف:
.build-post: .build-impl cp ${CND_DISTDIR}/${CONF}/${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}} arm-none-eabi-objcopy -O ihex ${CND_ARTIFACT_NAME_${CONF}} ${CND_ARTIFACT_NAME_${CONF}}.hex arm-none-eabi-size ${CND_ARTIFACT_NAME_${CONF}}
(مهم - يجب أن تكون المسافة البادئة حرف علامة تبويب واحدة ، وليس مسافات)
سطرًا بسطر: 1 - نسخ ملف الكائن (.elf) من مجلد الإخراج إلى جذر المشروع ، لتسهيل الوصول إليه ؛ 2 - يولد HEX من قزم (يمكن التعليق عليه إذا لم يكن هناك حاجة إلى HEX) ؛ 3 - يعرض مقدار الذاكرة المشغولة حسب المقاطع.
النتيجة النهائية:
جيد حتى الآن.
OpenOCD - الصعوبات الأولى
في الكتيبات الإلكترونية المذكورة أعلاه ، برمجة رقاقة من خلال OpenOCD بسيطة وروتينية. يتم تثبيت أحدث إصدار (0.10.0) ، يتم أخذ ملف التكوين (من مجموعة OpenOCD أو من مجلد المشروع SW4STM32) ، يتم كتابة أمر النموذج في خصائص المشروع → تشغيل:
وكل شيء يعمل على الفور. في الواقع ، هذا هو الحال بالنسبة للعائلات الشابة مثل STM32F103 و F407 ، لكني مهتم بـ F7 و H7. مع الإصدار الأول ، يتعطل الإصدار الرسمي لـ OpenOCD 0.10.0 مع ظهور الخطأ "فشل auto_probe" و "سبب تصحيح غير محدد 7" ؛ هذا الأخير غير معتمد على الإطلاق. لقد جربنا جميع التجميعات الرسمية المتاحة 0.10.0 من يناير 2017 ويناير 2018 - النتيجة متطابقة. يؤكد البحث عن الكلمات الرئيسية وجود المشكلة ، على الرغم من أنه لا يمكنك تسميتها بشكل كبير ؛ لا يوجد تحليل وحل.
ولكن هناك إصدار مضمون للعمل - من مجموعة SW4STM32. بطبيعة الحال ، اتضح أنه تم تحسينه واستكماله ، مع نصوص جديدة ودعم لعائلة H7. أيضًا ، تم تغيير بنية الملف فيه ، ويتم تخزين الموارد في المكون الإضافي في وحدة نمطية منفصلة ، لذلك ، من أجل الأداة المساعدة المدمجة في مجلد واحد لرؤية البرامج النصية الخاصة به ، كان مفتاح التبديل -s مطلوبًا.
Board.cfg لـ NUCLEO-F767ZI ، بعد التعليقات ، والمكثف:
set CHIPNAME STM32F767ZITx source [find interface/stlink-v2-1.cfg] transport select hla_swd source [find target/stm32f7x.cfg] set WORKAREASIZE 0x10000 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 reset_config srst_only srst_nogate connect_assert_srst set CONNECT_UNDER_RESET 1
انطلق أخيرًا من خلال Run Main Project:
البرنامج الثابت ناجح ، يتم تنفيذ التعليمات البرمجية.
تصحيح الأخطاء
يُفترض أن المخطط هو الأكثر تقليدية: خادم GDB محلي على OpenOCD ، يتصل NetBeans به من خلال المضيف المحلي: 3333 عبر TCP. وفقًا لذلك ، سيتطلب NetBeans المكون الإضافي Gdbserver.
من الممكن تبسيط إطلاق OpenOCD من خلال سكربت مضرب ، وبما أنه بعد اكتمال الجلسة تذهب إلى وحدة التحكم ، فمن المنطقي تكرار إعادة التشغيل إلى ما لا نهاية:
:start openocd -f debug.cfg -sd:/Prog/openocd/scripts goto start
إطلاق:
لم يتم كتابة الإصدار من SW4STM32 بشكل صريح ، ولكن الخادم ينتظر اتصال TCP بالمنفذ 3333. في NetBeans ، حدد Debug → Attach Debugger ... ، وقم بتثبيت:
الجلسة نشطة. محطة OpenOCD:
في المظهر ، كل شيء يبدو جيدًا - جلسة التصحيح نشطة ، ويتم تنفيذ التعليمات البرمجية. ومع ذلك ، لا تزال المشكلة موجودة.
المشكلة
في وضع التشغيل الحر ، لا يمكن إيقاف التنفيذ.
إذا قمت بتعيين نقطة توقف قبل بدء الجلسة ، فعند إدخال التصحيح ، ستتوقف عند تحديث السياق ، وسيعمل التنفيذ خطوة بخطوة وعرض / تغيير المتغيرات ، أي ، من حيث المبدأ ، جميع الوظائف الأساسية اللازمة لتصحيح الأخطاء بالكامل:
ولكن فقط حتى البداية المجانية التالية ، وبعد ذلك يبقى فقط لإغلاق الدورة وإعادة تشغيلها.
يرتبط تافه آخر غير سار بنقاط توقف البرمجيات: يتم تعريف وظيفة SYSTEM_Halt () على أنها __asm__ ("bkpt") ، ويؤدي تشغيلها إلى عرض مربع حوار غير ضروري:
عند النقر فوق تجاهل وتوقف مؤقتًا ، فإنه يعمل على النحو المطلوب (أي أنه يوقف التنفيذ) ، ومع ذلك ، فمن المستحيل تعيين هذا الخيار افتراضيًا وإيقاف عرض النافذة بالوسائل القياسية.
قبل الكومة ، أود أتمتة إطلاق OpenOCD وربط المصحح مباشرة من خلال NetBeans.
ومع ذلك ، من الناحية الموضوعية ، فإن الوظيفة الوحيدة التي لا تكفي لتصحيح الأخطاء بشكل أو بآخر هي إيقاف التنفيذ (مطلوب أيضًا تعيين نقطة توقف على الطاير).
تصحيح الأخطاء
كشف بحث على جوجل أن مشاكل مماثلة مع إيقاف NetBeans توقف GDB ، ولكن تم إصلاحها قبل عدة سنوات. لعدم وجود فكرة أفضل ، تم تنزيل مصادر NetBeans على أمل المشي عبر المصحح مباشرة. والمثير للدهشة أننا تمكنا من تحديد المشكلة بسرعة قبل استدعاء الأداة الخارجية GdbKillProc.exe ، والتي هي في الأساس غلاف لـ DebugBreakProcess (pid) من WinAPI. يتم تقليل مبدأ الأداة المساعدة إلى انقطاع غير تدخلي للعملية (تناظرية "kill -SIGINT [pid]" تحت * nix ، أو Ctrl + C في وحدة التحكم).
لكنها لا تعمل.
ما تم اختباره
في وضع وحدة التحكم ، يتفاعل عميل GDB (arm-none-eabi-gdb.exe) بشكل صحيح مع Ctrl + C ، أي أنه يوقف تنفيذ التعليمات البرمجية دون إغلاق الجلسة ، وينتظر المزيد من الإرشادات.
عرض ps -W و Windows Process Explorer العملية بشكل صحيح ، ويطابق PID المتغير الداخلي في NetBeans.
استدعاء يدوي "kill -SIGINT [pid]" من حزمة MSYS يطرح خطأ "لا يوجد مثل هذه العملية".
التحقق من خلال "taskkill / pid [pid]" يؤدي إلى "تعذر إنهاء العملية ... لا يمكن إنهاء هذه العملية إلا بقوة ..." ، والذي يبدو أنه يشير إلى قفل النظام. مع مفتاح التبديل / f ، يتم إغلاق العملية تمامًا ، وهو ليس جيدًا أيضًا.
في هذه العملية ، اتضح أنه في نظام التشغيل Windows ، لا يهم الوضع مع توليد إشارات المقاطعة ، أو بالأحرى ، بأي حال من الأحوال: يتم دعم نظير SIGTERM فقط بشكل افتراضي ، وهو ما يتوافق مع قطع تقريبي للعملية ، ولا يوجد حل مقبول بشكل عام.
على الإنترنت ، تم العثور على أداة قتل windows ، مصممة لمحاكاة Ctrl + C و Ctrl + Brk. تعثر العملية على إرسال المقاطعة دون أخطاء ، ولكن لا يزال عميل GDB لا يستجيب.
تم تنفيذ التجارب باستخدام جميع إصدارات 32 بت (NetBeans و ARM Tools و MSYS 1.0) ، باستثناء windows-kill الذي رفض بدء 32 بت ("... غير قادر على البدء بشكل صحيح ..."). ربما تكون المشكلة هي هذه على وجه التحديد ، لأنه ، وفقًا للبيانات المجزأة من المنتديات و bugtrackers ، يجب أن يتطابق عمق البت للأداة والعملية. تكمن الصعوبة هنا في أن ARM لا يقدم إصدار x64 من سلسلة الأدوات لنظام التشغيل Windows ، بما في ذلك الطريقة الوحيدة للقضاء على عدم التجانس هو جعل إصدار x32 من windows-kill يعمل ، وهو أمر غير واضح أيضًا ما إذا كان من الممكن ضمن Win x64 من حيث المبدأ.
في منتصف العملية ، تم إعادة تثبيت نظام التشغيل من الصفر ، ولم يلاحظ أي تغييرات في سلوك الأشخاص التجريبيين ، بما في ذلك بثقة كبيرة يمكن إلغاء ميزات نظام معين.
مطلوب مساعدة قاعة
في الواقع ، يمكن اعتبار كل ما سبق مقدمة لهذه الفقرة.
الخطوة الأخيرة المتبقية هي جعل تصحيح STM32 تحت NetBeans حقيقيًا:
يتطلب آلية برنامج عمل لإرسال إشارة مقاطعة SIGINT (Ctrl + C) إلى عملية عميل Windows GDBفيما يلي توصية لإعداد الحد الأدنى من التكوين الكافي للتحقق / تصحيح المشكلة أعلاه. إذا / عندما يمكن حلها ، سيتم إعادة تصميم المقالة في دليل بسيط خطوة بخطوة حول كيفية تكوين NetBeans + OpenOCD للعديد من العائلات ولوحات تصحيح الأخطاء المختلفة. يمكن إكمال المزيد من الوظائف حسب الرغبة ، مع وجود حل أساسي عملي بالفعل.
إعداد الاختبار
يقترح استخدام لوحة Blue Pill على أساس STM32F103C8T6 و استنساخ ST-Link V2 كمنصة أجهزة.
من الضروري:
1. قم بتثبيت برنامج
GNU Arm Embedded Toolchain2. تثبيت OpenOCD 0.10.0 (
بناء تحت وين )
3. قم بتسجيل مجلدات العلبتين في الحزم في PATH (لوحة التحكم ← النظام ← إعدادات النظام المتقدمة ← متغيرات البيئة ... ← المسار).
4. في مكان مناسب لإنشاء ملف board.cfg ، انسخ المحتويات:
source [find interface/stlink-v2.cfg] source [find target/stm32f1x.cfg] transport select "hla_swd" reset_config none separate set WORKAREASIZE 0x5000 set CHIPNAME STM32F103C8T6 set ENABLE_LOW_POWER 1 set STOP_WATCHDOG 1 set CLOCK_FREQ 4000 set CONNECT_UNDER_RESET 1
5. اختر البرنامج الثابت المناسب للاختبار (test.elf) ، والمعيار الرئيسي هو أن التنفيذ والتوقف يمكن تمييزهما بوضوح. نسخ إلى مكان مناسب.
6. من مكان مناسب وميض اللوح:
openocd -f board.cfg -c "program test.elf verify reset exit"يجب أن تبدأ البرامج الثابتة. نموذج إخراج OpenOCD إلى وحدة التحكم:
7. من مكان مناسب لبدء خادم OpenOCD GDB:
openocd -f board.cfgالرمز لا يزال قيد التنفيذ ؛ نموذج الإخراج (تظل وحدة التحكم مقفلة بواسطة OpenOCD):
8. في وحدة تحكم أخرى أو قم بتشغيل arm-none-eabi-gdb.exe مباشرة من حزمة GNU ARM Embedded Toolchain وتنفيذ الأوامر:
target extended-remote localhost:3333 (لا يزال الرمز قيد التنفيذ)
continue (الكود قيد التشغيل ، وحدة التحكم مقفلة)
Ctrl+C (توقف الرمز ، وحدة التحكم نشطة)
continue (تشغيل مرة أخرى ، تم تأمين وحدة التحكم)
تتمثل المهمة في إزالة عميل GDB من حالة التنفيذ (أي محاكاة Ctrl + C) بشكل برمجي.
لمعرفة معرف العملية ، استخدم "ps -W" من البيئة * nix أو Windows Process Explorer (مثبت اختياريًا).
ربما سيقوم شخص ما بالتصحيح بشكل صحيح بعد الإعداد الأولي لـ NetBeans - ستكون هذه المعلومات مفيدة أيضًا ، خاصة مع وصف مفصل للنظام والميزات المحتملة.
يرجى مشاركة الأفكار في التعليقات ، وآمل أنه من خلال العمل معًا يمكننا تحويل تجربة جريئة إلى دليل مفيد لإعداد أداة أكثر فائدة.