Weird issue PanelDue. I think it has a bad SB diode. Ideas?

  • So DuetWiFi v1.02 (FW 1.20)+ PanelDue 3.0 (FW 1.17) + PT100 module were working fine in test setup. After mounting board in 3DP case PanelDue is having problems communicating to DuetWiFi.

    Yesterday I did the following:

    • Confirmed both are set to 57600 > Did not fix problem
    • Swapped out with different cables > Did not fix problem
    • Disconnected Steppers, PT100 Sensors, Estop SWs, Fans, LEDs (on PWM FAN Port 2), Heaters > Did not fix problem
    • Removed electronics from case
    • Tested again with various cables between DuetWiFi and PanelDue (everything else disconnected) > Did not fix problem
    • Re-flashed PanelDue FW with Bossa > Did not fix problem
    • Unplugged power for the night

    This morning:

    • Plugged in power

    It worked momentarily. Enough for it to connect and switch to Idle. I then clicked 'Console' button on PanelDue and it showed:
    WiFi module started
    WiFi module is connected to access point RogueOne: IP Address

    I then entered M115 in PanelDue console and no response.

    So here are my thoughts. Either something in the DuetWiFi startup is somehow disabling or messing up communication to/from the Panel OR maybe there is a failing electronic component on one of the boards which upon having the electronics be cold for hours and doing a cold startup works briefly, but then comms stop working. Accessing WiFi/Web console works fine. Via this interface, I am able to move motors, read temp sensors, set temp on nozzle or bed, change speed of fans or dim LEDs on FAN PWM P2. Estops work fine.. Just the PanelDue can not connect. I checked out PCB schematics for both boards and was testing components on the PanelDue board. Din/Dout 2.2k resistors check out fine, however I am not sure the SB Diode (BAT54C) is working properly. I do not have much experience with SB Diodes. I checked the diode from common cathode to anode and surprisingly it was not zero. In fact it was 1.9. I checked the reverse from the anodes to cathode and meter showed .246.

    Does the SB Diode seem to be shot or ..?
    any help would be appreciated.

    Best regards,

  • administrators

    I think this is due to a bug in PanelDueFirmware, because I have had a similar problem recently, including today. What I found is that some commands display the correct response and others display no response. M115 and M114 didn't work, but M119 did.

    I have a new beta of PanelDueFirmware under development, which I may be able to release this evening, in which I think the problem is fixed.

  • Hi David, thanks for the fast response. Unfortunately, it is not responding to any commands from the PanelDue. Now just is stuck at 'Connecting'. I'm thinking of hooking up a USB to TTL to computer and connecting Din/out ports to that with 3.3/5V level shifter and just having PC listen on comm coming out of PanelDue. Or maybe connecting PC terminal via USB>TTL (3.3) to DuetWiFi and seeing if I can talk to it.

    BTW - I'm a serious fan of your work. My background is CompEng/Sci. It did make me laugh a bit that PanelDue PCB is in Eagle, whilst DuetWiFi is in KiCad 😛 My fun with 3DP is hobby- not work related. I do have Atmel Studio with Atmel ICE. I could probably import your code into AS7 and run in in HW Debug to see what the heck is going on with my boards. Right now my gut is telling me it is probably that SB Diode.

    I'll look around for any debugging / t-shooting stuff you may have in the forums. This may be a bit deep for others..

  • administrators

    If you connect a PC to your Duet via USB and send M111 S1 P3, then all received GCodes will be echoed to the PC. Any that are prefixed "aux" come from PanelDue.

    I have never known that diode to fail. OTOH we do see occasional instances of pins of the ATSAM microcontroller not being adequately soldered to the PCB. However, by far the most common cause of communications failures is bad crimp connections in the cable.

    HTH David

  • David,
    Thanks for the TIP. LOL.. I did the M111 command, but had designated P15. P3 works much better 🙂

    So I uploaded new firmware and still the same. I then left it powered off for 4 hours and I hooked up Saleae Logic Pro analyzer. Upon power-on - it worked perfectly and I captured the data. I was even able to do a M115 and get back that data. So then powered everything off and on again.. and then the logic analyzer captured tons of framing errors and PanelDue upper right was stuck on "Connecting". I ordered replacement SB Diodes which will be arriving Monday. Hopefully that'll do the trick.

    Funny thing is.. I forgot I had the Logic Analyzer. Let's just say it's been a long week 🙂 I also checked the pins around the Atmel SAM chips and they appeared to be ok. I may hit those pin areas with an clean tipped iron this weekend. Who knows..


  • administrators

    Were the framing errors in the data on the PanelDue DOUT pin, or on the DIN pin?

    If you let me know which size screen you have, I'll do you a firmware build from the latest unreleased source code.

  • LOL - I should have noted that, before unplugged and put away the analyzer. I really want to redo the testing but not sure I have time today to work on it. I have stuff to do with wife & kids. One extra thing I did notice was that when it does work from being off for awhile, the display goes in sequence of "Starting Up", to "Connecting", then to "Idle". Then it seems to work for like a minute before something goes wrong and stops communicating. Also.. after unplugging it from that state or doing a reset. I noticed the display goes straight to "Connecting" and seems to skip "Starting Up". idk. maybe the comm lines need a reset or something. David - I greatly appreciate your help in this, but to be honest I feel a bit lazy. I can probably import your firmware code and run code in HW debug mode and see what is going on myself and just report back. I was able to get Marlin imported into AS7 and do HW debug with that with a RAMPS 1.4 board.. I only have one Atmel-ICE so could only do testing from PanelDue or DuetWiFi at a time. Would be neat to have both setup and running at same time 🙂 I'll keep you posted and thanks for such great work!


  • administrators

    I plan to release a new PanelDue firmware beta tomorrow, so please try that one. I suspect that the issue you are seeing is caused by a firmware bug.

    PanelDue doesn't always see the "Starting up" state of the Duet when it connects.

  • Hi David. So this time I connected 4 probes.

    Probe 0 @ PanelDue CONN_SD Din (was easy to connect probe here)
    Probe 1 @ PanelDue CONN_SD Dout (same as above)
    Probe 2 @ DuetWiFi CONN_SD Pin10 - UTXD0 (aka Din of Panel)
    Probe 3 @ DuetWiFi CONN_SD Pin09 - URXD0 (aka Dout of Panel)

    Upon cold boot, first communication started at 1.32s and was from panel. ~7.7ms later, Duet responded.. and they then communicated back and forth every 1s. First framing error occurred 52.8 seconds from power-on. After that framing errors were prevalent every second or so. Framing errors only showed on probe 0 & 3 which are the Dout. So from my standpoint data is corrupt before it reaches the SAM chip on the DuetWiFi board.

    I have 2 good data captures with Saleae Logic. 1st one is 4MB and 2nd one is 13MB. First session shows everything working as expected up until that 52.8s point. If you want, I can send you the files. Download of Saleae Logic is free and will work in simulation mode if you don't have the analzer probe, however you can open the capture data files and check out the data yourself.

    So IMHO I think the culprit is either that SB Diode or the SAM chip on the PanelDue board. I'm out of time now, but I could put older firmware back on the boards to see if something in new firmware is causing this. PM me if you would like for me to email or upload those capture files.

    Also, I have an order of SB Diodes arriving tomorrow, so I intend on doing a replacement sometime tomorrow.

    Best regards,

  • Ah - just saw your last post. Will hold off on the SB diode replacement until I try out your new beta code.

    Many thanks!

  • administrators

    A framing error suggests to me that the ATSAM is no longer transmitting correctly. Assuming you have set your logic analyser to the correct parameters (57600 baud, 1 stop bit, no parity bit) that suggests to me a firmware error or a faulty microcontroller.

  • Probe settings confirmed. 57600, 1 stop bit, no parity. Also- you had asked what screen size I had. That would be 4.3".

    I am thinking it's a bad chip and not firmware. But- It may be a "it depends". Some SAM chips have one HW SPI port whereas others may need to be setup as SW. idk.. just thinking aloud.

  • administrators

    If you are brave, you can try the binary here: I haven't tested it, but the 5" build from the same source code seems to work properly so far.

  • AH- that's not brave! Brave is what may come next.. SMD rework 🙂 I did try that binary and still a no-go 😞 . Going to try that SB Diode next and if that doesn't fix it.. then I'll order a few ATSAM4S4BA chips and.. see how it goes.

    Keep you posted.

  • administrators

    What happened when you tried the new binary: did it not work at all, or work but had the same issue?

    The PanelDue board will work without that diode present. Its main purpose is to provide compatibility with 5V systems by limiting the voltage that can appear on the pins of the ATSAM.

  • I figured it was for that. Hmm.. I could setup some of those probes of Logic Analyzer to Analog mode an analyze voltage. Ah - I just checked the DuetWiFi. It doesn't have any protection. The DuetWiFi's URXD0 and UTXD0 pins plugs directly to pin 75 and 66 of the ATSAM4E8E. So in theory.. I could remote the diode and the 2.2K resistors on the PanelDue board. I just have to bridge over where the resistors were.

  • David - truly puzzling. I left the display disconnected for several days as I worked on other parts of the build. Today I reconnected it for cable length sizing, etc.. and it just works. Typically it would stop working after coming up on a minute of start-up, however it has been on for at least 10 mins and counting. For the record - running v1.21RC1 on DuetWiFi and 1.20b2 on DuePanel.

    I'm trading in my CmpEn/Sci degree and going back for a degree voodoo/witch doctor.


  • @ddt154:

    I'm trading in my CmpEn/Sci degree and going back for a degree voodoo/witch doctor.

    Many would say they are already one and the same.

  • LOL disregard. Stopped working a second ago.

    It apparently just does not like me and is messing with me.

    Will keep you updated. Should be received new PanelDue board in a week.


  • administrators

    If the framing errors are on the PanelDue data out pin, then likely causes are:

    1. Intermittent short between that data out pin and something else, in the cable or at the Duet;

    2. The pin on the MCU that generates data out is not properly soldered down to the pad, or has a minute solder bridge to an adjacent pin.

    I guess there is also the possibility of the crystal oscillator on the PanelDue not running smoothly.

  • interesting - I discovered panel can receive data from Duet. Using WiFi/Web interface I did a print and noticed on the panel that it is getting print status. Ie Temperature readings. But yet on the Panel, it shows I have 4x extruders, but on DuetWiFi.. it is programmed for 1. I'm going to hit the pins with soldering iron.. We'll see if that makes a difference.


  • administrators

    Another way to test data reception by the Duet is to use M117 or M300 commands.

  • Status Update: fixed

    So hit the R4 and R5 2k2 resistors, D3 sb diode, and output pins with soldering iron. Worked for awhile and then stopped transmitting again, like before. I then removed these resistors and diode and then bridged over where the 2k2 resistors were and voila, PanelDue is working.

    So I tested the 2k2 resistors and they are ok, however SB diode seems to be the culprit in this case.

    I'll keep you posted if this arises again.
    Many thanks for your help

Log in to reply