DRV8840EVM

Hi Jeff,

There are a few quick things to try. After that we will have to do some more research.

Power down the board, disconnect the USB cable, and close the GUI.
Reconnect the USB cable and re-open the GUI. The board does not require power for this experiment.
Try connecting to the EVM by selecting Connect as you have done before.

Let us know if this fixes the problem.

Rick,

Yes I tried that, and the same result is the text box is still red. Status bar says connected and COM4, 9600, N, 8, 1. What can I try next?

Jeff

Hi Jeff,

We will investigate from our side. As long as the MSP430 is powered and blinking, and USB communication to the MSP430 is correct the GUI should work.

You can try another USB cable and uninstalling and re-installing the GUI. After that, it will be difficult to determine the cause.

Hi Jeff,

What version of the GUI are you using? I am using version 1.1 dated February 9 2011.

Once you click Connect and receive the Connected COM4, 9600, N, 8, 1 status at the bottom, the GUI should be communicating with the MSP430.

Any command sent by the GUI should change the status box to <X><X><X> and the color to green.

If it does not, the MSP430, the FTDI USB to UART device, or supporting circuitry is malfunctioning. Since the status LED is blinking, the MSP430 is alive and running code. Is the 3.3V LED also lit?

Rick,

I reinstalled the zip file, t is version 1.1 dated February 9 2011. I tried another USB cable. The 3.3V LED is lit. The Status LED continues to flash once a second. The text box is still red after receiving the Connected COM4, N, 8, 1 status.

The MSP430 State does not change. I am probing with a scope and the I4 bit is not staying pulled high. Every 7.5 usec it is indeterminate for 1 usec.

The last I remember running was the PHASE pin at 10% DC.

Jeff 

Hi Rick,

We are experiencing a new issue with the DRV8840 expansion board.

Our output 1 is held to VM despite digital control inputs.

The chip knows that Output 1's transistor is continually closed to VM because it outputs a Fault Low whenever we try to set Phase to 0 (which should make Output 2 High). This goes away upon reset.

So it looks like the DRV8840 chip can read its digital inputs and output its Fault bit accordingly, but still Output 1's output is held high despite changing phase, enable, sleep, the current bits, or any other digital input.

Have you seen this phenomena before? Any common reasons for it?

Thanks,

Jeremy

Hi Jeremy,

No, I have not seen this phenomena before.

Can you provide a basic schematic of your load?
Do you have the load connected? If the load is connected, does the device function properly without the load?
What are the other input values prior to setting PHASE to 0?

We have tried this with a 4.4ohm inductive load and a 9.9 Mohm resistive load.

The chip is faulting whenever Out 2 gets pulled up to the same voltage as Out 1.

What happens:

1. With the 9.9Mohm resistive load:
- PH:1, EN:1: It looks like the chip manages to pull Out2 Low, as it should. No fault.
-EN:0, any PH: The chip fails to pull Out2 Low and Out2 is pulled up to the same voltage as Out1. Fault

2. With the 4.4ohm inductive load
-PH:1,EN:1 The chip fails to pull Out2 Low and Out2 is pulled up to the same voltage as Out1. Fault
-EN:0, any PH: The chip fails to pull Out2 Low and Out2 is pulled up to the same voltage as Out1. Fault

So the chip seems to be faulting when it should, i.e. when 2 gets pulled up to the same voltage as 1 (and we effectively short circuit the system). this happens with any (at least 1) current bit selected.

The problems with the chip seem to be:
a. Fails to pull Out1 Low, ever
b. Fails to pull Out2 Low at PH=1, EN=1 if there is too small a resistance between Out2 and Out1
c. Fails to pull Out2 Low at EN = 0 regardless of resistance between Out2 and Out1

Our logic level inputs hover around 3.3V.

Upon disconnecting and reconnecting power to the board, Out2 stopped getting pulled up to Out1 but we'd still see a fault on the same previous conditions.

Thanks,

Jeremy

Hi Jeremy,

From your description, it appears you have the DECAY pin set to 0. Is that correct?

Regardless of how the DECAY pin is set, you should not have a fault occur if you have a 9.9M resistive load. It appears the device may have been damaged. Have you looked at the output with a scope during the few microseconds after the inputs have been changed? This could help with further debug, although changing the device may be the best approach.

Yes, the decay pin was set to 0 for slow decay.

We can't see a difference now, even in the microsecond range, with changing inputs. Is it possible that by switching off the device after running it we experienced a voltage spike that may have damaged the chip? It was my understanding that the h-bridge should be able to handle a voltage spike. Could a flyback diode help in this regard, still?

Thanks,

Jeremy

Hi Jeremy,

The device is designed to handle voltage spikes within the datasheet absolute maximum and minimum values.
From the description, the device may have been damaged. If you have the ability to replace it, I suggest you order a few samples of the device in case.

What was the VM voltage used originally?