প্রোগ্রামারে EEPROM পড়া ও লেখার ত্রুটি
মডিউলের সমস্যা নির্ণয় বা কোডিং করার আগে তাকে পড়তে হয়, আর তারপর প্রায়ই লিখতেও হয়। দুটি ধাপই নিজস্ব ধরনে ব্যর্থ হয়। এই পেজে প্রতিটি ব্যর্থতাকে তার কারণের সঙ্গে এবং যে সেটিং বা পদ্ধতিতে তা ঠিক হয় তার সঙ্গে মেলানো হয়েছে: মডিউল একেবারেই চোখে না পড়া থেকে শুরু করে এমন লেখা পর্যন্ত, যা “সফল” হয়েও নিঃশব্দে হারিয়ে যায়।
মডিউল শনাক্ত হচ্ছে না
| যাচাই | কেন |
|---|---|
| বসানো ও ক্র্যাডল | মডিউলকে কানেক্টরের একেবারে শেষ পর্যন্ত ঢুকতে হবে; তার ফর্ম ফ্যাক্টরের অ্যাডাপ্টার ব্যবহার করুন: QSFP ক্র্যাডলে SFP বসালে সেটি দেখা যাবে না |
| পাওয়ার-আপের সময় | ঢোকানোর পর দুই-তারের বাস সাড়া দেওয়ার আগে মডিউলের সর্বোচ্চ ~2 s (SFP) বা আরও বেশি (CMIS) সময় লাগে |
| মডিউল-উপস্থিতির সিগন্যাল | MOD_ABS / ModPrsL অ্যাসার্ট হতে হবে; বাঁকা পিন বা এই সিগন্যালহীন মডিউল অনুপস্থিত বলে মনে হয় |
| লো-পাওয়ার অবস্থা (CMIS) | LowPwr-এ শনাক্তকরণ তথ্য পড়া যায়, কিন্তু পূর্ণ অ্যাক্সেসের জন্য কিছু হোস্ট/প্রোগ্রামার Ready আশা করে |
| বাসের গতি | 100 kHz বা তার কম দিয়ে শুরু করুন; কিছু মডিউল 400 kHz-এ NACK দেয় |
| অচল মডিউল | কোনো গতিতেই DDM বা শনাক্তকরণ তথ্য নেই; মডিউলকে খারাপ বলার আগে দ্বিতীয় একটি বোর্ডে নিশ্চিত হোন |
পড়লে FFh, 00h বা অর্থহীন মান আসে
| লক্ষণ | কারণ | সমাধান |
|---|---|---|
| সব FFh | I²C NACK: ওই অ্যাড্রেসে কোনো ডিভাইস নেই, অথবা পেজ নেই | অ্যাড্রেস দেখুন (SFP-তে A0h শনাক্তকরণ তথ্য বনাম A2h ডায়াগনস্টিকস; QSFP/CMIS-এ পেজিংসহ একটিমাত্র A0h) |
| সব 00h | মডিউলে পাওয়ার নেই / রিসেটে আটকে আছে; অথবা EEPROM সত্যিই ফাঁকা | ক্র্যাডলে পাওয়ার ও মডিউল-উপস্থিতি দেখুন; ফাঁকা মডিউলও আছে (কোড না করা মজুত) |
| দৈর্ঘ্য ঠিক, কিন্তু বিষয়বস্তু ভুল | উদ্দিষ্ট পেজের বদলে অন্য পেজ পড়া হচ্ছে | পেজ-সিলেক্ট বাইটে (127) মান লিখে আবার পড়ুন; CMIS-এ ব্যাংক সিলেক্টও (126) |
| এলোমেলো / সরে যাওয়া বাইট | বাস খুব দ্রুত, লম্বা ক্যাবল, হোস্টের সঙ্গে বাস কনটেনশন | ≤ 100 kHz-এ নামান; ছোট তার ব্যবহার করুন; চালু সুইচে নয়, টেস্ট বেঞ্চে পড়ুন |
| A2h পড়া ব্যর্থ, A0h ঠিক | মডিউলে ডায়াগনস্টিকস নেই, অথবা ডায়াগনস্টিকস ব্লক সুরক্ষিত | A0h বাইট 92-এর বিট 6 দেখুন (DDM বাস্তবায়িত); কিছু লেখা-সুরক্ষিত ধরন শুধু A0h-এ সাড়া দেয় |
| পড়ার মধ্যে মান বদলে যায় | লাইভ মনিটর, এটি স্বাভাবিক; অথবা ডেটা প্রস্তুত নয় | DDM বাইটের বদলে যাওয়ারই কথা; কোনো স্ন্যাপশটে ভরসা করার আগে ডেটা-রেডি বিট দেখুন |
লেখা একেবারেই ব্যর্থ হয়
WRITE FAIL, ডেটায় NACK, অথবা বাইট আগের মানেই ফেরত আসে:
| কারণ | চেনার উপায় | করণীয় |
|---|---|---|
| পাসওয়ার্ড দরকার (ফার্মওয়্যার কন্ট্রোলার) | পাসওয়ার্ডের অ্যাড্রেসে সঠিক মান না বসানো পর্যন্ত লেখা প্রত্যাখ্যাত হয় (SFP A2h 0x7B–0x7E, QSFP 123–126, CMIS 122–125) | সুরক্ষিত মেমোরি ও পাসওয়ার্ড বিভাগে মডিউলের পাসওয়ার্ড দিন; পরিচিত ভেন্ডর পাসওয়ার্ড ডেটাবেজ থেকে নিয়ে প্রয়োগ করা হয় |
| হার্ডওয়্যার লেখা-সুরক্ষা | পাসওয়ার্ড যা-ই হোক, শুধু পড়া যায়; পাওয়ার-সাইকেলের পরেও থেকে যায় | WP পিন প্রোগ্রামার বোর্ডকেই ড্রাইভ করতে হবে, শুধু সফটওয়্যারে হয় না; দেখুন লেখা-সুরক্ষার ধরন |
| টাইমিং | মাঝে মাঝে ব্যর্থতা, পেজের আংশিক লেখা | ক্লক ধীর করুন (নির্ভরযোগ্য EEPROM লেখার জন্য প্রায়ই ~1 kHz লাগে), বাইট/পেজের মাঝে রাইট-সাইকেল সময় (5–10 ms) মানুন, ব্লকের মাঝে বিলম্ব যোগ করুন |
| রিড-অনলি অঞ্চল | নির্দিষ্ট কিছু বাইট কখনো বদলায় না (চেকসাম, কিছু মডিউলে থ্রেশহোল্ড, ভেন্ডরের এলাকা) | EEPROM-এ নকশাগতভাবেই একটি সুরক্ষিত অঞ্চল থাকে; মডিউল যে ফিল্ডে লেখার অনুমতি দেয়, শুধু সেগুলোতেই লিখুন |
| ভুল অবস্থা | লেখা গ্রহণের আগে CMIS মডিউলের LowPwr অবস্থা, অথবা ডেটা-পাথ নিষ্ক্রিয় থাকা দরকার হতে পারে | আগে মডিউলকে প্রয়োজনীয় অবস্থায় আনুন |
| পেজ নির্বাচিত হয়নি | আপনি সঠিক অফসেটে লিখেছেন, কিন্তু ভুল পেজে | লেখার আগে বাইট 127 (ও 126) সেট করুন এবং পেজ-সিলেক্ট বাইট আবার পড়ে যাচাই করুন |
লেখা “সফল” হয়, তবু টিকে থাকে না
- পাওয়ার-সাইকেলের পর আগের অবস্থায় ফিরে যায় — মডিউল লেখাগুলো সাময়িক মেমোরিতে রাখে এবং ভেন্ডরের সেভ কমান্ড দরকার হয়; সেটি ছাড়া পুরোনো ইমেজ ফিরে আসে। এটি সামলায় একটি প্রোগ্রামিং স্ক্রিপ্ট (লেখা-সুরক্ষার টাইপ 4)।
- সঙ্গে সঙ্গে আগের অবস্থায় ফিরে যায় — মাইক্রোকন্ট্রোলার নিজের স্টোর থেকে EEPROM মিরর করে এবং আপনার লেখা বাইটের ওপর নিজেরটা বসিয়ে দেয়; এর জন্য নির্মাতার অ্যালগরিদম লাগে (টাইপ 5)।
- কিছু বাইট টেকে, কিছু টেকে না — আংশিক সুরক্ষিত ম্যাপ; একটি একটি করে ফিল্ড লিখুন এবং প্রতিটি যাচাই করুন।
সফল লেখার পরও হোস্ট মডিউল প্রত্যাখ্যান করে
| কারণ | সমাধান |
|---|---|
| চেকসাম পুরোনো — CC_BASE (বাইট 63), CC_EXT (95), CC_DMI (A2h 95), QSFP 191/223 | নতুন করে গণনা করুন; CodingBox লেখার সময় এটি নিজে থেকেই করে (মেমোরি ম্যাপ) |
| শনাক্তকরণ তথ্য এখন অসংগত — যেমন ভেন্ডর বদলানো হয়েছে, কিন্তু কমপ্লায়েন্স কোড বা তরঙ্গদৈর্ঘ্য অন্য হার্ডওয়্যারের ইঙ্গিত দেয় | শনাক্তকরণ তথ্য আসল অপটিক্সের সঙ্গে সংগত রাখুন (গতি ও রেট, ফিজিক্যাল অমিল) |
| ভুল মডিউল ধরনের লেআউটে লেখা হয়েছে | XFP-কে SFP-এর মতো করে লেখা, অথবা QSFP-এর পেজ গুলিয়ে ফেলা; ব্যাকআপ থেকে ফিরিয়ে আনুন |
লেখার পর মডিউল অচল
ক্যালিব্রেশন ধ্রুবক, থ্রেশহোল্ড বা ভেন্ডর-নির্দিষ্ট এলাকার (যেখানে কিছু কন্ট্রোলার নিজেদের কনফিগারেশন রাখে) ওপর অর্থহীন মান লিখলে মডিউল ব্রিক হয়ে যেতে পারে। পুনরুদ্ধারের পথ: Code database থেকে লেখার আগে CodingBox-এর নেওয়া ব্যাকআপ ফিরিয়ে আনুন, তারপর শুধু উদ্দিষ্ট ফিল্ডগুলো লিখুন।
সোনালি নিয়ম
- আগে পড়ুন ও সংরক্ষণ করুন — প্রতিটি লেখার আগে একটি পূর্ণ রিড থাকা উচিত, যা ডেটাবেজে জমা হয়।
- প্রথমবার লেখার চেষ্টার আগে সুরক্ষার ধরন শনাক্ত করুন (লেখা-সুরক্ষার ধরন)।
- ধীরে চলুন — ক্লক ও বাইটের মাঝের টাইমিং বেশির ভাগ “এলোমেলো” ব্যর্থতা মেটায়।
- যা লেখার, শুধু তা-ই লিখুন — ফিল্ড লিখুন, গোটা পেজ নয়; ইমেজ ফিরিয়ে আনার সময় ছাড়া।
- পাওয়ার-সাইকেলের পর আবার পড়ে যাচাই করুন।
CodingBox-এ
CodingBox প্রতিটি ফর্ম ফ্যাক্টরের জন্য সঠিক অ্যাড্রেস ও পেজিং ব্যবহার করে মডিউল পড়ে, EEPROM editor স্ক্রিনে কাঁচা ও ডিকোড করা বাইট দেখায়, লেখার সময় চেকসাম নতুন করে গণনা করে, নিজে থেকে ব্যাকআপ রাখে, এবং সুরক্ষিত ও সেভ-কমান্ডওয়ালা মডিউলের জন্য পাসওয়ার্ড দেওয়া ও প্রোগ্রামিং স্ক্রিপ্ট সমর্থন করে (মডিউলে লেখা)। বোর্ড পর্যায়ের ত্রুটি সন্দেহ হলে পণ্যের সমস্যা সমাধান দেখুন।
এই ব্যর্থতাগুলোর পেছনের বাস-প্রক্রিয়া: অ্যাড্রেস, পেজ সিলেক্ট, রাইট-সাইকেল টাইম, ক্লক স্ট্রেচিং: দুই-তারের ইন্টারফেস।
মডিউল কেন যেভাবে সাড়া দেয়: MCU-ইমুলেটেড মেমোরি, বুট উইন্ডো, ক্লক স্ট্রেচিং, সুরক্ষিত অঞ্চল: কন্ট্রোলার ও ফার্মওয়্যার।