DC2026C and DC2591

Hi All,

I have two of each of these boards and I'm having trouble with one of the DC2026 (Linduino). I'll just go through the debugging I've done. I've tested both Linduinos with:

1) Both DC2591

2) Both USB cables

3) Both power cables

4) Using both the Arduino IDE and MatLab

5) Both with only one Linduino connected, and with both Linduinos connected

One of the Linduinos works under all conditions, the other one does not work under any condition. Normally I would say that it's probably dead, however if I connect it as per its datasheet, I get the "hello" message in the Arduino IDE. However if I then send the command "CH0:ENA" (from the datasheet for the DC2591), I get no response. If I then give the command "CH0:VOL 0.5" nothing happens. Additionally, nothing happens if I give the command "*IDN?". If I do the same thing with the working Linduino, it operates as expected.

Can anyone help me with this?

Thank you.

UPDATE____________________________________________________________________

I probed the I2C signals for the device that works and the device that doesn't work. I noticed that on power-up, there is an I2C signal that the Linduino sends out (presumably to determine what's connected to it). I get that on the Linduino that works, regardless of whether the DC2591 is connected or not. I do not get that on the Linduino that doesn't work. Is it possible to flash the firmware, or did I just get a lemon?



UPDATE____________________________________________________________________ I probed the I2C signals for the device that works and the device that doesn't work. I noticed that on power-up, there is an I2C signal that the Linduino sends out (presumably to determine what's connected to it). I get that on the Linduino that works, regardless of whether the DC2591 is connected or not. I do not get that on the Linduino that doesn't work. Is it possible to flash the firmware, or did I just get a lemon?
[edited by: AR_MacDonald at 7:57 PM (GMT -4) on 29 May 2021]
Parents
  • 0
    •  Analog Employees 
    on May 30, 2021 1:12 PM

    Hi AR_MacDonald,

    On the firmware - that's the main question - how did you flash the firmware on the unit that works? The process is described in the demo manual starting on page 5. Once you've installed the Arduino IDE, downloaded the sketchbook, and aimed the IDE at the sketchbook, load the EasySMU_Run sketch into the Linduino.

    The behavior you're describing, and the "hello" message, are consistent with the default firmware that ships with the Linduino, which is a command interpreter that works with the QuikEval program and compatible eval boards (which the DC2591 is NO. You must write the EasySMU firmware before it will work.

    I do notice that the Linduino manual  still points to a zip file for the sketchbook - it has since been moved to Github: https://github.com/analogdevicesinc/Linduino 

    Also - while debugging this situation, try programming the unit that does NOT work first, and don't do anything to the one that does, so you have a working basis for comparison.

    I don't have an EasySMU or screen, but I was able to verify and upload the sketch to a linduino, and get an error message (because there's no DC2591 attached):

    -Mark

  • Hi Mark,

    When I send a command to the Linduino that isn't working, regardless of whether the EasySMU is connected or not, I do not get any response.

    I did a bit more electronics debugging, and I believe that the issue is a hardware one - I'll elaborate.

    On the working Linduino, I noticed that on power-on or reset it sends a command over the TWI, presumably some sort of handshake with whatever development board is connected to it. On the Linduino, this does not happen.

    Moreover, on the Linduino that is not working, I noticed that the SCK line (pin 17 on the microcontroller) is being held low, which would seem to indicate that something is sinking current. This could either be the microcontroller, U12 or Q1. U12 is a buffer and the input should be high impedance, similarly with the gate for Q1, so I believe that the microcontroller is malfunctioning.

    I do not know whether the TWI interface is malfunctioning, or whether the SCK line being driven low is somehow "hogging" resources and preventing the TWI from operating. The only thing I do know is that the USART is working, since I still get the "hello" message.

    I could try pulling off U12 and Q1, since we don't need that functionality. If that doesn't work, I could also pull off R54 and leave SCK floating, which may be better if it's sinking current, but I think we just got a lemon.

    Thank you!

  • 0
    •  Analog Employees 
    on May 30, 2021 3:29 PM in reply to AR_MacDonald

    You just reminded me of something - can you check the board revision? It should be in the copper layer on the reverse side of the board. There was a subtle issue with early revisions - the NC7WZ125 buffers are a little too perfect - the have very strong, fast output drive, and a floating input will draw excessive shoot-through current. When the processor is in reset, the early rev boards would indeed have those inputs floating, and some Linduinos would reset themselves occasionally. We added pullups / pulldowns and source-termination resistors to fix this.

    Also try a shorter USB cable, and ideally connected to a powered hub. This might help narrow down the cause.

    Also - did you check the baud rate? The default firmware (DC590 emulator), transmits "hello" at 115200 baud, but the EasySMU firmware operates at 9600 baud.

    -Mark

  • Both of the Linduinos I have are Rev. 1, but I noticed that one of the inductors, and one of the capacitors are different between them. The serial number of the working Linduino is D1114632-0508, and the serial number of the malfunctioning Linduino is: 045863-0248.

    I've tried using a 3' cable, which is the shortest I have available, and it does not work with that cable.

    I know that the "hello" message transmits at 115200 baud, but the EasySMU operates at 9600 baud, and I've tried both. Since the problem is not related to the EasySMU (no handshake at power up), I've kept it at 115200 baud.

  • 0
    •  Analog Employees 
    on May 31, 2021 2:28 PM in reply to AR_MacDonald

    A couple of points - "

    On the working Linduino, I noticed that on power-on or reset it sends a command over the TWI, presumably some sort of handshake with whatever development board is connected to it. On the Linduino, this does not happen.

    This is expected with the default firmware - in fact, if you send an upper-case 'I' you should see some activity on the I2C/TWI bus. (See line 240 in the linked sketch.)

    Moreover, on the Linduino that is not working, I noticed that the SCK line (pin 17 on the microcontroller) is being held low, which would seem to indicate that something is sinking current.

    This is also expected - the Linduino / DC590 emulator defaults to SPI interface enabled, mode 0. So I don't think this is the issue.

    Have you been able to confirm/deny that you can flash the non-functional Linduino with anything? Try the MyBlink sketch, which should blink the LED (which happens to be the SCK line). If that works - there is an I2C address scanner that should show no devices with the DC2591 disconnected, and the appropriate addresses when it is installed.

    If you can't upload - maybe you did get a lemon - where did you purchase the board from?

    -Mark

  • Hi Mark,

    Since the SCK line is being driven low, the SCK led is continuously on.

    I tried uploading the sketch you provided and it failed. This is the error message I got:

    Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Uno"

    avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
    Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
    Copyright (c) 2007-2014 Joerg Wunsch

    System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

    Using Port : COM29
    Using Programmer : arduino
    Overriding Baud Rate : 115200
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x96
    avrdude: stk500_recv(): programmer is not responding
    avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x96

    avrdude done. Thank you.

    Problem uploading to board. See www.arduino.cc/.../Troubleshooting for suggestions.

    I think it's dead.

    Thanks for your help!

  • 0
    •  Analog Employees 
    on Jun 1, 2021 2:12 PM in reply to AR_MacDonald

    Let's check one more thing (maybe two) - There is a little copper trace labeled "jumper" on the reverse side of the board - can you verify that it is intact? (It will be if the board came from stock, through an authorized distributor.) The idea with this jumper is that IF you want to use one of the various debug tools through the 6-pin ISP header, you can cut that trace and do so. But it must be intact in order to use the normal Arduino IDE (AVRDude) programmer. IF the trace is cut, solder a wire (or 2mm jumper if you have one) from JP2, pins 1-2.

    The fact that you get the hello message implies that the processor is NOT in reset (R18 intact), but the fact that you can't program it implies that somehow the reset signal is not getting through. Also inspect C21 for cracks, cold solder, anything else suspicious.

    -Mark

Reply
  • 0
    •  Analog Employees 
    on Jun 1, 2021 2:12 PM in reply to AR_MacDonald

    Let's check one more thing (maybe two) - There is a little copper trace labeled "jumper" on the reverse side of the board - can you verify that it is intact? (It will be if the board came from stock, through an authorized distributor.) The idea with this jumper is that IF you want to use one of the various debug tools through the 6-pin ISP header, you can cut that trace and do so. But it must be intact in order to use the normal Arduino IDE (AVRDude) programmer. IF the trace is cut, solder a wire (or 2mm jumper if you have one) from JP2, pins 1-2.

    The fact that you get the hello message implies that the processor is NOT in reset (R18 intact), but the fact that you can't program it implies that somehow the reset signal is not getting through. Also inspect C21 for cracks, cold solder, anything else suspicious.

    -Mark

Children