בנוגע למיקרו-בקר:

לאחרונה הבחנתי שהבקר מתנהג בצורה שונה עבור אותו הקוד בדיוק.
כלומר פעם אחת הקוד יכול לרוץ טוב, פעם אחרת לא טוב.
לא נראה לי שהבעיה בסביבת פיתוח הקוד בגלל שלפני כן זה עבד טוב.
כמו כן זה לא בעיית errata.

משהו שאני שם לב אליו במיוחד זה שפסיקה אמורה להתרחש, היא מתרחשת (כפי ששמתי לב באמצעות ה-ICE שבמעבד), אבל המעבד לא מבצע את השיגרה שמטפלת בפסיקה. הוא פשוט ממשיך בשאר הקוד... שמתי breakpoint ב-handler של הפסיקה כדי לוודא שאכן המעבד לא נכנס; ולצערי צדקתי.

יכול להיות שההתנהגות המוזרה הזאת נובעת מצריבות מרובות בגלל הגבול של כמות הצריבות האפשריות?

בנוגע לנפילת מתח:

יש איזה מעגל עם 2 טרנז' FET שמבצעים החלפה בין ספקי כוח, כאשר האחד הוא קבוע וזה בטרייה, והשני שנאי שאינו קבוע.

כאשר השנאי יחובר, הוא ינתק את הבטרייה.
אבל מה יקרה כאשר אנתק את השנאי? הכוח למעגל יופסק באופן מידי, ולטרנזיסטורים ייקח X nSec כדי להחליף למצב שבו הבטרייה מספקת את הכוח למעגל. מה יש לעשות כדי לספק כוח למעגל למשך כמות הזמן הזו? אני מניח שזה עם קבל, אבל אני לא בטוח מה לעשות.

תודה רבה!
דור.

במיקרובקרים זולים יחסית, כמות הצריבות החוזרות האפשרית היא בסביבות 1000 מחיקות וצריבות מחדש. ברכיבים יקרים יותר זה מגיע אפילו עד 100000 צריבות חוזרות..
ובוא לא נשכח שזהו מספר שעליו היצרן מוכן להתחייב, כלומר בפועל המספר גדול יותר..
מכאן, אם יש בעיה בחומרה, קרוב לודאי שהיא לא נובעת מכמות הצריבות.. כדי להגיע ל-1000 מחיקות וצריבות צריך לעבוד עם הרכיב ברציפות במשך למעלה משנה (בהנחה שכל יום מבצעים 2-3 צריבות..)
המסקנה שנובעת מההקדמה לעיל היא שזה לא הגיוני שה-MCU שלך התחיל לזייף בגלל כמות המחיקות והצריבות מחדש..
אם שאר הקוד פועל כהלכה ורק ה-ISR עושה בעיות, אני דווקא הייתי מהמר על מימוש שגוי של ה-ISR או טיפול שגוי בפסיקה כמו למשל הגדרה לא נכונה של סיביות אפשור הפסיקות..
אפשרות נוספת, פחות נפוצה אך תתכן היא שמשהו בקוד שלך מחרבש את הערך שנמצא ברגיסטר אפשור הפסיקות ולכן לאחר ההרצה, הפסיקות למעשה אינן מאופשרות...
מומלץ גם שתציין את סוג המיקרובקר איתו אתה עובד.. לפעמים זה יכול לתת רעיונות למי שמכיר את הרכיב ועבד איתו בעבר...

בברכה,
DigiGil

_- סיוע בהשלמת פרויקט-גמר להנדסאים -_

(האתר digigil.com נסגר)

במחשבה שנייה זה באמת נראה יותר כמו באג בתוכנה.
אבל עדיין אני לא מבין למה ב-2 צריבות רצופות התוצאות שונות.

עד כמה ששמתי לב רק הפסיקה הזו, וגם כן פסיקה אחרת, בעייתיות. כלומר - מנגנון הפסיקות פשוט משתבש \ לא פועל.

לפעמים מופעלת פסיקה בצורה לא קשורה (מבלי סיבה נראית לעין; מבלי שאפשרתי\הגדרתי פסיקה כזו) ונכנסת ל-default handler שהוגדר בקובץ startup.

ציטוט:

אפשרות נוספת, פחות נפוצה אך תתכן היא שמשהו בקוד שלך מחרבש את הערך שנמצא ברגיסטר אפשור הפסיקות ולכן לאחר ההרצה, הפסיקות למעשה אינן מאופשרות...

קראתי את מידע האוגרים דרך JTAG ולא מצאתי איזשהיא בעיה... הכל היה נראה טוב. למעשה האוגר שמחזיק את הפסיקה הפעילה הנוכחית הראה סימן שהפסיקה מתבצעת כרגע. (למרות שבמציאות לא נכנסתי לפסיקה)

לוגיקת הקוד נכונה עד כמה שבדקתי הרבה מאוד פעמים... ניסיתי גם לבדוק קוד backup ששמרתי (ושאני יודע שעובד טוב). אבל בבדיקה הראשונה (ובהתאם בצריבה הראשונה) הקוד לא עבד בכלל - הפסיקה לא הופעלה. אך בצריבה השנייה הקוד עבד טוב. לא שיניתי אותו כלל בין הצריבות.

אני ממש מקווה שזה באג בתוכנה ושבקרוב אחזור אליכם ואומר "איך לא שמתי לב לזה...". אבל אחרי כל הבדיקות שעשיתי ואחרי מה שכתבתי למעלה זה נראה לי כמו אפשרות פחות סבירה...

1. צריבות מרובות עלולות לפגוע בתוכן ה FLASH ששומר את התוכנה. אי כניסה לרוטינת פסיקה לא קשורה לכך.
2. גם בעיות חומרה וגם באגים בתוכנה (בעיקר כאלו שקשורים לטיימינג) עלולים לגרום לכך שפעם התוכנה תרוץ ופעם לא. מה מקור הפסיקה שלא מתבצעת? האם יש קטעים שבהם אתה חוסם פסיקות? האם אתה מאפשר פסיקות נוספות רק ביציאה מה HANDLER? האם אתה קורא לפונקציות מתוך ה HANDLER?
3. אני מניח שיש לך במעגל קבל כלשהו על המתח. בגלל קבל זה, המתח למעגל לא יפול מיידית ולא תופיע הבעיה. אם אין קבל, או שהקבל קטן מדי - תוסיף קבל 100U (יחזיק את המתח ל 10 מיקרושניות בזרם 1A וירידת מתח של 0.1V).

Elim

1. זה גם מה שאני חשבתי. שאז במקרה הזה כל התוכנה לא תראה סימן חיים סביר להניח...

2. זה גם מה שאני חושב, שוב, אבל העניין הוא שבכל צריבה הזמן שווה - הקוד רץ מההתחלה ולכן העניין של הזמנים אמור להיות שווה. כך שלא אמור להיות הבדל בהתנהגות \ התוצאה הסופית.

מקור הפסיקה שלא מתבצעת (אך אמורה להתבצע) זה זמנן (timer).

אני חוסם פסיקה אך ורק בתוך הפסיקה (כלומר עושה disable לפסיקות עתידיות, עד מתי שאאפשר אותן שוב).

פסיקות נוספות יכולות להתרחש רק ביציאה מה-handler, כי כך המנגנון בנוי - עד שלא חוזרים מרוטינת פסיקה, אותה הפסיקה לא יכולה לגרום לכניסה לרוטינה המוגדרת באוגר ששומרת את כתובת השיגרה.
יש אפשרות של פסיקות ברמות גבוהות יותר שיכולות לגרום לפסיקה כאשר נמצאים בפסיקה ברמה נמוכה יותר, אבל זה לא המצב כאן.

אני אכן קורא לפונקציות מתוך ה-handler ע"י משתנה callback (מצביע לפונקציה). אך בעבר זה לא הראה בעיות...

3. אכן יש. החישוב שעשית בוצע כפי שכתבת באשכול כאן ?

1. האם הטיימר נותן פסיקות באופן מחזורי, או שאתה דורך אותו בכל פסיקה כדי לתת את הפסיקה הבאה?
ואגב - באיזה בקר מדובר?
2. אכן כן - כך מבוצע החישוב.

Elim

1. אני דורך את הטיימר בכל פסיקה כדי לתת את הפסיקה הבאה.

נכון סליחה שכחתי לתת לכם את הבקר: http://www.atmel.com/dyn/products/p...sp?part_id=4104

אני משתמש בקיט פיתוח לעת עתה.

היום בדקתי את התוכנה מכל כיוון וזה לא נראה שיש בה בעיה.

ושימו לב מה קרה, הנה הצעדים מהראשון לאחרון:

1. עשיתי build לפרויקט באופן חד פעמי.
2. צרבתי פעם ראשונה לבקר. הרצתי - אך האפליקציה לא עבדה טוב (הפסיקות לא פעלו).
3. צרבתי פעם שנייה לבקר. הרצתי - לא עבד.
4. צרבתי פעם שלישית לבקר. הרצתי - לא עבד.
5. צרבתי פעם רביעית לבקר. הרצתי - כן עבד.
6. צרבתי פעם חמישית לבקר. הרצתי - כן עבד.

מלבד הצעד הראשון לא עשיתי שוב build לפרויקט!

ייתכן שהבקר מקרטע?

1. האם לאחר צריבה שעובדת - הוא ממשיך לעבוד תמיד בכל כיבוי והדלקת מתח ?
2. האם קיימת אופצית VERIFY בזמן הצריבה ואם כן, האם אתה מפעיל אותה?

אם התשובה ל 1 היא כן, ול 2 לא, אז יתכן שיש לך בעית תקשורת בצריבה.

Elim

1. בפעם האחרונה שבדקתי - לאחר צריבה שעובדת, ולאחר לחיצה על כפתור RESET, האפליקציה עובדת טוב (כמו שצריך).
2. אני לא בטוח, אבדוק ואחזור עם תשובה.

ד"א - לאחר שהצריבה עובדת, אז האפליקציה מתנהגת כרגיל למשך זמן מה, ואח"כ אני מזהה שהמעבד (ARM7) נכנס למצב Abort, מסיבה לא ברורה...

אם יש בעיה בתקשורת הצריבה, אז למה דווקא פסיקות לא מתרחשות? (כאשר הצריבה לא טובה)
גם פסיקת UART שקבעתי לה רמת פסיקה גבוהה יותר אינה מופעלת.

יתכן שמתקיים מצב טיימינג גבולי (יחד עם באג בתוכנה) שגורם לכך שהפסיקות ישארו חסומות.
מצב DEADLOCK כזה יכול למשל להתרחש אם לפני היציאה מהפסיקה אתה מקבל פסיקה נוספת מאותו סוג (יתכן שבזמן שאתה נמצא בפונקציה שאתה קורא לה מתוך הפסיקה). הסיבה לכך היא שבניגוד לקריאה לפונקציות, שבהן מצב החזרה (כולל IE) נשמר ב STACK, בפסיקה המצב נשמר בכתובות חומרה קבועות (סט כתובות אחד לכל פסיקה).

אתה יכול לנסות ביצוע של הפסיקות ללא קריאה לפונקציות - במקום זה, תדליק ביט סמפור בפסיקה, וב IDLE TASK (או בלולאה ראשית) תבדוק את מצב הביט ואם הוא מופעל - נקה אותו וקרא לפונקציה.

עריכה - לפני ביצוע השינוי - אתה יכול לבדוק אם זו הבעיה ע"י כך שבלולאה הראשית תבדוק את מצב איפשור הפסיקות ואת ה MASK ואם הפסיקות חסומות - תפעיל I/O או לד.

כמו כן, כניסה ל DEADLOCK תקרה אם תפנה שתי פסיקות שונות לאותו HANDLER.

Elim

הפסיקה היא של הזמנן שנקרא PIT (ר"ת Periodic Interval Timer).
כתבתי את התוכנה בצורה כזו שהפסיקות של PIT לא יכולות להתערבב אחת עם השניה, כלומר שיהיה אפשר להתעסק עם ה-PIT רק בשביל מטרה אחת בזמן אחד. והפסיקה של ה-UART אינה מתרחשת (אלא אם אני כותב מידע לרגל RX של UART, ולא עשיתי זאת)

ה-AIC (מנגון טיפול בפסיקות) כולל stack חומרתי בגודל 8words (מילה אחת = 4 בתים), אז גם אם באה פסיקה ברמה גבוהה יותר אני מניח שזה לא אמור לגרום לבעיה... יש אוגר שנקרא AIC_IVR והוא מכיל את הכתובת של הפסיקה הנוכחית המבוצעת.
כיוון שה-AIC תומך בפסיקות מקוננות אז אני חושב שזה לא אמור להיות הבעיה... כמו כן האפליקציה והקוד לא בנויים בצורה כזו שיהיו 2 פסיקות מקוננות, אלא אם נכתב מידע לרגל RX של UART, אבל זה לא קרה..

לגבי ה-stack החומרתי:

ציטוט:

When an interrupt of a higher priority happens during an already occurring interrupt service rou- tine, the nIRQ line is re-asserted. If the interrupt is enabled at the core level, the current execution is interrupted and the new interrupt service routine should read the AIC_IVR. At this time, the current interrupt number and its priority level are pushed into an embedded hardware stack, so that they are saved and restored when the higher priority interrupt servicing is finished and the AIC_EOICR is written. The AIC is equipped with an 8-level wide hardware stack in order to support up to eight interrupt nestings pursuant to having eight priority levels.

המנגון של ה-AIC פועל בצורה כזו שפסיקה ברמה מסוימת לא יכולה להפסיק פסיקה עם אותה הרמה, אלא ממתינה עד שתסיים (וכך גם המעבד עושה):

ציטוט:

The nIRQ line can be asserted only if an interrupt condition occurs on an interrupt source with a higher priority. If an interrupt condition happens (or is pending) during the interrupt treatment in progress, it is delayed until the software indicates to the AIC the end of the current service by writing the AIC_EOICR (End of Interrupt Command Register). The write of AIC_EOICR is the exit point of the interrupt handling.

עשיתי pause דרך JTAG לריצת הקוד כאשר הצריבה הייתה לא טובה, וראיתי את אוגרי ה-AIC תקינים. כמו כן אוגרי ה-PIT היו תקינים. בע"ה בקרוב אביא תמונה של האוגרים והערכים שלהם.

ציטוט:

אתה יכול לנסות ביצוע של הפסיקות ללא קריאה לפונקציות - במקום זה, תדליק ביט סמפור בפסיקה, וב IDLE TASK (או בלולאה ראשית) תבדוק את מצב הביט ואם הוא מופעל - נקה אותו וקרא לפונקציה.

למה לעשות set interrupt ומיד אח"כ (אחרי בדיקה) לנקות בלולאה הראשית? אם אעשה set אז הפסיקה תופעל והקוד יקפוץ לכתובת ה-handler... לא..?

ציטוט:

עריכה - לפני ביצוע השינוי - אתה יכול לבדוק אם זו הבעיה ע"י כך שבלולאה הראשית תבדוק את מצב איפשור הפסיקות ואת ה MASK ואם הפסיקות חסומות - תפעיל I/O או לד.

בדקתי עם JTAG אך האוגרים מראים שהפסיקות מאופשרות, ואפילו פסיקת ה-PIT (שזה למעשה פסיקת SYS כלומר system) במצב pending, אבל המעבד לא נכנס ל-handler. אאל"ט באוגר AIC_IVR (האוגר שמציין את כתובת handler הפסיקה שמתבצעת כרגע) הייתה הכתובת של הפסיקה, אבל המעבד לא נכנס ל-handler שהקצתי באוגר המתאים (שמתי breakpoint ב-handler וגם שמתי לב שהאפליקציה לא מתעדכנת). בדקתי גם את כתובות ה-ISR שהקצתי לכל מקור פסיקה - וזה תקין, הכתובות נכונות (נבדק לאחר ביצוע disassembly).

אני חושב שאני לא נכנס למצב deadlock כיוון שאין לי 2 פסיקות באותו הזמן, וכמו כן לא הפנתי 2 פסיקות שונות לאותו ה-handler.

ד"א, לפני כן כאשר כתבתי שהמעבד נכנס למצב abort, הכוונה היא ל- Prefetch Abort (ולא ל-Data Abort).

האם תיחלת את כל הפסיקות?
יתכן שאתה חוטף פסיקה שאינה מתוחלת (ועקב כך לא מתנקה) - ולכן מאותו רגע כל הפסיקות באותה רמה ומתחת נשארות PENDING.
גם אם חסמת את כל הפסיקות שלא מתוחלות ב MASK, יש פסיקות שלא ניתנות לחסימה (לא ממש בקי בבקר הזה, אך בד"כ פניה לכתובת לא חוקית לדוגמה תייצר פסיקת ERR שבמעבדים מסויימים לא ניתנת לחסימה).
רצוי בפסיקות שאינן בשימוש לשים NUL HANDLER (שלא מבצע כלום, רק מנקה את הפסיקה ויוצא).

Elim

כן הן מאותחלות (הכוונה לביצוע clear לפסיקה, נכון?).

פסיקת ה-abort, עד כמה שאני יודע, היא היחידה שלא ניתנת לחסימה.

שמתי לכל הפסיקות default handler בקובץ startup.
אך גם אם איזשהיא פסיקה מוזרה הייתה מתרחשת - ונניח שהייתה נכנסת ל-handler עם לולאה אינסופית, אז הייתי אמור לראות זאת ע"י הפסקת הריצה דרך JTAG. (ד"א אני נמצא במצב מוגן מפני הבעיות ש-JTAG יכול ליצור בעקבות קריאת האוגרים).

אך במקום זאת, אני נמצא בלולאה שמחכה שדגל מסוים יתאפס. הדגל הזה אמור להתאפס בתוך הפסיקה (שאינה מתבצעת).

כלומר יש לי משהו כזה:

קוד:

HANDLER PIT_ISR()
{
  clear interrupt();
  if (required_interval_time--)
    // restart counter to trigger an interrupt again,
    // until required_interval_time equals 0 (zero)
  else
   // disable PIT interrupts and mark the timer_ended flag as true
}

ואז התוכנית שמחכה לדגל timer_ended למעשה ממשיכה בלי סוף:

קוד:

while (!timer_ended);

זה לא הקוד במדויק אבל זה הרעיון. אז התוכנית נתקעת על לולאת ה-while כי הדגל לא מסומן כ-true בגלל שלא הייתה אפילו כניסה אחת ל-handler של הפסיקה (אימתתי זאת בעזרת breakpoint בתחילת ה-handler).
אך אפילו אם אני מנסה לעורר פסיקת UART - שהיא עם העדיפות הגבוהה ביותר, אפילו זה לא קורה כאשר הצריבה לא טובה. כלומר שאני מניח שבין צריבה לצריבה משהו ב-AIC לא בסדר... כנראה...

בקרוב בע"ה אחזור עם תשובה לגבי אופציית ה-verify של הצריבה ואז אני מקווה שנידע טוב יותר. תודה!

בדקתי, וכאשר אני מבצע launch לקוד, אז אני רואה שכתוב:

קוד:

verifying address (0x0yyyyyy - 0x0zzzzzz ) 2KB

משהו כזה כתוב. המילה הראשונה, "verifying", אני בטוח שהיא קיימת. השאר אני חושב פחות רלונטי... (אך אוכל להביא תצלום מסך אם יש צורך)

היום לקחתי את קוד הגיבוי (שאני יודע שהוא עובד טוב), צרבתי אותו והפעלתי - וזה פעל טוב כל הזמן.
וכאשר לקחתי את הקוד שאינו גיבוי (כלומר הקוד שאני פשוט עובד עליו, וידוע לי שאינו טוב) - אז האפליקציה לא פועלת טוב. הפסיקות לא פעלו בכלל. וזה היה בכל הצריבות עם הקוד הזה.

עוד דבר מוזר זה שלפעמים כשאני צורב, אני נמצא במצב של פסיקה תמידית - מיד אחרי יציאה מה- handler, המעבד קופץ שוב ל-handler מחדש. אם אני צורב שוב אז זה עובר (כלומר בצריבה הבאה זה לא יופיע).

ניסיתי לבודד את הקוד הבעייתי, אז לקחתי את קוד הגיבוי (שעובד טוב), והוספתי חלקים מהקוד העדכני (שאינו עובד טוב), והגעתי למחלקה בשם- "timer" שמשתמשת בזמנן PIT כולל פסיקות (כאשר צריך).
עם הקוד הזה היו לי 2 מצבים\מקרים:

1. כאשר צרבתי והאפליקציה פעלה טוב.
2. כאשר צרבתי ולא פעלה טוב (אין פסיקות).


דבר נוסף - כאשר אני עושה RESET או מנתק את אספקת הכוח ומחזיר - האפליקציה לא פועלת (אין פסיקות... השאר פעל טוב) אפילו בצריבה טובה. למרות שעד כמה שאני יודע, המידע נצרב ל-flash, ולא ל-ram.

אני כבר לא יודע מה לחשוב...

אני פועל עם 2 עורכי טקסט, כלומר האחד זה ++Notepad שאיתו אני עורך את הקבצים (כי הוא יותר נוח), והשני זה ה-IDE שכולל את ה-compiler, debugger וכו'.
למרות זאת אני בטוח שלא היה בילבול בין 2 התוכנות וגם וידאתי בכל פעם מחדש.

תודה!
דור.

עריכה:
ליתר ביטחון אציין שכאשר אני כותב שהאפליקציה לא פועלת - הכוונה היא מבחינת (כל) הפסיקות בלבד, אלא אם אציין אחרת. שאר האפליקציה כן פועלת, לדוגמא כתיבת מידע ל-LCD.

כמעט בודאות מלאה - יש לך בעיה בקוד בלבד. אין בעיה בצריבה.
יתכן שיש לך מירוץ בין התיחולים לפסיקות - האם אתה מאפשר פסיקות מכל סוג רק אחרי שגמרת את כל התיחולים, כולל הצבה של כל וקטורי הפסיקות?

Elim

אני מאפשר פסיקות אך ורק אחרי שסיימתי את כל האיתחולים. עלה לי הרעיון שאולי נשמר המצב הקודם של הפסיקות מההפעלה הקודמת, אבל זה לא יכול להיות בגלל שבכל הפעלה מחדש אמור להיות reset למעבד ולערכי האוגרים.

לדוגמא הינה התהליך של איפשור פסיקה:
מגדיר את סוג הפסיקה (level / edge), רמת חשיבותה, וכתובת ה-handler באוגרים של AIC. ואז כאשר אני צריך לבצע delay ללא\עם פסיקה, אז אני מגדיר את אוגרי PIT - את הזמן, מאפשר אצלו פסיקה (אם צריך), מריץ את ה- counter ופועל כרגיל.

כמו כן שמתי להתנהגות הזו:

בצריבה לא טובה, כאשר אני עושה Suspend לריצה (יענו pause), אני שם לב שבאוגר PIT_SR (ר"ת Status Register של PIT) הביט PITS שווה '1'. ואז כאשר אני קורא שוב את האוגר PIT_SR דרך JTAG, הביט הזה מתאפס! ההתנהגות הזו לא כתובה בדוקומנטציה.
הביט PITS, וכמו כן השדה PICNT באוגרים PIT_PIVR ו- PIT_PIIR, אמורים להתאפס אוטומטית אך ורק כאשר אני קורא את האוגר PIT_PIVR.

ציטוט מה-DS:

ציטוט:

When CPIV and PICNT values are obtained by reading the Periodic Interval Value Register (PIT_PIVR), the overflow counter (PICNT) is reset and the PITS is cleared, thus acknowledging the interrupt. The value of PICNT gives the number of periodic intervals elapsed since the last read of PIT_PIVR.

כאשר הביט PITS עולה ל-1, אמורה לפעול פסיקה (אך ב-"צריבה לא טובה" היא אינה פועלת למרות שהביט עולה ל-1).

עכשיו נזכרתי בדבר נוסף:

יש RTT (זמנן זמן-אמת \ Real Time Timer) שאני בכלל לא מגדיר אותו בתור פעיל, בשום מקום בקוד.
אבל ב-handler שאמור לבצע הבדלה אם הפסיקה היא של PIT או RTT, שמתי לב ע"י בדיקת RTT שהוא פעיל - ובהתאם לכך אצטרך להיכנס לפסיקה.
המערכת בנויה כך ש-PIT ו-RTT נכנסים לאותו ה-handler ולכן חובה להבדיל ביניהם באמצעות ערכי האוגרים המתאימים.

אם PITS עולה, ואתה לא נכנס לפסיקה, זה יכול להיות בגלל:
1. אתה עדיין ב HANDLER של פסיקה גבוהה יותר.
2. כל הפסיקות חסומות גלובלית.
3. הביט המתאים ב MASK לא פתוח.

שתי פסיקות שמופנות לאותו HANDLER עלולות לגרום לבעיה כזו - תלוי ברמות ובמבנה מנגנון הפסיקות.
אפשרויות לבדיקה:
אם אתה לא משתמש ב RTT, דאג לחסום אותו ב MASK (ולשים אותו בכלל ב DISABLE אם זה אפשרי), וכן לודא שאף פונקציה או HANDLER לא פותחות לו את ה MASK.
לחילופין, כתוב NULL HANDLER נפרד ל RTT שרק ינקה אותו ויצא.

Elim

1. לפי מה שבדקתי בעזרת JTAG - אני נמצא בלולאת ה-while שנמשכת לנצח, ולא בתוך handler מסוים.

2. לא חסמתי את הפסיקות גלובאלית, בכל הקודים הכתובים (כולל הגיבויים שעובדים טוב).

3. בדקתי בעזרת JTAG וה-MASK של RTT סגור, לעומת PIT ו-UART שהם פתוחים. על פסיקת SYSC (יענו system שזה שייך ל-PIT, RTT ועוד כמה פונקציות) כתוב שהיא pending. אך המעבד לא נכנס לפסיקה הזו בצריבה לא טובה.

ציטוט:

אם אתה לא משתמש ב RTT, דאג לחסום אותו ב MASK (ולשים אותו בכלל ב DISABLE אם זה אפשרי)

אני לא יכול לחסום את RTT ב-MASK כי אז אני אחסום את PIT. הבקר בנוי באופן כזה שפסיקות שנגרמות על ידי פונקציות מערכת, כמו PIT או RTT, ייפנו לאותו ה-HANDLER, ובתוך ה-HANDLER הזה צריך לזהות מי גרם לפסיקת ה-SYSC בעזרת אוגרי הפונקציות. כיוון שבקוד לא נגעתי באוגרי RTT, פסיקת RTT לא אמורה לפעול וכמו כן ה-counter של RTT.

אבל אנסה לעשות את הדבר הבא:
כאשר תזוהה פסיקה מ-RTT, אפנה לפונקציית איפוס ה-RTT כמו שכתבת. אני לא בטוח שזה יעזור אבל חשוב שאנסה. כמו כן אבדוק מה המצב של אוגרי RTT.

ד"א, יש לי 2 קבצי startup - ב-ASM וב-C, אבל השתמשתי באותם קבצי ה-startup כל הזמן ולכן אני חושב שהם לא הגורם לבעיה...
בנוסף, שווה שאבדוק אם זו הבעיה - לאחר קימפול, בין היתר כתוב warning בנוגע להגדרה מסוימת שנכתבה בקובץ scatter.sct. אני זוכר שכתוב משהו כמו:

קוד:

*.(ramfunc)

ועד כמה שהבנתי מתעסקים שם במרחב הזיכרון. אביא תצלום מסך. לדעתך ייתכן שיש קשר?

אני לא ממש מכיר את מנגנון הפסיקות של ה ARM לעומק, אך שוב - כדי לבדוק שזה לא מצב שבו הפסיקות נחסמות ונשארות חסומות - אתה יכול להכניס בלולאת ה WHILE פתיחה של הפסיקות וה MASK - כך שזה יתבצע כל הזמן ברקע (אין בעיה ולפעמים אפילו רצוי להכניס איפשור פסיקות כזה ללולאה הראשית - כדי למנוע מצבי DEADLOCK).

Elim

אני זוכר שאוגר ה-IMR (אוגר מיסוך הפסיקות) איפשר את הפסיקות של PIT ו-UART, אך בכל מקרה אנסה זאת!

תודה לך!

דור.

בנוגע לפתיחת פסיקות בלולאה הראשית:

שכחתי מזה שהאיטרציה השנייה של הלולאה הראשית כלל לא מתרחשת, בגלל שבאיטרציה הראשונה התוכנה מחכה לדגל מסוים שיהיה TRUE אחרי שהפסיקה תתרחש מספר פעמים. לכן זה לא יעזור.

אבל מה שכן עשיתי, בשלב ה-init (כלומר לפני הגדרת פסיקות או התעסקות איתן בכלל), זה disable לכל הפסיקות ואח"כ ניקיתי את כל הפסיקות.

אך זה לא עזר.

אבל שמתי לב שלא משנה איזה חלק של קוד מבוצע, אפילו הקוד ההתחלתי שבכתובת 0, האוגר AIC_IPR מכיל ערך 0x2 - שזה אומר שהפסיקה SYSC (שקשורה ל-PIT ופונקציות נוספות) במצב pending כל הזמן.

לכן, אני מניח, שאף פסיקה אחרת לא יכולה להתרחש - בגלל שהמעבד מחכה להתחיל את פסיקת ה-SYSC !
למרות שזה לא מסביר למה הוא לא נכנס אליה, או למה הוא לא נכנס לפסיקה גבוהה יותר כמו של ה-UART.

אמרתי מקודם שאביא צילומי מסך, אז הינה הם:

Verify

תוכן הקובץ scatter.sct

השגיאה בונגע ל- scatter.sct לאחר קומפילציה

האוגרים של AIC (מגנון טיפול הפסיקות) - חלק א'

האוגרים של AIC (מגנון טיפול הפסיקות) - חלק ב'

שגיאת כתיבה לזיכרון שהופיעה באופן חד-פעמי בעבר וחשבתי שאולי כדאי להראות

אני יכול להביא גם צילומי מסך של הקוד אם צריך אבל כיוון שאתה לא מכיר את המיקרו-בקר הזה אז אני לא בטוח אם זה יעזור (כנ"ל לגבי תצלומי מסך של האוגרים)... אבל אם תרצה אוכל להביא בלי בעיה !

ד"א הקוד שלי ממש פשוט, והוא משתמש מקס' ב-2 פסיקות, לכן הסיכוי שתהיה איזשהיא בעיה "רגילה" נראה לי פחות סביר למרות שגם יכול להיות שנעלם מעיניי משהו חשוב.

תודה רבה!

וערב טוב,
דור.

את אותו מנגנון שמאפשר פסיקות ופותח MASK אתה יכול להכניס למקום שבו מחכים לדגל (לולאה שבה אתה עושה את הפעולות ומחכה לדגל בלופ - עד שהדגל ב TRUE).

Elim

להפתעתי, היום כל הצריבות (בערך 7) היו טובות - כלומר הפסיקות עבדו בכל פעם שביצעתי צריבה והרצתי את הקוד. מדובר על הקוד שנחשב פגום, לאחר שעשיתי build לכל קבצי ה-cpp.
לכן לא הייתה לי אפשרות לנסות מה שביקשת שאנסה...

בינתיים עדיף שלא אשגע אותך עם הנושא הזה ונראה מתי אצליח להצביע על הבעיה באופן ממוקד יותר.

תודה על עזרתך עד כה!

דור.

אני חושב שהבעיה נמצאה ובעקבותיה הפתרון:

בקוד כתבתי איזה 2 שורות שמשנות את מקור השעון הראשי.
לפני הקוד - השעון התקבל ממוצא PLL.
אחרי הקוד - השעון אמור להתקבל מהגביש.

לפי ה-DS, נדרש לבצע את שינוי מקור השעון בצורה הדרגתית.
בקוד שכתבתי, חשבתי שאני פועל לפי ה-DS, אבל היום בחנתי את זה שוב וראיתי שהקוד לא תקין - מה שגרם לשינוי לא-הדרגתי של הערכים באחד האוגרים.
הייתי צריך לבצע פעולות bitwise מסוימות כדי שהקוד יותאם לכתוב ב-DS.

עכשיו עשיתי זאת והקוד פועל כמו שצריך!

תודה Elim שהשקעת הרבה בניסיון לעזור!