# DMOC645 Hardware Problem



## ACEVS4US (Jul 21, 2011)

I may be one of the unlucky first to have a hardware problem with the DMOC645. 

August last year I purchased a DMOC645 and Siemens motor combo. I loaded the firmware etc and spun the motor without too many issues. I then put the controller aside and began work on installing the motor into the car. Last week I connected the motor and controller up again hoping to test out the transmission and get some wheels spinning. Of course this is where the problems began.

I connected everything up as before, all the proper connections are there because I'm using the same ampseal wiring harness as I used before (I also checked continuity from my arduino to the controller, all was good). At this point I naturally assumed I had a problem with my Arduino hardware not sending out CAN packets, but no, that checked out as well. So I then tried RS232 communication, but that also didn't work. Now things were becoming concerning! I then try to reflash the firmware with the Kvaser, but when I do this the azure software says "turn ignition on" which basically means CAN comms are down. So basically, no communications at all. I really haven't done anything to cause a working controller to become a non-working controller.

I have opened up the controller to check the ribbon cables are properly seated, especially the one that carries the comms from the ampseal connector to the processor board. I also checked the ribbon for continuity (but not yet for adjacent pin shorts). I have attached a picture of the status LEDs. Two of the bicolour LEDs are shinning red, they are "PWM Enabled" and "Defined". Pretty sure PWM enable related to the drive enable status of the controller, so that should be red until I enable the drive. The "Defined" LED starts off green at power up and then goes red after a couple of seconds. Can anyone come up with some suggestions to help with this (I'll try anything)? I wouldn't rule out even the most obvious things? I'd also be interested in knowing which LED's light up when no firmware is programed onto the DSP. That would at least tell me the DSP is doing something?


----------



## CKidder (Dec 12, 2009)

Fun times! I don't have a DMOC645 handy on the bench right now so I can't look inside a working unit. However, that's an awful lot of lights lit up so I'm going to have to assume that the power works and the device at least is trying to start up. I've programmed quite a few of these DMOCs and they work fine on the bench with just power and canbus so the issue shouldn't be a lack of connections. If you have an oscilloscope you might try looking at the CANH/L signals to see what is going on and how the waveforms look. They should be pretty sharp and have a sensible looking bit time. With a multimeter you could read the voltage from H to L and see if there is one. Resting there should be 0V between those two. Unfortunately that same result would happen if the CAN lines were dead. But, if anything is transmitting then your meter should show some voltage as it'll be seeing a voltage during some of the samples. Make sure that your terminating resistors are intact - remember each end of canbus should have a 120ohm resistor. The DMOC does not include canbus termination. The proper nominal bus resistance is 60 ohms. 

If none of that fixes it I can dig out a DMOC and take a peek. I still have two unprogrammed DMOCs I could look into. Do note, though, that the DMOC does send canbus traffic when it is unprogrammed. So, whether it has been flashed or not you should be able to see canbus traffic when it is powered.


----------



## ACEVS4US (Jul 21, 2011)

Thanks for the reply Collin, much appreciated
I understand you are trying to get rid of those unprogrammed DMOCS. Can you please send me a PM if you're going to sell out of them? - I don't want to be left without one. I obviously want to investigate whether I can fix this one first though, but if my hand is forced I may just have to buy one as a backup. 

I will have a look on the scope this evening, to see whether there is any CAN traffic. My memory is that on power up RS232 status info should be transmitted as well (baud rate 19200 8N1?)? Or do I transmit something to make it talk? 

Worst case scenario (which I think this probably is), I guess the processor could be replaced if:
1) I could remove the encapsulation over it.
2) We could get the firmware back onto it.

There must be someone out there who has the hex file for the firmware (if there is please leak it to me in a PM)? We could then just use the JTAG to upload the firmware/bootloader from a blank processor. Does anyone know anyone who use to work at AZD that might be able to sneak me a hex file? 

Chris


----------



## CKidder (Dec 12, 2009)

Yes, a programmed DMOC will output start up messages shortly after it gets power. So, you should be able to see them on RS232 when it starts up.

Trying to change the processor would probably prove to be quite difficult. It has a conformal coating over it and it looks to be BGA or something. It won't be a good time. Even then, do you have TI TMS jtag equipment? I actually don't. I've got JTAG for a couple of other processor types but not that one. Also, I don't actually know anyone at AZD who might leak the bootloader hex file. So, unfortunately this whole idea seems like a very tough sell.

It would be very odd that a unit that has hardly been used and been left alone would have a bad processor. I suppose it could be possible as electronics have a sort of inverse bell curve for failure. Some fail right away, then it tapers off to nothing for a while as all the bad units already died. Then at the end of life they all start to fail again. So, there is a possibility that it was just plain bad. But, usually companies try to burn in expensive equipment to weed out the early failures as much as possible. The processor and the rest of the sensitive stuff is isolated so you wouldn't think it would be easily damaged by environmental issues. However, I believe I did once accidentally hook up the plus and minus for 12V backwards on a DMOC445 and blew the power board so I'm not convinced that they fully protected everything. You know how expensive a blocking diode on your input is


----------



## electricmini (Oct 21, 2008)

Just a quick thought - the drive_enable pin is connected, isn't it?
This foxed me for a while with my DMOC....


----------



## ACEVS4US (Jul 21, 2011)

Okay, so I've made some really good progress on this. It looks like the processor is probably alright. The problem is certainly with the "Comm_+5V" power supply. This supply has only 1.8 ohms resistance to ground and when I power the board up it reads 0V - so the supply has developed a short. Both CAN and RS232 transceivers are not receiving power. As you can see in the picture attached I have removed the LDO regulator in an attempt to find where the supply is shorted. All the chips are coated in resin encapsulant so I had completely butcher the chip to remove it without damaging the board. 

It turns out the regulator wasn't the cause of the short circuit (when removed the short persists), but it was likely damaged anyway because its output was directly shorted to ground. The next plan of attack is to remove the transceivers one at a time and see if this gets rid of it (they seem likely culprits).

Removing the short shouldn't prove too difficult, it is highly likely one of the transceivers is damaged. 

The next difficulty is that the input to the LDO regulator is only reading 1.47 volts, obviously too low. So there is more damage upstream as well. I'll need to trace this down and fix it as well. The good thing is it looks fixable.

It looks like the input to the LDO regulator may be derived from the power/gate drive board it connects to the ribbon connector at the top of the picture.


----------



## ACEVS4US (Jul 21, 2011)

> Just a quick thought - the drive_enable pin is connected, isn't it?


Thanks for the thought
Yep I've got drive enable connected.

The "drive enable" enables the PWM circuits on the power stage. Comms will still work without this connected.

Chris


----------



## electricmini (Oct 21, 2008)

I wonder what J13 does...

I guess we'll never know - unless someone happens across the original schematics (unlikely now)


----------



## ACEVS4US (Jul 21, 2011)

Okay so I've got it working again!!

I'll attempt to explain what was wrong and how I fixed it.

The root of the problem appeared to be failure of the CAN transceiver. The chip (SN65HVD1050QDRQ1 or similar) had developed a short between it's power supply rails. This in itself is curious because of the level of protection these chips have (15KV ESD protection on all inputs and +/-200V transient protection). It did however certainly die!

The failure of the CAN transceiver caused a cascade of other problems related to the comms power supply. The comms power supply is indeed derived from the Gate drive/Power board. The power board regulates a rectified transformer voltage to +5V. This supply then goes through a ribbon cable to the processor board. The signal is then cleaned up again on the processor board via a common mode choke and an inductor before being post regulated with an ultra low dropout (30mV) +5V regulator. This is then called the +5V_Comm power supply and there is a test point on the processor board for this. This supply is completely isolated from all other power supplies. Digital isolators are used between the CAN and RS232 transceivers and the processor.

Basically the short destroyed the LDO regulator and fused the ground side of the common mode choke. I ended up replacing both digital isolators (as a precaution), both transceivers, the LDO regulator and the common mode choke. I have indicated part numbers and locations on the attached picture.

Hope this will one day help someone else!

Chris


----------

