I2C errors in 2.02, using DWC 2.0.0 RC3



  • Some good news, some bad. When I do I get I2C errors now the printer performs a few moves, stops, and does a few more moves. Previously it would only do one move.

    Unfortunately I reset it before thinking to grab a screenshot of M122. Here's a recreation. I'll get the real thing next time it happens.

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
    Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
    Used output buffers: 3 of 20 (14 max)
    === RTOS ===
    Static ram: 25524
    Dynamic ram: 98292 of which 0 recycled
    Exception stack ram used: 352
    Never used ram: 6904
    Tasks: NETWORK(ready,544) HEAT(blocked,1232) MAIN(running,3844) IDLE(ready,200)
    Owned mutexes:
    === Platform ===
    Last reset 00:04:18 ago, cause: power up
    Last software reset at 2019-01-15 15:38, reason: User, spinning module GCodes, available RAM 4216 bytes (slot 2)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 32.7, current 32.9, max 33.5
    Supply voltage: min 11.6, current 11.7, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max not available
    Driver 8: standstill, SG min/max not available
    Driver 9: standstill, SG min/max not available
    Date/time: 2019-01-17 15:04:48
    Cache data hit count 645630772
    Slowest loop: 94.64ms; fastest: 0.08ms
    I2C nak errors 0, send timeouts 12345, receive timeouts 0, finishTimeouts 12345 (something similar to this)
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 25, completed moves: 25
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.0
    Heater 1 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 0
    Stack records: 1 allocated, 0 in use
    Movement lock held by file
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is doing "M190 S65 " in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 11.51ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 2 of 8
    Interface state 5, link 100Mbps full duplex

    The next time it happens I'll be sure to grab the real M122 output. It has been a while since I posted, but we've been through all of the usual troubleshooting as far as I know. I also saw that the I2C communication was redone for 2.02, which is why I am bringing this up.



  • It finally happened again after a few hours of testing.

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
    Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
    Used output buffers: 1 of 20 (17 max)
    === RTOS ===
    Static ram: 25524
    Dynamic ram: 98292 of which 0 recycled
    Exception stack ram used: 416
    Never used ram: 6840
    Tasks: NETWORK(ready,544) HEAT(blocked,848) MAIN(running,3844) IDLE(ready,200)
    Owned mutexes:
    === Platform ===
    Last reset 02:23:39 ago, cause: power up
    Last software reset at 2019-01-15 15:38, reason: User, spinning module GCodes, available RAM 4216 bytes (slot 2)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 8
    Free file entries: 8
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 41.0ms, max retries 0
    MCU temperature: min 33.1, current 33.6, max 35.0
    Supply voltage: min 11.4, current 12.3, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max 7/594
    Driver 1: standstill, SG min/max 0/659
    Driver 2: standstill, SG min/max 10/602
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max 0/492
    Driver 7: ok, SG min/max 0/0
    Driver 8: standstill, SG min/max 0/0
    Driver 9: standstill, SG min/max not available
    Date/time: 2019-01-17 17:24:08
    Cache data hit count 4294967295
    Slowest loop: 248.05ms; fastest: 0.08ms
    I2C nak errors 0, send timeouts 28776, receive timeouts 0, finishTimeouts 28776
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 239, MinFreeDm: 104, MaxWait: 1342116ms, Underruns: 0, 0
    Scheduled moves: 64, completed moves: 63
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.0
    Heater 1 is on, I-accum = 0.9
    === GCodes ===
    Segments left: 0
    Stack records: 1 allocated, 1 in use
    Movement lock held by file
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 1 5
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 87.35ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8
    Interface state 5, link 100Mbps full duplex



  • We are discussing it also over here:
    https://forum.duet3d.com/topic/7269/duet-sometimes-really-slow-i2c-error-or/33
    A suggestion is to put some resistors on the duex5 header, but I haven't tried it yet.


Log in to reply