State of gpio when Microcontroller is breaks

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

i am currently trying to figure out in what state my micronctoller GPIO will be when it breaksdown.

 

If you are running a program and the pin is in output state when the microcontroller breaksdown, what will be the output?

Will it keep the same state or will it go undefined?

I know there is a internal pull-up that can be enabled, but will it still be enabled when the microcontroller breaksdown?

 

I was thinking about an external pull-up or pull-down the make sure there is a define state when the microcontroller breaks.

 

The reason for this is, that i have a pin that set a RS485 chip in receiving or driving mode, depending on the pin state. I want the RS485 chip to be in receiving mode when the micocontroller breaks, then it won't keep the bus busy and can other devices still communicate.

 

Currently using a atmega4809, but i don't think that matter for the question here.

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

Define "Breaksdown". You mean if the AVR is damaged?

I vote undetermined.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

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

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

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

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

yes damaged, not working anymore (broken). In whatever way

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

The result is indeterminate. You need to determine how likely such a failure is, what the possible outcomes are and if you need to mitigate this.
Having said this, it is more likely the RS485 will fail and this has been my experience. I’ve replaced many more rs485 chips than microcontrollers. The usual failure mode of a Rs485 transceiver is to stop the bus from working.

Last Edited: Thu. Mar 28, 2019 - 11:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rgamer145 wrote:
. In whatever way
Then the answer is the pins get stuck high, the pins get stuck low, the pins are floating - all results are possible as all forms of damage are possible.

 

How do you propose to damage this AVR in the first place - temperature, shock, over voltage, reverse voltage, lightning, hammer, explosion, other ??

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

I think the most likely ways would be. falling damage, over voltage/reverse voltage 

 

And yes, i was thinking the same. You don't know the state of the output. But is it usefull to place a weak pull down resisitor on the pin, to kinda make the output more defined when broken?

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

i don't think the micocontroller will break first, but was thinking about the possibilities when something breaks.

And my idea was also the it undetermined, but in case of failure in some way make it determined with an weak external pull-up/pull-down resistor.

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

It's far more likely that the external resistor or the tracks to it or the solder holding it will "breaK" than anything inside the silicon (unless you really do subject it to an environment outside the specification - explosion, over voltage, etc etc)

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

So one way to counter this is not to use the level of a pin to drive your RS485 driver but to use the constant toggling of a pin to do it. As long as the pin toggles then you are in transmit mode. If the pin stops toggling and stays high, low, or just goes to some indeterminate state, then you go into receive.

 

Or you do as some RS485 interfaces do and use your transmit data to turn the driver to transmit. A high to low transition on TX triggers a monostable which drives the transmit enable. When TX stops wiggling, the driver will revert to receive after a short time.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

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

Use a 555 timer to turn on the rs485 transmitter. If the microprocessor dies the 555 times out and shuts off the transmitter. What if the 555 faiils? Put an attiny 85 between the 555 and the transmitter. What if the attiny 85 fails? What if the microprocessor works but the transmitter fails and continues to transmit when it is supposed to be off.

Any shared medium is subject to failure due to one transmitter jabbering. Run separate wires rather than a shared bus.

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

It really comes down to the tolerable failure rate and how many levels you want to back up the backups! As long as you have a single-point-of-failure, you are doomed to a finite failure rate.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!