การชนบิต I2C EEPROM: เขียนดี แต่ถ้าบิตแรกไม่ได้ถูกตั้งค่า

ขณะนี้ฉันกำลังทำงานเกี่ยวกับโครงการ I2C EEPROM โดยใช้การทุบบิตเพื่อขับ SDA และ SCL

ฟังก์ชั่นการอ่านของฉันทำงานได้ดี แต่เมื่อใดก็ตามที่ฉันเขียนไบต์ใด ๆ ด้วย "1" นำหน้าฉันจะอ่าน FF ย้อนกลับเสมอ แม้ว่าไบต์จะถูกโปรแกรมด้วยอย่างอื่นมาก่อน นำ "0" สมบูรณ์แบบ มันไม่ใช่รูทีนการอ่านของฉัน อย่างที่ฉันเห็นในขอบเขตมันจะคืนค่า FF

ฉันกำลังมองหาคำแนะนำเกี่ยวกับสาเหตุที่อาจเป็นเช่นนี้ มีอะไรที่ชัดเจนหรือไม่ที่ฉันอาจคิดถึงซึ่งอาจทำให้เกิดปัญหาได้ [ฉันไม่สามารถโพสต์รหัสได้ - บริษัท เป็นความลับ ... :(]

ทุกรูปคลื่นที่ฉันดูตรงตามสเปคอย่างแน่นอน ฉัน decoupling EEPROM pull ups ของฉันคือ 2.2k ดังนั้นภายในสเป็ค ฉันกำลังตอกบัตรอยู่ที่ประมาณ 500 Hz ในต้นแบบนี้ ชิปกำลังส่ง ACK ไปยังแต่ละไบต์ของฉันดังนั้นจึงรับรู้ได้ แต่มันไม่ทำงาน ...

ฉันใช้ Microchip 24LC256

อัลกอริทึมการเขียนที่ง่ายขึ้นสำหรับหนึ่งไบต์:

wait
SDA low
SCL low
wait
for each bit
    if bit is set:   SDA high
    if bit is unset: SDA low
    wait
    SCL high
    wait
    wait
    SCL low
    wait
wait
SDA high 
SCL high
wait
wait
check ACK status
SDA low
SCL low
wait
return ACK status

อัลกอริทึมการอ่านที่ง่ายขึ้นสำหรับหนึ่งไบต์:

wait
SCL low
SDA high
for each bit (8 bits)
    SCL high
    wait
    wait
    SCL low
    wait
    check and store received bit
    wait
do a NACK or ACK depending on if it is the last byte

คุณกำลังอ่านข้อมูลหลังจากที่นาฬิกาเหลือน้อยอีกครั้ง คุณจะต้องทำอย่างนั้นระหว่างการทำนาฬิกาให้สูงและทำให้ต่ำ หลังจากที่นาฬิกาอยู่ในระดับต่ำทาสได้รับอนุญาตให้เปลี่ยนสายข้อมูลไม่ได้ในขณะที่มันสูง

ดังนั้นการอ่านควรเป็นดังนี้:

wait
SCL low
SDA high
for each bit (8 bits)
    SCL high                      <--------
    wait
    check and store received bit  <--------
    wait
    SCL low                       <--------
    wait
    wait
do a NACK or ACK depending on if it is the last byte

ปัญหาในที่สุดก็กลายเป็นว่าฉันถูกส่งเงื่อนไข STOP โดยไม่ตั้งใจภายใต้เงื่อนไขบางอย่างเนื่องจากเวลาที่ยุ่งเหยิง ฉันเลิกใช้ขอบเขตและออกจากเครื่องวิเคราะห์ลอจิกและสามารถแก้ไขปัญหาได้ใน 15 นาทีเพราะมันเน้น STOP ซึ่งไม่ควรมี ฉันจะเลือกผู้ที่จะให้รางวัลกับคำตอบที่เป็นประโยชน์ที่สุด ขอบคุณสำหรับการแก้ปัญหาทั้งหมด

ตกลงขอบเขตของคุณพิสูจน์ว่าไบต์ที่ 1 ที่เข้ามาใน PIC ไม่ดีดังนั้นจึงไม่ใช่ฟังก์ชั่นการอ่าน PIC

คุณตรวจสอบว่าระยะเวลาการเขียนนั้นตกลงเมื่อสิ้นสุดการรับหรือไม่?

สิ่งนี้ล้มเหลวในทั้งสองโหมดด้านล่างหรือไม่

- Byte mode sequential
- Page mode Sequential

ข้อมูลจำเพาะแสดง "บิตที่มีนัยสำคัญมากที่สุด (MSB) 'b7' ถูกส่ง fi rst" สิ่งนี้ก็เหมือนกันเมื่อ b7 = 1 ที่ไบต์ทั้งหมดถูกอ่านเป็น FF ดังนั้นมันจะไม่ถูกเขียนและลบเฉพาะ (เงื่อนไขข้อผิดพลาด) เมื่อ b7 = 1 หรืออ่านกลับไม่ดีเป็น FF โดยไม่คำนึงถึงเนื้อหาก่อนหน้า เนื่องจากการเขียนทุกครั้งเป็นการลบแบบกว้างไบต์ก่อนที่จะเขียนอาจเป็นการเขียนที่ไม่ดีหรือการอ่านที่ไม่ดีหรือระยะเวลาของไบต์ที่ 1 นั้นแตกต่างกัน

คำแนะนำ: ตรวจสอบสัญญาณ PTC ระหว่างการเขียน / อ่านเพื่อให้แน่ใจว่าการทำงานปกติ

มีตัวเลือกในการใช้นาฬิกาภายนอกสำหรับกำหนดเวลาความยาวของรอบ E / W โดยใช้ PTC คุณเคยลองใช้สิ่งนี้หรือไม่?

รอบเวลา tE / W

• ออสซิลเลเตอร์ภายใน 7ms typ
• นาฬิกาภายนอก 4 ~ 10 ms นาที ~ สูงสุด

มันผ่านเกณฑ์นี้หรือไม่?

ฟังดูเหมือนจะเป็นสองสิ่ง:

1. บนรถบัสมีอะไรอีกบ้าง? จะมีการช่วงชิงบัสกับอุปกรณ์อื่นที่กำลังถูกรีเซ็ตหรือไม่เตรียมการหรือไม่?
2. คุณเปลี่ยนทิศทางของพิน I / O อย่างถูกต้องหรือไม่? 0xFFหากมีการปรับการทำงานในกรณีที่ออกคุณอาจจะลืมไม่ได้ตั้งใจที่จะเปลี่ยนทิศทางของขาที่จะป้อนข้อมูลและมักจะอ่าน สลักอาจถูกทิ้งไว้เป็นเอาท์พุทขับรถบัสในขณะที่คุณกำลังอ่านจากมัน
3. คุณมี pull-ups ภายในที่ขาของตัวเองและ / หรือบนเส้น I / O หรือไม่? ไมโครคอนโทรลเลอร์มักจะให้ช่วงของความต้านทานและไม่ใช่ค่าคงที่ คุณอาจต้องการปิดการใช้งาน pull-ups บนไมโครและเพียงแค่ใช้งานแบบแยกบนบัสเนื่องจากคุณสามารถรับความต้านทาน pull-up ที่แม่นยำยิ่งขึ้นจากส่วนประกอบที่ไม่ต่อเนื่อง
4. ขั้วของนาฬิกา - คุณแน่ใจหรือไม่ว่าคุณกำลังวัดที่ขอบ / เฟสด้านขวาระหว่างนาฬิกา / ข้อมูล คุณอาจกำลังตอกย้ำสิ่งที่ดูดีสำหรับคุณในขอบเขต แต่ถ้าเฟสอยู่นอกบรรทัด EEPROM ทั้งหมดของคุณจะเห็นเป็น0xFFs (และน่าจะกลับมาเหมือนเดิมเพราะอาจเป็นคำสั่ง / เงื่อนไขที่ไม่ถูกต้อง)

ฉันส่งสิ่งนี้เป็นความคิดเห็นข้างต้น แต่ความมั่นใจในคำตอบของฉันเพิ่มขึ้นอย่างเงียบ ๆ ในจิตใจของฉันดังนั้นฉันจึงส่งเสริมให้เป็นคำตอบ

ฉันมีลางสังหรณ์อย่างบ้าคลั่งว่านี่เป็นข้อบกพร่องซอฟต์แวร์ระดับต่ำที่เกี่ยวข้องกับการลงนามของตัวแปรบางอย่าง ในแต่ละรหัสบิตคุณเข้าสู่ระบบโดยไม่ได้ตั้งใจด้วยการเลื่อนขวาหรือไม่? หากคุณเป็นผู้นำของคุณในที่สุดก็จะทิ้งคุณด้วย 0xFF หลังจาก 7 กะการดำเนินงาน

สตีเว่นพูดพาดพิงถึงสิ่งนี้ในความคิดเห็น แต่คุณได้เห็นความศักดิ์สิทธิ์ของการดำเนินการเขียนของคุณบน osilloscope หรือคุณคิดว่ามันทำงานโดยดูจากครึ่งหลังที่อ่านดีหรือไม่? หากคุณยังไม่ได้ลองดูการดำเนินการเขียนของค่า 0xAA นั่นอาจเป็นสิ่งที่ดีที่จะลอง

หากคุณสามารถระบุรหัสที่แท้จริงของวงในของคุณและการประกาศตัวแปรที่เกี่ยวข้องเราอาจสามารถตรวจพบข้อบกพร่อง