L293D Enable2 Will not go low

L293D Datasheet

This problem has been driving me nuts. I'm using an Arduino Nano to control two motorized ball valves with an L293D driver. The Arduino receives feedback from flow sensors to adjust the rate of flow. When the flow rate is in the correct range it sets the Enable pin on the L293D for the respective valve LOW to stop any more movement. One of the valves is functioning as intended, but the other will not disable. I checked with an oscilloscope and saw that ENABLE2, which is connected to PIN 9 on the Arduino, does not go below 2 volts when pulled low. It does go to 5 volts when pulled high.

When I test the Nano on its own PIN 9 does go to ground when pulled low.

When I remove the Nano from the circuit Enable 2 on the L293D is still at around 2 volts.

I soldered in a DIP socket so I could pull the L293D and test the circuit. With the L293D pulled the circuit tests out fine. PIN 9 goes to ground with no issue

So I believe I have determined that the L293D itself is providing the 2 volts on Enable 2. When the L293D is removed everything tests out ok.

I have tried multiple Nano boards. I have tried multiple L293D drivers. Always the same result. The code for this project is quite lengthy and in multiple modules, but I am confident it is not a code issue, as the anomaly is still there when the Nano is removed entirely.

Is the L293D in a module? Maybe there is a fault in the module board. It wouldn't necessarily be on that pin.

It is not in a module. Standard 16 pin DIP package.

What is this thing? A custom PCB?

1 Like

I'm building an automated brewing system. It is on a custom PCB.

Please follow the forum guidelines for posting a question, and post all the information you have so we can evaluate it properly.

Can you test these drivers also in a different environment? As a last resort I suspect that you killed all test candidates by some bug in your PCB (missing GND or Vcc, wrong chip orientation...) or 12V applied prior to 5V.

Checking some PCB tracks:

FCV1 EN: Nano pin 13 incorrectly goes to Y5 output of U5 before it incorrectly ends up at pin 15 of the L293D (should be pin 9, but the part orientation is 180 deg). Note that you shouldn't use an unused pin as a via (especially if its an output - which explains the 2V when low problem).

FCV1 EN: I see no PCB track at Nano pin 12.

In whatever PCB software you're using, you'll need to go through its rules for valid net names (are spaces allowed???) and run an electrical rules inspection to check for errors.

I suspect other errors exist.

Did you build and try a prototype of your project before going tp PCB?

Thanks.. Tom... :grinning: :+1: :coffee: :australia:

Thanks for checking it out. I've posted a picture of the PCB with the ground plane removed, that should make it easier to see the traces on the bottom of the board. Everything on FCV1 EN is working properly. FCV2 EN is also connected to the L293D as I can see the pin go high when it is supposed to.

The footprint for the Nano doesn't include D11 or D12 on the schematic for some reason. I guess I didn't think anything of it. But they are unused.

I will test the chips that I was using to see if they are dead in something else.

I'm using EasyEDA. I'm by no means an expert so I'm sure it looks sloppy, but everything works so far except this one pin. Somewhere along the way in testing this I managed to short out my hex inverter, so I'm going to put together a new board and see if it is any better. I appreciate you taking the time to help.

I did not. I tested all the individual elements separately before putting it all together on the PCB. The PCBs are pretty cheap so I'm not too concerned with failed boards.


That really isn't the point. A prototype is usually easier to troubleshoot and modify. PCB geometry and features can easily hide mistakes that would be much more obvious on proto.

Sometimes you have no choice, for example if the signal frequencies are very high, so the leads have to be very short and well shielded and/or counterpoised by a ground plane.

Also, your style of schematic is almost useless for reading, nothing but net nodes coming out of every component. A useful schematic connects the lines so you can see visually where everything is connected. It's possible you would have spotted some mistakes visually if you had done this.

Hi, @aarg

YES YES YES.... :+1: :+1: :+1: :+1: :+1:

In this case @mjstreet86, you best bet now is to sit down with pen(cil) and paper and reverse engineer your PCB, then compare the schematics, @dlloyd has basically done this to point out some of the PCB errors.

Do you have a DMM?
If so use it to check your PCB.

Tom.... :grinning: :+1: :coffee: :australia:

Ok. I've added in the circuit lines and reduced the number of net labels. Anything with a net label is now either voltage supply, ground, or going straight to a screw terminal. I hope this helps. I will work on testing the other things you have mentioned this weekend.

Thanks again.



PLEASE do not go back and do a MAJOR edit to previous posts.
The flow of this thread has now been ruined.
You should have posted your new schematic in a NEW post.

Have you gone over your PCB with a DMM and checked every track connection around the 293?

Tom.... :grinning: :+1: :coffee: :australia:

Totally agree. OP did a reasonable job, though...

I found the issue. After checking all of the hardware extensively I finally concluded that Pin 9 was not going low, but instead going to a high impedance state, and the Enable 2 pin on the L293D just floats at around 2 volts on its own.

digitalWrite on an input pin will enable the internal pullup, which is why I could see the pin still going HIGH as expected.

I looked through the code and did not find any errors. Pin 9 was being set as an output using the pinMode function, it just wasn't changing the bit in the register. I decided to print the DDRB register to the serial monitor before and after the calling pinMode and determined that the function wasn't working for DDRB. Curiously, it was setting the bit for Pin 13 as expected. I am using VS Code and PlatformIO to write the code, so maybe there's some issue within that framework.

The solution was to set the DDRB register directly. After doing that all is working as intended. I haven't dug any further into figuring out why pinMode is not working.

PinMode() works just perfectly. There is a bug in your code.

Setting Pin A7 as Input was changing bits in the DDRB register. I was unaware of this behavior. I've removed that part of code and it is working now. Thank you for your help.

1 Like

Great, you found out that A6 and A7 can't function as digital pins.