XMEGA32E5 BROWN-OUT?

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

I'm having a bit of trouble with Pin 7 on PORTC seemingly browning out the device when pulled low. I have the pin configured as an input with no pullup or down because I'm using an opto with a pullup. I'm using single wire UART on the port as well as I2C. The odd part is I wrote my own drivers except for the single wire UART. I used the asf for the single wire and in a nut shell when I have just a bare bones project without ASF I don't see issue with the pin is pulled low. I figured it's something to do with the ASF but I'm lost as to which potential register being set would cause this. I checked the brownout fuses and monitored the voltage rail and the condition for brownout is never met. Any suggestions are welcome.

 

P.S. I'm more than willing to post the code but it is pretty hefty.

Cheers,
Jesse_G an EE writing firmware...what could go wrong...

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

Can you describe how you determine that a brownout event has occurred?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Jesse_G_EE wrote:
I'm using an opto with a pullup.

 

Post the schematic with part values.

 

When you say you have I2C and single wire USART on the port do you mean on the same pin, or on separate pins?

 

Other 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

Jesse_G_EE wrote:
h Pin 7 on PORTC seemingly browning out the device when pulled low
Jesse_G_EE wrote:
Pin 7 on PORTC seemingly browning out the device when pulled low. I have the pin configured as an input with no pullup or down because I'm using an opto with a pullup.

Most likely you "think" it's an input, but it's actually an output that is high, when the pin is pulled low, it causes a dip in VCC and the part resets.

Check your code and specifically any thing that messes with the port pin direction, this is an xmega so port direction has to be explicitly set i believe where a tiny/mega a module can override a pin direction when enabled. 

Try disabling sections of the code that deals with pins on that port and see if you can isolate where to look.

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

ka7ehk wrote:

Can you describe how you determine that a brownout event has occurred?

 

Jim

 

ki0bk wrote:

 

Most likely you "think" it's an input, but it's actually an output that is high, when the pin is pulled low, it causes a dip in VCC and the part resets.

Check your code and specifically any thing that messes with the port pin direction, this is an xmega so port direction has to be explicitly set i believe where a tiny/mega a module can override a pin direction when enabled. 

Try disabling sections of the code that deals with pins on that port and see if you can isolate where to look.

Jim

 

Essentially, the opto coupler(TCP817S1A) is triggered pulling the node low and everything goes off. Meaning, the 16x2 LCD and the indicator LED's and so on. I put a breakpoint on a flag I created to see when it happens, and it happens after I return to main and go into my I2C communication(mostly Fluery's I2C Master lib). The other oddity is I have the exact setup on 3 other pins on the same port(4,5,6). I repeated the breakpoint on each pin to monitor the registers and nothing. It goes into the I2C routine and executes just fine. Also, thank you for the input.

 

jgmdesign wrote:

Post the schematic with part values.

 

When you say you have I2C and single wire USART on the port do you mean on the same pin, or on separate pins?

 

Other Jim

 

Don't judge me on using a linear instead of a buck converter on the power side haha. Also, they are have there own pins on the communication side. I'm going to cut the trace and jump it to another port to see what happens. I'm an EE so thats the easier route as this isn't the final product.

Cheers,
Jesse_G an EE writing firmware...what could go wrong...

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

Jesse_G_EE wrote:
Don't judge me on using a linear instead of a buck converter on the power side haha.

 

No issue from me on a linear regulator.

 

Looks like an industrial design based on those input circuits.  I do not see any reason for what is occurring unless you indeed have accidentally set that pin as an output.

 

One thing, and its just me being a little picky...the 1M pull ups are a bit high for an industrial application....theres a chance noise from the environment could trigger your input....10k at most is all I ever use, but its your circuit and if you want that so be it sad

 

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

jgmdesign wrote:

 

One thing, and its just me being a little picky...the 1M pull ups are a bit high for an industrial application....theres a chance noise from the environment could trigger your input....10k at most is all I ever use, but its your circuit and if you want that so be it sad

 

 

Jim

 

I actually swapped the pull ups for a lower value and I appreciate your feedback. I also jumped the trace to an open pin on PORTA and the same thing is happening. So I'm probably doing something obviously stupid, I just can't see it yet. Onward and...ward

Cheers,
Jesse_G an EE writing firmware...what could go wrong...

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

Thanks for all the replies. I'm an idiot when it comes to programming. I have to trust my hardware and not my programming...I'll figure that out one of these days. I looked a variable I was sending I2C:

char *coilCall[4] = {MSG_U, MSG_UL, MSG_U_UL, MSG_D, MSG_DL, MSG_D_DL};

As you can see I have 6 values defined in a 4 element array. Its like my first day... Well when I went to sent coilCall[4] to I2C it didn't like that. What a day....

Cheers,
Jesse_G an EE writing firmware...what could go wrong...

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

Ignore the PM I sent you then...

 

Great that you got it working.

 

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