Odd Start Up State

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

I am working on a project that consists of daisy chaining about 50 boards together each containing an ATMEGA1284P. There are 8 lines in and 8 out. In is 2X power and ground, usart tx and rx, a power enable, and a general I/o. Out is 2x power and ground, usart, and 2 i/o pins. When the first one boots, it sets one IO line low that loads the next board in a certain state and then sets another high to enable the next board's regulator enable. This goes on to the next and so on.

I only am testing about 20 boards right now and half the time it works fine, but the other half it may only enable 12 or 4 or 7 or none or 17...you get the point...it is random. Making a change and reprogramming 20 boards is a nuisance so hopefully someone can explain what might be going on here. Can the usart semi power up the next device and cause it to enter a weird state? I have the brown out fuse set for 1.8v and I'm powering it with 3.3, should I use 2.3? Should I set the port d...usart....to an output state, set all low, power up next, then configure usart? Any ideas would be greatly appreciated. Also...if I force a reset via watchdog on the first board it's worse....maybe 25% of the time all boards load. I can visably see when a board loads. An LED is present from an io line. One more thing, there is about a 300ms total delay from when one board is up and the next starts. I added this in the code.

Thanks!

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

 Can the usart semi power up the next device and cause it to enter a weird state?

Yes, it certainly can.

 

In the Electrical Spec's it says that no pin can be greater than 0.7 V above Vcc.  If Vcc is 0 then the max allowed on a pin is 0.7 V.

This means that you can't have active signals on the uC's I/O pins until the chip is powered up.

 

There are over/under voltage protection diodes on the I/O pins that connect them to the Vcc and Ground rails.  The USART signal can partially power the micro through this diode on the RxData line.

Partially powering a micro is bad news.  It can partially work, lock up, perhaps work erratically, etc.

 

I would suggest powering up the next PCB, and then enabling the USART in the preceding PCB.  The USART pins will power up as inputs until your code configures the USART.  So power up the next PCB before your USART setup code, with a bit of a delay to allow the next uC to power up and stabilize.

 

I assume that each PCB has EVERY Vcc, AVcc, Ground, and AGround pin tied to Vcc and Ground.

I assume that each AVcc/Gnd and AVcc/AGnd pin pair has a by-pass cap across it, close to the uC's body.

I assume that AVcc is tied to Vcc either directly, or through an LC filter.

 

I trust that a single PCB, tested on its own, is running fine, (flashing an LED, etc.).

 

I assume you have an Xtal for the clock freq on each PCB, or have otherwise instituted some sort of clock calibration to insure that each PCB's baud rate is correct.

 

It seems to me you could test with just 5 PCBs in the chain until they work reliably, then slowly add the others to the chain.  No real reason to program 20 PCBs with each version of the code until it starts working correctly.

 

What is the distance between boards?  Are the USARTs connected at logic level, or via RS-232, or via RS-4xx, etc.?

 

It would be great if you added a photo of your project, once it is up and running, if you are able to do so.  It sounds like an interesting project.

 

JC

 

 

Last Edited: Fri. Sep 19, 2014 - 04:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JC...thanks so much. That's what I was hoping to hear. It's been bugging me all day.
Yes all grounds are tied except I didn't mention a second high power which is isolated through optos.
Vcc and Avcc are tied through a LC.
Yes each PCB was tested. They were swapped to different locations during this as well and it didn't matter.
Yes there is an external xtal and I chose one and a baud rate to match with minimal error.
It seems I have better luck with it failing over a larger span.
It seems I can't upload a picture from my phone so I'll add one tomorrow.

Thanks again!

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

Try connecting a bd to teraterm on a pc, power up the 1284... see a garbage char out the uart? If so, do you read the UDR to clear the char ready flag BEFORE setting the baud rate and enabling the rx and tx?

Imagecraft compiler user

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

Thanks Bob. I set the outbound uart to initialize after the next board power is applied and so far after programming and testing 34 boards daisy chained about a dozen times, they all come up successfully. I do however have a "flush" after power up as well. I use ascii STX and ETX to begin and end a command after the first board so any garbage is ignored. The first board goes into a user friendly terminal.

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

It's probably too late to redesign the boards(and expensive)

 

BUT!

IMO it is unwise to enable/disable the power supply in this type of configuration just because of what you described.  A better approach would have been a pull down resistor on each RESET line for the AVR's and put some code in each processor that sets an output pin that can be tied to the reset of the next AVR to take it out of reset.  This way you always have a stable power supply, which is probably why the AVR's are acting the way they are.

 

Example.

All the AVR's are in their respected positions.  AVR A has an I/O pin tied the the reset line of AVR B, which has an I/O pin tied to AVR C and so on.  All boards power up at the same time, but the pull down resistors keep the AVR's in RESET.  Once AVR A starts up and the code is running, it sets the I/O pin HIGH, which takes AVR B out of reset and it starts up, then when it's code finished the INIT cycle set teh I/O pin HIGH taking AVR C out of reset, and so on.

 

This would virtually guarantee that the boards all start up properly.  You might have to put some sort of jumper on the board to classify it as board A when the jumper is installed, or any of the others when the jumper is missing.

 

Just me two sense.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

Here's the issue with that....I may be powering up to 100 boards. Powering all on at once isn't desired. Pull ups, capacitors, ics, etc all on at the same time....not sure of the outcome. Jumpers won't work....these have to be interchangeable without modifications. Believe me...I originally had kind of the same idea by using reset.

Thanks tho

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

As promised, this is 3 4' sections out of 5.

Attachment(s):