SparkFun Forums

[marus]

Hi,

I've been working on a design for a board for a simple 2WD robot; It's a pretty simple design using an STM32F103C8 microcontroller, two TI DRV8830 for driving the motors, up to four HC-SR04 Ultrasonic sensors to detect obstacles (multiplexed through a 74HC4052 chip and level shifted through a TXB0104), with a socket for an Synapse SNAP RF200 module for wireless communication. The SNAP module is also wired to to be able to control the STM32s boot0, boot1 and nReset lines so that I should theoretically be able to re-program the main microcontroller wirelessly (although I haven't actually tested doing this in the real world yet with an STM32).

It seems to pass my interpretation of the design rules for places like seeedstudio, iteadstudio, etc., (although I'm using DesignSpark PCB and not Eagle so that assumes that I've correctly translated their rules into DesignSpark); but any feedback on what I've likely done wrong, might have done ok, and possibly did well would be greatly appreciated.

Schematics and Gerbers are available at the links below (if there is a better format for these let me know and I'll try to convert to that format):

Schematic PDF: https://www.dropbox.com/s/2dox44ayqd0ow ... ematic.pdf
Gerbers: https://www.dropbox.com/s/v2hegnsfkzay6ym/Gerbers.zip

[viskr]

You are going to need much more bypass capacitors. I see none on the incoming voltage source.

Also trying to power the motor drivers and the micro from the same supply WILL cause you no end of grief. Motor will inject lots of noise into the power and your micro will not be very friendly to that.

Most designs will separate the micro supply from the motor supply. Also most of the time the motors will be connected directly to the input power, which is typically a battery. There is no sense in wasting current going through a linear regulator before it goes into the motor.

While you should be able to program wirelessly, that should not be the only method to do it, otherwise you might find yourself with a brick. It would be good to add a standard 6 pin connector so you can use one of SparkFuns USB/serial breakout boards. That will also allow you to eavesdrop on the wireless communication during debug.

[marus]

Where there any places other than the input on the voltage regulators that were missing bypass caps?

It shouldn't be too hard to separate the motor supply so that it directly coming from the main power connector instead of through the voltage regulator the micro is on. Although I will probably have to look for different voltage regulators with a lower dropout as the DRV8830s have a max recommended Vcc of 6.8; can't think of much that would give me an input between 6v and 6.8v (5 fully charged NiCads would give exactly 6v, but I they seem to drop to below 6v fairly rapidly in my experience).

As for another method to program there is already an SWD connector on the right hand side so that I can program and debug using the ST-LinkV2 built into some of my STM32 discovery boards; although breaking out the second UART to a header that I can hook up directly to the computer isn't a bad idea; although it wouldn't be used for programming.

Thanks for the suggestions.

[viskr]

1117 voltage regulators are designed to use a minimum 4.7 uF input AND output caps which should be close to the regulator. And they really should be larger

Depending on your battery will drive the motor/supply consideration. You might also Li types which have a much flatter charge/discharge voltage curve. You can run from a single battery and then boost the Vbat to 5V with a switching regulator (if you are only building one consider one of the pre-packaged units).

When you start piling up batteries it gets harder to charge them. The 8830 supports 2.75 to 6.8V. It really depends on the motors you are thinking of.

[FLOWMEET]

In the schematic I like put bypass cap near from target device, so I have a reference every time I lock it, so I like add some tags in the schematic like:

1. This route shorter, for a a couple of AGND for example
2. G = R1/R2, thermal dependent so R1/R2 closer,,,


don't abuse but some of comments are good



Best regards...
www.flowmeet.com

[marus]

So I think what my best option will be is to do off-board regulation to 5v which will be used as input to this board, how exactly I get that 5v I can determine later. The 5v input would directly power the motor controllers and ultrasonic subsection, while the 3.3v liner regulator could remain to power the micro. I would of course need to fix the bypass caps on the 3.3v regulator and add a level shifter for the i2c bus for the motor controllers; probably just use another TXB0104 (I could of course use an 0102, but then I have to purchase a separate part). Were there any remaining issues that you saw with the schematic that wouldn't be covered by these changes?

I think I may also add the places on the board for an external crystal for the STM32; it doesn't strictly require an external crystal as it can use its own internal clock source, but the external one is generally more accurate and that might be necessary to get accurate readings from the ultrasonic sensors.

I'm not quite sure I understand Flowmeet's comments; in the schematic the bypass caps for all ICs other than the STM32 are directly connected (and therefore quite close) and the caps for the STM32 are clustered together slightly above the block for the STM32.

If you had a look at the Gerber's did you see any issues with the general layout and routing approach?

Thanks for all your feedback viskr, you're the kind of person that makes this community great.

[viskr]

The STM32 can handle 5V i2c, which is an open drain bus anyway, so it is a function of the pullup resistors.

I did take a peak at the gerbers. I would split the GND pour so that the GND for the motor controllers is isolated from the GND for the rest of the circuitry. You want to tie those 2 GNDs together at only 1 point, usually the GND power input.

I haven't used the HC-SR04, one spec I saw said it was TTL levels, which means the STM32 should be able to drive it directly. Someone else here may be able to answer that. TTL levels means 0 to 2.6V, but when translating Chinese spec sheets who knows. You could use a 74HCT4052 and get rid of the bus translator if the HC-SR04 does do TTL, if it doesn't you only need to translate the trigger input before the 4052.

[viskr]

PS you want to GND the enable on the 4052

[marus]

Didn't think about the fact that the i2c pins are actually 5v tolerant ones, so the level shifter would not be necessary there. The ones being used for the ultrasonic components are not 5v tolerant pins. While you can trigger the HC-SR04 with a 3.3v apparently (I haven't tried it myself; I've been running it through a level shifter on my dev boards), the echo will still come back as 5v. Seemed to me like it was just as well to level shift the entire chunk for the ultrasonic since I had to shift at least the level in the echo.

When I get to redesigning I'll try to split up the GND pour like you suggested.

And thanks for noticing the missing ground on the enable of the 4052; I had that in a one point but must have accidentally deleted it at some point when I was making edits.

[marus]

Just thought I'd post an updated version based upon my interpretation of your advice; plus a few fixes I noticed myself upon review.

The main changes are as follow:
- Moved the regulation to 5v offboard; motors and the ultra-sonic sections are now powered directly from the 5v input to the board; while the micro is powered through the 3.3 LDO linear regulator.
- Did two separate ground pours; one for the motor controller area and one for the rest of the board; only joined close to the power input connector.
- Fixed the bypass capacitors on the LDO; this now uses two 10uF Tantalum caps; one on input and one on output. This was based upon the typical application in the data-sheet for TI's version of the 1117 regulator; also fixed my foot print for the 1117 because I noticed that I had accidentally tied the tab to ground instead of Vout.
- Changed the 4.7uF capacitor on the micro to a 10uF Tantalum; I've found several different recommendations online for the decoupling caps for the STM32 but the STMicroelectronics "Getting started with STM32F10xxx hardware development" application note states "... and a chemical capacitor C of about 10 µF..." (although the reference schematic in the same document uses a 10 uF ceramic).
- Fixed the enable pin on the HC4052 multiplexer to be tied to ground.
- Fixed the enable pin on the TXB0104 level translator to be tied to 3.3v instead of ground as it is active high; also changed the package for this to TSSOP-14 instead of SOIC-14 as apparently I ordered the TSSOP version by mistake.

Updated Schematic: https://www.dropbox.com/s/iabfrpt32j4az ... tic-r2.pdf
Updated Gerbers: https://www.dropbox.com/s/rfq0bc63ji7jj ... ers-r2.zip

If you, or anyone else, has any more feedback it is always appreciated; My background is software not hardware so I've still got a lot of learning in this area, but it is a fun and interesting hobby.