ATMega16 weird behavior

[DavidDLC]

We are working on a project that involves an ATMEGA16 microcontroller connected through USB as a COM Port.

Somebody else made the hardware and firmware design, I just jumped to help with this issue

Every time we send a byte and the microcontroller process it the current goes down and close to 0, sometimes the microcontroller will reset. Any operation, even when the command is set to do nothing (just receive the byte)

I'm thinking of a Brown Out condition, but I'm approaching the forum if somebody has experience or another clue of what might be causing this issue.

Attached is a chart of the current going down.

If somebody can help we really appreciate it

[tepalia02]

Which hardware are you using to program the ATmega16? Is it USBASP?

[iMo]

Do you have the USB made via software? Is there a schematics available?

[DavidDLC]

Tepalia02: Yes, we are using the USBASP.

imo: The unit connects as COM port and unfortunately they don't let me share the schematics

[Carel]

Look for a more "official" programmer. A couple of weeks ago I bought a USBASP programmer, one of my STK500's is broken. The software is a nightmare. Seemingly it bypasses the USB chip on the PC side to emulate a serial connection. When my mouse stopped working, I quit on it.

I am now going to order an AVRISP mkii.

[tepalia02]

Which loading software are you using? Is it AVRdude? If you try to read the fuse bits of the microcontroller, can you read? AVR chips often behave weirdly because of wrong fuse bits. 

[DavidDLC]

I found the problem.

They have two port pins connected to ground, I set them as inputs and this solved the problem.

The software developer said he checked the data sheet and they supposed to be inputs by default (I didn't check) and maybe the bootloader was setting them as an outputs, he copied the bootloader from the web.

Thanks for your answers

[brucehoult]

The software developer said he checked the data sheet and they supposed to be inputs by default (I didn't check) and maybe the bootloader was setting them as an outputs, he copied the bootloader from the web.

I would think it would be very bad for any microcontroller to default to any pins at all being outputs, and start trying to drive them on reset, with no idea what that are connected to.

[DavidDLC]

The problem is that he copied the bootloader from somewhere else and didn't check anything on it

[Doctorandus_P]

The problem is that ...

And another problem is that bootloader leaves the processor in some intermediate and thus unknown state. The proper way to exit a bootloader is by a hard reset, for example by enabling the watchdog and let it timeout on purpose.