Custom PCB with ATmega32U4 - Issues with UART

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, 

 

We have implemented a custom PCB with an ATmega32U4 which is intended to communicate with a battery gauge over UART. We have, successfully, prototyped the circuit and the code using an Sparkfun Pro Micro Arduino which also uses the ATmega32U4. The design of our board is based on the Sparkfun design. However, the ATmega32U4 on the custom PCB is flashed with the same code, it is not able to communicate to the battery gauge. The USB communication between ATmega32U4 and computer appear to be fine. We used the ATMEL ICE programmer to flash the board. Also the fuses were updated to match the fuse configurations of the Sparkfun Pro Micro which are low_fuses=0xFF and high_fuses=0xD8.

 

Is there anything that needs to be done to a brand new ATmega chip to make act like an Arduino besides flashing and setting fuses? One point of confusion I have is we are running the ATmega32U4 at 3.3V but still using a 16 MHz crystal. According to the datasheet, that is out of spec. Would this have any impact on the issue that we are experiencing? Would the USB communication work with the wrong crystal? Are there any issues with the schematic that we have implemented?

 

The schematic is attached. 

 

Thanks, in advance, for your help!

Mike 

 

 

Attachment(s): 

This topic has a solution.
Last Edited: Fri. Feb 14, 2020 - 01:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any possibility you have your battery TX/RX pins connected backwards?  ie. TX to TX and RX to RX???

Your schematic looks ok to me with this one possible exception, normally TX connects to the remote RX and vis-versa.

 

Welcome to AVRFreaks!

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should have a pullup resistor on the program reset line or the gate pin will float and cause strange resets when the programmer is not plugged in.

 

The same thing goes for GPIO_5.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

However, the ATmega32U4 on the custom PCB is flashed with the same code, it is not able to communicate to the battery gauge.

 

Can you successfully download any program?

Can you just simply flash an LED at 1 Hz?

 

Let's see what others say, but I do not like your micro Reset\ circuitry.

 

It appears that J13 is an ISP programming header.

The Reset\ signal from the programmer should connect directly to the Reset\ pin on the micro.

 

If the Reset\ signal is asserted, then the micro will go into its Reset Mode, and the I/O pins will all go into a high impedance input state.

Hence the GPIO_5 that feeds the Gate will float.

Ah, I see John already mentioned that.

But why qualify the programmer's Reset\ signal with the logic gate and a pin from the micro being Reset\ ?

 

I suspect that without a good reason for doing otherwise, I would have connected the programming Reset\ directly to the micro, and put a 200 ohm or whatever resistor in series with the Reset logic gate's output.

(Need to check its drive capability).

 

As mentioned check the USART signals and make sure that they aren't reversed.

 

Flash one of the LEDs 10 times at 1 Hz on start up to make sure the micro is running at the correct frequency, at least for now.

 

I'll never understand Active Low LEDs, but that has nothing to do with why the board isn't working.

 

As you have plenty of spare I/O pins, I would have brought one out to a "spare" LED just for testing and debugging.

You don't have to populate it if you don't want to, but the extra pads cost you nothing.

You can also use that I/O pin or another one, to a spare header, for hooking up an O'scope, either to time ISR's, or as a scope trigger when looking at other signals, etc.

 

I'm not a USB hardware guy.

But I'll just ask if you need / should have any voltage clamps on the USB data lines?

And/or do either of them need a pull-up to define the USB speed?

And, since it isn't readily clear to me from the schematic, is there a Ground connection from the micro to the USB Header's Ground pin?

 

 

JC   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Jim, 

 

Thanks for the response. I have double and triple checked the connections to the battery. The battery is actually using a single wire and below is the circuit that we have implemented, where the 1-Wire Bus is the battery connection and the TX and RX are connected to the Arduino ports. Any issue you see with the crystal? Some Arduinos (like the Leonardo) have a 1MOhm resistor connected in parallel to the crystal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:

You should have a pullup resistor on the program reset line or the gate pin will float and cause strange resets when the programmer is not plugged in.

 

The same thing goes for GPIO_5.

 

This was an outdated schematic. We do have a pull up resistor on the program reset line. Thanks for the feedback!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doc, the active low scenario probably goes back to the days of dtl and ttl logic. Open collector was common and the sink current performance was better pulling low. Then we went to nmos and again, the sink performance was better than the source. Nowadays with cmos, there is no advantage. So active low is really just something of an old convention or convenience. You have two choices - flip a coin!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I get it, it just bothers my old brain.

And I do understand that it makes absolutely no difference for the end user, or the hardware, or the software, (as long as the coder knows whether it is using reverse logic or not).

In the STK500 which also uses the reverse logic there is a driver transistor for each LED, and the driver lets the LED turn fully on regardless of the Vcc level for the micro.

In this case there is no benefit to the reverse logic, and I just like positive logic better.

 

I never was much good with PNP transistors, either...

 

I did some TTL design years ago.

I don't recall ever using DTL gates / chips.

That seems like a long time ago, (sigh).

 

JC

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Solved - Turns out the diode was shorted with extra solder during PCB production. Once that was fixed, everything worked great. Thanks everybody for the help! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good catch, please mark the solution (your own in this case) #9

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where are the decoupling caps on the supply/gnd pairs?

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should use a schottky diode...at 3.3V  the less voltage you throw away, the better.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!