Io penso che ho trovato la risposta. Si scopre che questo è un problema noto, ma ho scoperto che solo dopo aver deciso dove si trovava il problema e l'ho cercato!
Ecco il processo che ho seguito, quindi puoi seguirlo (e, se necessario, puoi quindi adattare la tua indagine se vedi risultati che differiscono dai miei presupposti). La linea di fondo è che sembra esserci un'incompatibilità tra (almeno alcuni) il comportamento I²C MSP430 e il comportamento I²C richiesto dal dispositivo che si sospetta essere lo Slave I²C, l' IDT ZSC31014 . Avere il foglio dati per quel dispositivo è fondamentale per capirlo, quindi grazie per averlo trovato.
La buona notizia è che ci sono (almeno) 2 soluzioni alternative per questo problema, che spiegherò alla fine.
La trama si infittisce, sembra che il collegamento di un oscilloscopio diverso non faccia funzionare correttamente il circuito e si può vedere che l'unica differenza è che un ACK non viene trasmesso.
Le nuove tracce sono utili, grazie, anche se le interpreto in modo leggermente diverso.
(Il undershoot del segnale SCL, che mi riguardava nella traccia iniziale, è ancora lì sull'ultima traccia. È interessante notare che il undershoot su SCL sembra maggiore del undershoot su SDA, soprattutto considerando le diverse scale verticali tra i segnali SCL e SDA sul traccia più recente. Suggerirei comunque di indagare sul fatto che il undershoot SCL alla fine, ma non credo che sia correlato al problema principale.)
Ci sono quei due "problemi" su SDA:
Un glitch appena prima o subito dopo l'impulso ACK non è raro, quando un Master I²C rilascia il controllo di SDA per consentire a uno Slave di eseguire l'ACK e quindi il Master potrebbe ricondurre nuovamente SDA. Quindi sto ignorando quello.
È il primo glitch SDA, prima del primo impulso SCL, che è più insolito. Dall'ampiezza di quel primo glitch SDA (vedi più avanti) e dal fatto che si verifica solo prima di quel primo impulso SCL (etichettato 0), ma non si verifica prima degli impulsi SCL successivi dove saremmo in grado di vedere un glitch su SDA (come SCL impulsi etichettati 4, 5, 6 o 7), sappiamo che non è un artefatto di misurazione, né accoppiamento da SCL (ad esempio).
(Per riferimento futuro, il glitch SDA iniziale sembra almeno 2 V nell'ultima traccia, quindi con Vdd a 3,6 V dai commenti precedenti, ciò rende l'ampiezza del glitch SDA almeno (2 / 3,6) = 0,55 x Vdd. Confronta questo con le soglie di livello logico I2C pertinenti discusse più avanti).
Ignorando la differenza ACK, credo di vedere un'altra differenza tra i due set di tracce in quel secondo screenshot. L'ampiezza di quel primo glitch SDA sembra leggermente diversa, confrontando la traccia SDA superiore etichettata C1(giallo-ish?) E la seconda traccia SDA etichettata M3(blu). Ora credo che le differenze nell'ampiezza di quel primo glitch SDA, sia ciò che può far apparire o scomparire il tuo problema, come spiego di seguito.
Anche una risoluzione più specifica del glitch sarebbe di aiuto (questo è uno dei problemi nel tentativo di lavorare su problemi "da remoto" - non riesco a far funzionare l'ambito da solo!). Presumo che quando si ingrandisce, sembra l'inizio di una normale logica I²C "1" (cioè una curva RC sul fronte di salita, specialmente se si rendono temporaneamente più deboli i pull-up, ad esempio 10k), tranne che non lo fa ' t raggiunge la piena tensione positiva prima che sia nuovamente guidato su uno "0" logico. Questo è ciò che viene mostrato su un'altra pagina web collegata in seguito. Se vedi una forma diversa per il tuo problema tecnico, la mia analisi successiva potrebbe non essere applicabile.
Il Master I²C ha il controllo del bus nel punto di quel glitch, tra I²C Start e il primo impulso di clock SCL (che hai etichettato "0" nonostante sia MSbit). Ciò mi ha reso sospettoso del comportamento di MSP430, anche se con SCL basso a quel punto, un glitch SDA non dovrebbe influenzare i dispositivi conformi a I²C, poiché aspetteranno che SCL salga prima di leggere lo stato di SDA.
Quindi, lo I²C Slave è davvero conforme allo I²C? Si scopre che lo ZSC31014 è " pignolo " e meno tollerante rispetto ad altri dispositivi I²C, proprio nel momento in cui credo che l'MSP430 stia producendo quel glitch!
Il foglio dati ZSC31014 elenca 3 aree in cui ammettono che il comportamento I²C del dispositivo è "diverso". Potresti essere interessato anche dai primi due in questo elenco altre volte (che non fa parte di questa analisi), ma è il terzo punto che ho contrassegnato di seguito in rosso, che è correlato a quel primo glitch SDA:
L'ampiezza di quel primo glitch SDA è fondamentale . Se quel glitch non aumenta abbastanza per essere riconosciuto da ZSC31014 come una logica "1" prima che ricada di nuovo, allora sei OK - il dispositivo deve vedere un fronte di discesa su SDA per infrangere quella "regola" e può essere solo un fronte di discesa se è già stato riconosciuto come logica "1".
Tutto ciò che influisce sull'ampiezza di quel glitch SDA, come il carico aggiuntivo di un 'oscilloscopio o analizzatore logico sul segnale SDA, potrebbe essere sufficiente per impedire al glitch di essere riconosciuto da ZSC31014 come raggiungere una logica "1" e quindi non "cadere" SDA edge ", quel terzo punto dell'elenco, può verificarsi (in una buona giornata, a seconda di tensioni, temperature ecc.). Tuttavia, come hai scoperto, la variazione tra diversi oscilloscopi è sufficiente per significare che alcuni di essi aggiungono un carico sufficiente per fermare il problema, mentre altri no. Questa configurazione deve essere molto marginale!
Ciò conferma la mia preoccupazione che i tuoi precedenti gruppi "funzionanti" di sensori, potrebbero "solo" funzionare, dal momento che le MCU MSP430 su quelle configurazioni "funzionanti probabilmente produrranno anche problemi di SDA. La mia teoria su una possibile differenza tra lotti di sensori, che potrebbe spiegare il diverso comportamento che hai segnalato (lotto "funzionante" vs. lotto "non funzionante") verrà spiegata in seguito.
È interessante notare che ZSC31014 è diverso dallo standard I²C in un'altra area che non è menzionata in tale elenco dal produttore, e questo potrebbe spiegare perché sembra che si veda una differenza tra i lotti di sensori.
Le soglie logiche I²C standard sono (semplificate) - sotto 0,3 x Vdd per la logica "0" e sopra 0,7 x Vdd per la logica "1" come mostrato nella specifica I²C :
Tuttavia, ZSC31014 ha soglie diverse , 0,2 x Vdd e 0,8 x Vdd, il che significa che la sua "regione non definita" tra tali soglie è maggiore rispetto ai dispositivi I²C tipici:
Quella "regione indefinita" più ampia aumenta la possibilità che il glitch entri nell'area del livello di tensione indefinita, dove potrebbe essere riconosciuto come una logica "1" (ricordate, qualsiasi cosa al di sopra di 0,2 x Vdd potrebbe essere riconosciuta dallo ZSC31014 come una logica "1" , poiché nella regione indefinita, tutto è permesso - è solo sopra 0,8 x Vdd quando deve essere riconosciuto come una logica "1"). E, come spiegato in precedenza, se il problema tecnico viene riconosciuto da ZSC31014 come se avesse raggiunto una logica "1", quindi quando ricade di nuovo in una logica "0", hai infranto quella "regola" contrassegnata in rosso per il comportamento I²C richiesto dallo ZSC31014.
Poiché il riconoscimento dei livelli logici in quella regione di tensione "non definita" non è specificato, il produttore del sensore non sta infrangendo la specifica se crea un batch che riconosce la logica "1" solo quando raggiunge 0,7 x Vdd, ma crea un altro batch che riconosce una logica "1" fino a 0,4 x Vdd, ad esempio. Quell'ipotetico secondo lotto sarebbe più probabile che vedesse il glitch dell'SDA come un limite SDA in calo, in violazione di quel terzo punto del loro elenco, ma non infrangendo le loro specifiche.
(Molti dei problemi a cui ho lavorato nel corso degli anni sono stati così: ci sono due dispositivi, nessuno dei quali rompe individualmente una specifica che ha scappatoie - ma uno è esigente e meno tollerante, in un punto in cui il l'altro ha bisogno che i dispositivi connessi siano più tolleranti a causa del suo comportamento oscuro! Ognuno di questi due dispositivi si interfaccia bene con la maggior parte degli altri dispositivi, ma sono inaffidabili (o falliscono completamente) quando sono collegati tra loro.)
Che cosa si può fare? Ho pensato a due opzioni:
Non usare un MSP430 - usa un altro MCU che non crei quel glitch SDA iniziale. Tuttavia, mi aspetto che tu abbia investito molto tempo nel software e non vorrebbe trasferire il codice su un altro MCU, se ciò potesse essere evitato.
"Bit-bang" il protocollo I²C su MSP430, invece di utilizzare il suo modulo hardware I²C integrato. In questo modo, hai il controllo totale dei segnali I²C e puoi evitare che si verifichi quel problema. Tuttavia, sarebbe ovviamente un po 'di lavoro creare le proprie routine I²C, eseguirne il debug e il codice risultante potrebbe essere più grande di quando si utilizza il modulo hardware I²C MSP430, che a sua volta potrebbe essere un problema se si ha poco spazio su Flash.
Quindi sono andato alla ricerca di problemi I²C MSP430 e ho scoperto che questa combinazione di MSP430 + ZSC31014 è un problema noto, a causa di quel primo problema tecnico SDA da MSP430! Vedi questa discussione sul forum TI E2E MSP430:
Forum TI E2E: impulsi glitch MSP430 I2C che causano problemi al chip periferico I2C
La soluzione menzionata qui è quella di modificare l'indirizzo I²C ZSC31014 in modo che SDA sia elevato nel momento in cui si potrebbe verificare un glitch positivo , e poiché SDA è reso alto quindi comunque, non c'è alcun glitch effettivo su SDA:
La nostra soluzione è configurare il chip ZSC in modo che abbia un indirizzo con il suo set di bit 6 (ad es. Ora stiamo usando 0x42) - questo trasforma l'impulso glitch in un bel bit "alto" pulito per la durata dell'indirizzo bit 6, che elimina del problematico fronte di discesa.
La stessa soluzione alternativa è effettivamente il contrario del suggerimento nel foglio dati ZSC31014, nella casella rossa che ho contrassegnato. Dicono che un glitch SDA deve essere evitato se il primo bit (che è il MSbit) dell'indirizzo I²C ZSC31014 è 0 - quindi non rendere il MSbit dell'indirizzo I²C uno "0", rendilo invece "1" invece impostare il bit 6 nell'indirizzo I²C a 7 bit!
Dato che il thread del forum TI E2E e il foglio dati ZSC31014 si stanno entrambi concentrando sull'indirizzo I²C, allora forse il glitch SDA non si verifica o non è un problema se si verifica durante l'invio di altri dati sul bus. Dovrai indagare su questo.
Pertanto, ignorando la prima soluzione alternativa dell'utilizzo di una MCU diversa, le due (più pratiche) soluzioni alternative sono:
- Bit-bang del bus I²C MSP430 scrivendo il proprio codice, in modo da non creare quel glitch su SDA, o
- Modificare l'indirizzo I²C ZSC31014 in modo che sia impostato il bit 6 del suo indirizzo a 7 bit, il che significa che SDA è già elevato quando altrimenti si verificherebbe il glitch, quindi non si verifica alcun glitch effettivo su SDA quando viene indirizzato ZSC31014 (supponendo che un glitch SDA sia non si verifica dopo altri eventi I²C Start durante il trasferimento dei dati o, se si verifica, che ZSC31014 non viene "sconvolto").
Spero che aiuti!
