Go Down

Topic: compiling HardwareSerial.cpp in AVRStudio4 fried USB on UNO (Read 1 time) previous topic - next topic

Xnloder

I'm building a distributed robot control system using 5 UNO boards, 4 'twi_slave' UNO controlling steppers and one 'twi_master' coordinating motion and communicating with a PC via USB (and with the slaves over TWI).  I developed this under the Arduino IDE, but moved to AVRStudio4 when I began having stack overflow problems, needing the additional tools for memory mapping.

This move from the Arduino IDE to AVRStudio4 requires I compile the core, including HardwareSerial.cpp.  It compiles fine, but the first time I ran it, I fried the USB driver chips on the UNO.  That UNO is toast. 

In searching for a cause to this bug, I read the source for SoftwareSerial.cpp, which includes a call to digitalWrite(_transmitPin, HIGH );    The init() code of HardwareSerial.cpp does not have this assignment.  If the USB of the PC and that of the UNO each tried writing to the same wire, this could cause the UNO to fry. 

So my questions to the forum are:

1 - Is there a pin assignment to the USB in/out of the UNO associated with HardwareSerial.cpp?  If so, where is it?  Perhaps in .init4? 
2 - Is there any other reason the USB on the UNO could fry?
3 - Suggestions as to how to avoid stepping in this particular cowpie again?

Thanks!

--Jon
Xnloder

davekw7x

#1
Jun 09, 2011, 03:26 pm Last Edit: Jun 09, 2011, 04:29 pm by davekw7x Reason: 1

...The init() code of HardwareSerial.cpp does not have this assignment....


I'll give your first item a shot:


The UART RXD pin is an "Alternate Function" pin for Pin 0 of Port D and the UART TXD pin is an "Alternate Function" pin for Pin 1 of Port D.  (Refer to the "Alternate Port Functions" section of the data sheet.)

When your sketch executes Serial.begin(), that function sets RXEN and TXEN bits in the UCSRB register of the ATmega328p.  That causes The RXD pin to be set up in INPUT mode and causes the TXD pin to be set up in OUTPUT mode, regardless of settings in the Data Direction Register for Port D.

Also, there is a 1K Ohm resistor between the ATmega RXD pin and the USB interface chip on the Uno, so that if you set the Data Direction Register bit for that pin to OUTPUT mode and you don't execute Serial.begin(), the I/O current for that pin will be limited to no more than 5 milliamperes, so there will be no damage to the ATmega or to the USB interface chip.  This assumes that you don't have anything directly connected to (and trying to drive) the UNO digital pin 0.

Bottom line:
I think you have to look somewhere else for your Frying Thing.  I am sure that others on this forum will be able to give specific examples from the collection of Kinds of Things That Can Fry an Arduino and How to Avoid Them.


Regards,

Dave

GeniusPro

I don't think your Uno is fried...you've simply aced the boot loader so that it no longer downloads a new program into Mr. Uno.  If this is the case, you only need to reload the bootloader not using the USB, but using an ISP programming device that plugs into the Uno and AVR Studio 5 downloadable from ATMEL's website for free.  I have made this same mistake before and  bought and use the cheapest ISP programmer I could buy on ebay, otherwise the ATMEL AVRISPMKII programmer goes for about $60 U.S.
If you have, as you say several Uno's, then you upload a dump of the entire Flash Memory (program memory + boot loader) by reading it into a file on your PC with the ISP programmer and then use the same programmer to clone it (Memory Program Flash Command) into the "dead" Uno. You can then go back to the Arduino platform and reprogram the seemingly mentally ill Uno with the correct code for your  project as you 've now restored the boot loader.

Xnloder

GeniusPro:
It would be nice if the UNO weren't fried...troubleshooting gets expensive otherwise. 

I assume you're talking about an SPI interface programmer.  Adafruit has one for $22, but I've not used it (https://www.adafruit.com/products/46), so have no idea how well it works.  I'll try what you've described and post results as soon as the programmer arrives (on order). 

Should the bootloader be part of the AVRStudio project, or should I somehow tell AVRStudio the flash location containing bootloader is sacrosanct?

Davekw7x:
Your synopsis of PORTD0 and 1 is excellent.  I have read (and re-read) the data sheet, but until I step in it, its hard to map text to functionality.  Thanks.

GeniusPro

The programmer simple plugs into an USB port on your PC and a 6-wire IDC connection connects to the Uno board for ISP programming, bypassing the bootloader. You install a driver for the programmer and then you can use it to erase, read the Flash and EEPROM contents to files or Write a freshly compiled program or saved file the Uno.  The bootloader is not needed when using the ISP programmer, nor is the AVR bootloader compatible with the Arduino IDE.

Xnloder

It was something else altogether.

My program was too large.  The map file says:

  Program:  27712, meaning Flash is 85% full, and
  Data:  2013, is 98.3% full. 

This means the stack is blown almost from boot-time.  Time to migrate to a larger system, as the code is as tight as its going to get. 

This is why real engineers design before coding.  Maybe some day I'll be a real engineer...

Go Up