ฉันคิดว่าฉันพบคำตอบแล้ว ปรากฎว่านี่เป็นปัญหาที่ทราบ แต่ฉันก็พบว่าหลังจากฉันตัดสินใจว่าปัญหานั้นอยู่ที่ไหนและค้นหาสิ่งนั้น!
นี่คือกระบวนการที่ฉันดำเนินการเพื่อให้คุณสามารถติดตามได้ (และหากจำเป็นคุณสามารถปรับการสอบสวนของคุณถ้าคุณเห็นผลลัพธ์ที่แตกต่างจากสมมติฐานของฉัน) บรรทัดล่างคือว่ามีที่ดูเหมือนจะเป็นความไม่ลงรอยกันระหว่าง (อย่างน้อยบางส่วน) MSP430 I²CพฤติกรรมและพฤติกรรมI²Cจำเป็นโดยอุปกรณ์ที่คุณสงสัยว่าจะเป็นI²Cทาสที่IDT ZSC31014 การมีแผ่นข้อมูลสำหรับอุปกรณ์นั้นมีความสำคัญอย่างยิ่งต่อการทำความเข้าใจสิ่งนี้ดังนั้นขอขอบคุณสำหรับการค้นหา
ข่าวดีก็คือว่ามี (อย่างน้อย) 2 วิธีแก้ปัญหาสำหรับปัญหานี้ซึ่งฉันจะอธิบายในตอนท้าย
พล็อตหนาขึ้นปรากฏว่าการเชื่อมต่อออสซิลโลสโคปที่แตกต่างกันทำให้วงจรทำงานไม่ถูกต้องและจะเห็นได้ว่าความแตกต่างเพียงอย่างเดียวคือ ACK ไม่ได้ถูกส่ง
ร่องรอยใหม่นั้นมีประโยชน์ขอบคุณแม้ว่าฉันจะตีความมันต่างออกไปเล็กน้อย
(สัญญาณ SCL undershoot ซึ่งเกี่ยวข้องกับฉันในการติดตามเริ่มต้นยังคงมีอยู่ในการติดตามล่าสุดมันน่าสนใจที่การ Undershoot บน SCL นั้นดูเหมือนจะดีกว่า Undershoot บน SDA โดยเฉพาะอย่างยิ่งการพิจารณาระดับแนวตั้งที่แตกต่างระหว่างสัญญาณ SCL และ SDA ใน การติดตามล่าสุดฉันยังคงแนะนำให้ตรวจสอบว่าในที่สุด SCL จะเปิดการทำงานของ Undershoot แต่ฉันไม่เชื่อว่าเกี่ยวข้องกับปัญหาหลัก)
มี "บกพร่อง" สองอันใน SDA:
ความผิดพลาดก่อนหรือหลังชีพจร ACK ไม่ใช่เรื่องแปลกเมื่อI²C Master ออกการควบคุม SDA เพื่อให้ Slave ดำเนินการ ACK จากนั้น Master อาจทำการ SDA อีกครั้ง ดังนั้นฉันไม่สนใจสิ่งนั้น
มันเป็นความผิดพลาด SDA ในช่วงต้นก่อนชีพจร SCL ครั้งแรกซึ่งผิดปกติมากขึ้น จากแอมพลิจูดของความผิดพลาด SDA ในช่วงต้น (ดูภายหลัง) และความจริงมันเกิดขึ้นก่อนที่ SCL พัลส์แรก (ติดป้าย 0) แต่ไม่เกิดขึ้นก่อน SCL ในภายหลังซึ่งเราจะสามารถเห็นความผิดพลาดใน SDA (เช่น SCL พัลส์ที่มีป้ายกำกับ 4, 5, 6 หรือ 7) เรารู้ว่าไม่ใช่สิ่งประดิษฐ์การวัดหรือการมีเพศสัมพันธ์จาก SCL (ตัวอย่าง)
(สำหรับการอ้างอิงในภายหลังข้อผิดพลาด SDA เริ่มต้นดูเหมือนอย่างน้อย 2V ในการติดตามล่าสุดดังนั้นด้วย Vdd ที่ 3.6V จากความคิดเห็นก่อนหน้าซึ่งทำให้แอมพลิจูดความผิดพลาด SDA อย่างน้อย (2 / 3.6) = 0.55 x Vdd เปรียบเทียบกับ เกณฑ์ระดับตรรกะ I2C ที่เกี่ยวข้องที่กล่าวถึงในภายหลัง)
ไม่สนใจความแตกต่าง ACK ฉันเชื่อว่าฉันเห็นความแตกต่างระหว่างร่องรอยสองชุดในภาพหน้าจอที่สองนั้น แอมพลิจูดของความผิดพลาด SDA ในช่วงต้นนั้นแตกต่างกันเล็กน้อยเมื่อเปรียบเทียบการติดตาม SDA ด้านบนที่มีป้ายกำกับC1(สีเหลือง - ish?) และการติดตาม SDA ลำดับที่ 2 M3(สีน้ำเงิน) ตอนนี้ฉันเชื่อว่าความแตกต่างในแอมพลิจูดของความผิดพลาด SDA ในช่วงต้นนั้นเป็นสิ่งที่อาจทำให้ปัญหาของคุณปรากฏหรือหายไปตามที่ฉันอธิบายด้านล่าง
ความละเอียดที่มากขึ้นโดยเฉพาะกับความผิดพลาดจะช่วยได้ (นั่นเป็นหนึ่งในปัญหาในการพยายามแก้ไขปัญหา "จากระยะไกล" - ฉันไม่สามารถใช้งาน 'ขอบเขตตัวเอง!) ฉันจะสมมติว่าเมื่อคุณซูมเข้าดูเหมือนว่าจุดเริ่มต้นของตรรกะI²Cปกติ "1" (เช่นเส้นโค้ง RC บนขอบที่สูงขึ้นโดยเฉพาะถ้าคุณทำ pull-ups ที่อ่อนแอลงเช่น 10k) ยกเว้นว่ามันจะไม่ได้ ' t ถึงแรงดันบวกเต็มก่อนที่จะถูกผลักไปยังตรรกะ "0" อีกครั้ง นั่นคือสิ่งที่ปรากฏบนหน้าเว็บอื่นที่เชื่อมโยงในภายหลัง หากคุณเห็นรูปร่างผิดปกติของคุณการวิเคราะห์ในภายหลังของฉันอาจไม่ได้ผล
I²C Master ควบคุมรถบัสที่จุดผิดพลาดระหว่างI²C Start และพัลส์นาฬิกา SCL แรก (ซึ่งคุณระบุว่า "0" แม้ว่าจะเป็น MSbit) นั่นทำให้ฉันสงสัยพฤติกรรมของ MSP430 แม้ว่า SCL จะมีน้อย ณ จุดนั้นความผิดพลาด SDA ไม่ควรส่งผลกระทบต่ออุปกรณ์ที่สอดคล้องกับI²Cเนื่องจากพวกเขาจะรอให้ SCL สูงขึ้นก่อนที่พวกเขาจะอ่านสถานะของ SDA ต่อไป
ดังนั้นI²C Slave นั้นเป็นไปตามI²C จริง ๆหรือไม่ ปรากฎว่า ZSC31014 เป็น " จุกจิก " และทนน้อยกว่าอุปกรณ์I²Cอื่น ๆ ในเวลาที่ฉันเชื่อว่า MSP430 กำลังผลิตผิดพลาดนั้น!
ZSC31014 แผ่นข้อมูลรายชื่อ 3 พื้นที่ที่พวกเขายอมรับพฤติกรรมI²Cของอุปกรณ์คือ "แตกต่าง" คุณอาจได้รับผลกระทบจากสองคนแรกในรายการนี้ในเวลาอื่น ๆ (นั่นไม่ใช่ส่วนหนึ่งของการวิเคราะห์นี้) แต่เป็นจุดที่สามที่ฉันทำเครื่องหมายไว้ด้านล่างเป็นสีแดงซึ่งเกี่ยวข้องกับความผิดพลาด SDA ในช่วงต้น:
แอมพลิจูดของความผิดพลาด SDA เริ่มต้นนั้นสำคัญมาก หากความผิดพลาดนั้นไม่สูงพอที่จะรับรู้โดย ZSC31014 ว่าเป็นตรรกะ "1" ก่อนที่มันจะตกลงมาอีกครั้งคุณก็โอเค - อุปกรณ์จะต้องเห็นขอบที่ตกลงบน SDA เพื่อทำลาย "กฎ" นั้นและสามารถทำได้ล้มขอบถ้ามันได้รับการยอมรับว่าเป็นลอจิก "1"
สิ่งใดที่มีผลต่อแอมพลิจูดของความผิดพลาด SDA นั้นเช่นการโหลดเพิ่มเติมของ 'ขอบเขตหรือตัววิเคราะห์เชิงตรรกะบนสัญญาณ SDA อาจเพียงพอที่จะหยุดความผิดพลาดที่ ZSC31014 จำได้ว่าเป็นการเข้าถึงตรรกะ "1" และดังนั้นจึงไม่มี ขอบ SDA "ซึ่งเป็นจุดที่สามในรายการสามารถเกิดขึ้นได้ (ในวันที่ดีขึ้นอยู่กับแรงดันไฟฟ้าอุณหภูมิ ฯลฯ ) อย่างไรก็ตามตามที่คุณได้พบความแตกต่างระหว่างออสซิลโลสโคปที่แตกต่างกันนั้นเพียงพอที่จะหมายความว่าบางส่วนของพวกมันเพิ่มภาระมากพอที่จะหยุดปัญหาและสิ่งอื่น ๆ ไม่ได้ การตั้งค่านี้จะต้องมีความสำคัญมาก!
สิ่งนี้เป็นการยืนยันความกังวลของฉันว่าเซ็นเซอร์ "ทำงาน" รุ่นก่อนหน้าของคุณอาจเป็นเพียง "ทำงาน" เนื่องจาก MSP430 MCUs ในการตั้งค่า "ทำงาน" เหล่านั้นมีแนวโน้มที่จะสร้างข้อบกพร่อง SDA ทฤษฎีของฉันเกี่ยวกับความแตกต่างที่เป็นไปได้ระหว่างชุดของเซ็นเซอร์ซึ่งสามารถอธิบายพฤติกรรมที่แตกต่างที่คุณได้รายงาน (ชุดทำงาน "กับชุด" ไม่ทำงาน ") จะอธิบายต่อไป
น่าสนใจ ZSC31014 นั้นแตกต่างจากI²Cมาตรฐานในพื้นที่อื่นซึ่งไม่ได้กล่าวถึงในรายชื่อนั้นจากผู้ผลิตและนี่อาจอธิบายได้ว่าทำไมคุณถึงเห็นความแตกต่างระหว่างชุดเซ็นเซอร์
ตรรกะมาตรฐานI²Cเป็นเกณฑ์ (ลดความซับซ้อน) - ต่ำกว่า 0.3 x Vdd สำหรับตรรกะ "0" และสูงกว่า 0.7 x Vdd สำหรับตรรกะ "1" ดังแสดงในข้อมูลจำเพาะของI²C :
อย่างไรก็ตาม ZSC31014 มีขีด จำกัด ที่แตกต่างกัน 0.2 x Vdd และ 0.8 x Vdd ซึ่งหมายความว่า "ขอบเขตที่ไม่ได้กำหนด" ระหว่างขีด จำกัด เหล่านั้นมีขนาดใหญ่กว่าอุปกรณ์I²Cทั่วไป:
ที่มีขนาดใหญ่ "ภาคที่ไม่ได้กำหนด" เพิ่มโอกาสของการผิดพลาดเข้าพื้นที่ระดับแรงดันไฟฟ้าที่ไม่ได้กำหนดที่มันอาจจะได้รับการยอมรับว่าเป็นลอจิก "1" (จำสิ่งที่เหนือ 0.2 x Vdd อาจได้รับการยอมรับโดย ZSC31014 เป็นลอจิก "1" เนื่องจากอยู่ในภูมิภาคที่ไม่ได้กำหนดสิ่งใด ๆ ที่ได้รับอนุญาต - มีค่ามากกว่า 0.8 x Vdd เมื่อต้องได้รับการยอมรับว่าเป็นตรรกะ "1") และดังที่อธิบายไว้ก่อนหน้านี้หาก ZSC31014 รู้จักความผิดพลาดว่ามีตรรกะถึง "1" แล้วเมื่อมันตกลงไปที่ตรรกะ "0" อีกครั้งคุณได้ทำลาย "กฎ" ที่ทำเครื่องหมายเป็นสีแดงสำหรับพฤติกรรมI²Cที่ต้องการ โดย ZSC31014
เนื่องจากไม่ได้ระบุการรับรู้ระดับตรรกะในส่วนแรงดันไฟฟ้า "ไม่ได้กำหนด" ผู้ผลิตเซ็นเซอร์จะไม่ทำลายข้อกำหนดหากทำหนึ่งแบทช์ที่รับรู้ตรรกะ "1" เฉพาะเมื่อถึง 0.7 x Vdd แต่ให้แบทช์อื่นที่รับรู้ ตรรกะ "1" ต่ำสุดที่ 0.4 x Vdd ตัวอย่างเช่น ชุดที่สองสมมุติว่ามีแนวโน้มที่จะเห็นความผิดพลาด SDA เป็นขอบ SDA ที่ลดลงซึ่งเป็นการละเมิดจุดที่สามนั้นในรายการของพวกเขา แต่ยังไม่ได้ทำลายข้อกำหนดของพวกเขา
(ปัญหาหลายอย่างที่ฉันได้ทำในช่วงหลายปีที่ผ่านมาเป็นเช่นนี้: มีสองอุปกรณ์ซึ่งทั้งสองอย่างนั้นไม่แตกต่างกันไปตามข้อกำหนดที่มีช่องโหว่ - แต่ปัญหาหนึ่งคือจุกจิกและทนทานน้อยกว่าในจุดที่ อีกหนึ่งความต้องการอุปกรณ์ที่เชื่อมต่อจะเป็นมากขึ้นใจกว้างเพราะของพฤติกรรมปิดบัง! แต่ละคนของทั้งสองอุปกรณ์จะปรับการเชื่อมต่อกับส่วนใหญ่ของอุปกรณ์อื่น ๆ แต่ที่ไม่น่าเชื่อถือ (หรือล้มเหลวอย่างสิ้นเชิง) เมื่อเชื่อมต่อกับแต่ละอื่น ๆ .)
แล้วคุณจะทำอย่างไร ฉันคิดถึงสองตัวเลือก:
อย่าใช้ MSP430 - ใช้ MCU ตัวอื่นซึ่งไม่ได้สร้างความผิดพลาด SDA ก่อนหน้านั้น อย่างไรก็ตามฉันคาดว่าคุณจะลงทุนซอฟต์แวร์เป็นจำนวนมากและไม่ต้องการที่จะย้ายรหัสไปยัง MCU อื่นหากไม่สามารถหลีกเลี่ยงได้
"Bit-bang" โปรโตคอลI²Cบน MSP430 แทนที่จะใช้โมดูลฮาร์ดแวร์I²Cในตัว ด้วยวิธีนี้คุณอยู่ในการควบคุมทั้งหมดของสัญญาณI²Cและสามารถป้องกันความผิดพลาดนั้นได้ อย่างไรก็ตามมันจะเป็นงานที่ต้องสร้างกิจวัตรI²Cของคุณเองตรวจแก้จุดบกพร่องและโค้ดผลลัพธ์อาจใหญ่กว่าเมื่อใช้โมดูลฮาร์ดแวร์ MSP430 I²Cซึ่งตัวเองอาจเป็นปัญหาหากคุณมีพื้นที่แฟลชไม่เพียงพอ
จากนั้นฉันก็ค้นหาปัญหา MSP430 I²Cและฉันพบว่าการรวมกันของ MSP430 + ZSC31014 นี้เป็นปัญหาที่ทราบกันดีเนื่องจากปัญหา SDA ในช่วงต้นจาก MSP430! ดูกระทู้นี้ในฟอรั่ม TI E2E MSP430:
ฟอรัม TI E2E: MSP430 I2C ความผิดพลาดพัลส์ทำให้เกิดปัญหากับชิปต่อพ่วง I2C
วิธีแก้ปัญหาที่กล่าวถึงนั้นคือการเปลี่ยนที่อยู่ ZSC31014 I²Cเพื่อให้ SDA สูงในเวลาที่มีข้อผิดพลาดในเชิงบวกที่อาจเกิดขึ้นและเนื่องจาก SDA สูงขึ้นแล้วดังนั้นไม่มีความผิดพลาดจริงใน SDA:
วิธีแก้ปัญหาของเราคือการกำหนดค่าชิป ZSC ให้มีที่อยู่ด้วยชุดบิต 6 (เช่นตอนนี้เรากำลังใช้ 0x42) - นี่จะเปลี่ยนพัลส์ผิดพลาดเป็นบิต "สูง" ที่สะอาดสำหรับระยะเวลาบิตที่อยู่ 6 ที่สะอาด ของขอบน้ำตกที่มีปัญหา
วิธีแก้ปัญหาแบบเดียวกันคือการย้อนกลับของข้อเสนอแนะในแผ่นข้อมูล ZSC31014 ในกล่องสีแดงที่ฉันทำเครื่องหมายไว้ พวกเขาบอกว่าจะต้องป้องกันความผิดพลาด SDA หากบิตแรก (ซึ่งคือ MSbit) ของที่อยู่ ZSC31014 I²Cคือ 0 - ดังนั้นอย่าทำให้ MSbit ของที่อยู่I²Cเป็น "0" ทำให้เป็น "1" แทนเช่น กำหนดบิต 6 ในที่อยู่I²C 7 บิต!
เนื่องจากเธรดฟอรัม TI E2E และแผ่นข้อมูล ZSC31014 ทั้งคู่เน้นไปที่ที่อยู่I²Cดังนั้นบางทีความผิดพลาด SDA อาจจะไม่เกิดขึ้นหรือไม่มีปัญหาหากเกิดขึ้นระหว่างการส่งข้อมูลอื่น ๆ บนบัส คุณจะต้องตรวจสอบว่า
ดังนั้นการเพิกเฉยวิธีแก้ปัญหาแรกของการใช้ MCU ที่แตกต่างกันวิธีแก้ปัญหาทั้งสอง (มีประโยชน์มากกว่า) คือ:
- บิตบัส MSP430 I²Cบัสโดยเขียนรหัสของคุณเองเพื่อที่คุณจะได้ไม่สร้างความผิดพลาดนั้นบน SDA หรือ
- เปลี่ยนที่อยู่ ZSC31014 I²Cเพื่อให้บิต 6 ของที่อยู่ 7 บิตถูกตั้งค่าซึ่งหมายความว่า SDA นั้นสูงแล้วเมื่อมีข้อผิดพลาดเกิดขึ้นดังนั้นจึงไม่มีข้อผิดพลาดเกิดขึ้นจริงบน SDA เมื่อมีการแก้ไข ZSC31014 (สมมติว่า SDA จะไม่เกิดขึ้นหลังจากI²Cอื่น ๆ เริ่มเหตุการณ์ระหว่างการถ่ายโอนข้อมูลหรือหากเกิดขึ้น ZSC31014 จะไม่ได้รับ "อารมณ์เสีย")
หวังว่าจะช่วย!
