ZHCSRX7 june 2023 BQ79616
PRODUCTION DATA
COMM CLEAR 在基底器件的 RX 引腳上發(fā)送。它不會發(fā)送到堆棧器件。無論 TX 狀態(tài)如何,都無法禁用 RX,并且可以隨時發(fā)送 COMM CLEAR。確保 COMM CLEAR 不超過 tUART(CLR) 位周期的最大值,因為這可能會導致識別其他通信 ping。
圖 8-26 UART COMM CLEAR使用 COMM CLEAR 命令清除接收器并指示 UART 引擎尋找新的幀開始。COMM CLEAR 之后的下一個字節(jié)始終被視為幀開始字節(jié)。當檢測到時,COMM CLEAR 會設(shè)置 FAULT_COMM1[COMMCLR_DET] 標志。主機必須在 COMM CLEAR 之后至少等待 tUART(RXMIN) 才能開始發(fā)送新幀。需要注意的是,除了 [COMMCLR_DET] 標志之外,還會設(shè)置 FAULT_COMM1[STOP_DET] 標志,因為 COMM CLEAR 時序違反了典型的字節(jié)時序,STOP 位被視為 0。
SLEEPtoACTIVE ping/音也會清除 UART 接收器。在從 SLEEP 模式轉(zhuǎn)換為 ACTIVE 模式時,該 ping/音會設(shè)置 [COMMCLR_DET] 標志。如果在 ACTIVE 模式期間發(fā)送了該 ping/音,則會設(shè)置 [COMMCLR_DET] 和 [STOP_DET] 標志。
在菊花鏈通信期間發(fā)送 COMM CLEAR:
當發(fā)送讀取命令,但響應(yīng)尚未完全返回到主機時,如果在這種情況下在基底器件中接收到 COMM CLEAR,則器件響應(yīng)會被丟棄。此外,堆棧器件看不到 COMM CLEAR 并繼續(xù)發(fā)送轉(zhuǎn)發(fā)到主機的響應(yīng),從而導致主機接收到意外的響應(yīng)幀。因此,主機應(yīng)通過等待從堆棧接收到所有響應(yīng)后再發(fā)送 COMM CLEAR 來避免這種情況。
如果發(fā)生上述情況,則可能會設(shè)置基底器件低級通信調(diào)試寄存器 DEBUG_UART_RR_TR[TR_WAIT](指示器件正在等待發(fā)送響應(yīng))或 DEBUG_UART_RR_TR[TR_SOF](指示器件正在發(fā)送數(shù)據(jù)時接收到 COMM CLEAR)位,具體取決于接收 COMM CLEAR 信號的時序。
在使用多點配置時,必須在每個幀之前使用 COMM CLEAR 信號以確保一致的通信。