Przykłady debugowania sieci CAN
Poniższe zdjęcie pokazuje przykładowy system z siecią CAN, który został zdebugowany. W płytce prototypowej po prawej stronie przerwaniu uległa ścieżka z sygnałem CANH, prowadząca do portu wyjściowego z układu. Uszkodzenie to powstało na skutek ciągłego przenoszenia tego systemu. Podczas przenoszenia PCB ocierało się w tym miejscu o nakrętkę śruby montującej płytkę do uchwytu. Ten problem uwidacznia się od razu po analizie oscylogramu poniżej. Podobnież pomiary multimetrem pokazały iż ścieżka ta nie przewodzi.
Na zaprezentowanym oscylogramie widać także detale innego istotnego elementu rami transmisji CAN - bit ACK. Oscyloskop został użyty w trybie jednokanałowym z triggerem generowanym na podstawie sygnału TXD płytki po prawej stronie (tej z przerwaną ścieżką) na pojedynczy bit. Tym pojedynczym bitem jest bit ACK, wygenerowany przez ten układ po odebraniu ramki transmisji. Wszystkie urządzenia otrzymujące ramkę CAN po jej poprawnym odebraniu wysyłają bit ACK. Trwa on trochę dłużej niż normalne bity, co jest wynikiem nadawania go równolegle przez kilka urządzeń. Czynnikami wydłużającymi czas trwania tego impulsu są - opóźnienie wprowadzane przez okablowanie sieci CAN - 5 ns/m; dryft zegarów poszczególnych urządzeń sieci CAN i wyższe napięcie różnicowe w sieci CAN podczas transmitowania tego bitu. Podwyższenie różnicy napięć wynika z faktu że więcej niż jeden układ nadają sygnał do sieci CAN naraz. Jeśli te czynniki przedłużą czas trwania impulsu ACK powyżej pewnego czasu gdzie spodziewany jest on przez nadajnik rami może doprowadzić to do błędów w transmisji.
Drugim przykładem aplikacji powyższej wiedzy do debugowania sieci CAN w której urządzenia działają poprawnie, ale bardzo wolno. Tylko bardzo niskie prędkości transmisji pozwalały na przesłanie kompletnej ramki bez błędów. Podłączenie oscyloskopu do pinu TXD pokazało bardzo małe czasy narastania sygnału w tym miejscu. Wolne narastanie sygnału wprowadzało opóźnienie wynoszące 9,6 μs, co jest równoznaczne 10 bitom w sieci o prędkości 1 Mbps. Od tego momentu wszystko stało się już jasne. Przyczyną takiego zachowania było wykorzystanie wyjścia mikroprocesora z otwartym drenem zostało użyte do sterowania pinem TXD transceivera. Przez to sterowanie tego wejścia było pozbawione silnego sterowania do stanu wysokiego. Podciągnięcie go zewnętrznym opornikiem do zasilania rozwiązało problem. Bez tego opornika tylko wewnętrzne podciągnięcie do zasilania w mikroprocesorze, podciągało lekko ten sygnał do stanu wysokiego, co przy dużym obciążeniu pojemnościowym powodowało tak wielkie czasy narastania.
Źródła:
http://www.ti.com/lit/an/slyt529/slyt529.pdf
Poniższe zdjęcie pokazuje przykładowy system z siecią CAN, który został zdebugowany. W płytce prototypowej po prawej stronie przerwaniu uległa ścieżka z sygnałem CANH, prowadząca do portu wyjściowego z układu. Uszkodzenie to powstało na skutek ciągłego przenoszenia tego systemu. Podczas przenoszenia PCB ocierało się w tym miejscu o nakrętkę śruby montującej płytkę do uchwytu. Ten problem uwidacznia się od razu po analizie oscylogramu poniżej. Podobnież pomiary multimetrem pokazały iż ścieżka ta nie przewodzi.
Na zaprezentowanym oscylogramie widać także detale innego istotnego elementu rami transmisji CAN - bit ACK. Oscyloskop został użyty w trybie jednokanałowym z triggerem generowanym na podstawie sygnału TXD płytki po prawej stronie (tej z przerwaną ścieżką) na pojedynczy bit. Tym pojedynczym bitem jest bit ACK, wygenerowany przez ten układ po odebraniu ramki transmisji. Wszystkie urządzenia otrzymujące ramkę CAN po jej poprawnym odebraniu wysyłają bit ACK. Trwa on trochę dłużej niż normalne bity, co jest wynikiem nadawania go równolegle przez kilka urządzeń. Czynnikami wydłużającymi czas trwania tego impulsu są - opóźnienie wprowadzane przez okablowanie sieci CAN - 5 ns/m; dryft zegarów poszczególnych urządzeń sieci CAN i wyższe napięcie różnicowe w sieci CAN podczas transmitowania tego bitu. Podwyższenie różnicy napięć wynika z faktu że więcej niż jeden układ nadają sygnał do sieci CAN naraz. Jeśli te czynniki przedłużą czas trwania impulsu ACK powyżej pewnego czasu gdzie spodziewany jest on przez nadajnik rami może doprowadzić to do błędów w transmisji.
Drugim przykładem aplikacji powyższej wiedzy do debugowania sieci CAN w której urządzenia działają poprawnie, ale bardzo wolno. Tylko bardzo niskie prędkości transmisji pozwalały na przesłanie kompletnej ramki bez błędów. Podłączenie oscyloskopu do pinu TXD pokazało bardzo małe czasy narastania sygnału w tym miejscu. Wolne narastanie sygnału wprowadzało opóźnienie wynoszące 9,6 μs, co jest równoznaczne 10 bitom w sieci o prędkości 1 Mbps. Od tego momentu wszystko stało się już jasne. Przyczyną takiego zachowania było wykorzystanie wyjścia mikroprocesora z otwartym drenem zostało użyte do sterowania pinem TXD transceivera. Przez to sterowanie tego wejścia było pozbawione silnego sterowania do stanu wysokiego. Podciągnięcie go zewnętrznym opornikiem do zasilania rozwiązało problem. Bez tego opornika tylko wewnętrzne podciągnięcie do zasilania w mikroprocesorze, podciągało lekko ten sygnał do stanu wysokiego, co przy dużym obciążeniu pojemnościowym powodowało tak wielkie czasy narastania.
Źródła:
http://www.ti.com/lit/an/slyt529/slyt529.pdf
Fajne? Ranking DIY
