ATTiny404 - Invert Input does not seem to work on PA0 (RESET/UPDI)

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

I'm using all IO pins on an ATTiny404.

 

I've got 6 Pushbutton inputs and 6 PWM outputs.

I've enabled Pullups on all the inputs.

 

I'm inverting ALL the IO pins (so pushbuttons give '1' when pressed, and PWM's are correct for my H-Bridge controllers)

 

Everything seems to work, EXCEPT the INVEN setting on PA0.  No matter how I set this bit, the input is NOT inverted.

It works, but it's just not inverted.

 

It seems coincidental that this ONE pin (out of 12) is the only one with a problem, AND this pin also happens to be the /RESET & UPDI programming pin.

 

Clearly the INVEN on the input is not critical (i can flip it in software), but I just wanted to know if anyone else has seen this issue, and if there is a trick I need to do to fix it.

I've verified that the code is setting all the input pins with the same INVEN/Pullup pattern (0x88)

 

Thanks

Phil.

 

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


Don't you need to make that pin an I/O pin first and an output? Of course then you lose the programmability of the chip.

 

Edit yep, I guess it's the very last thing you want to do but I have never done it so someone else may pitch in with more info.

 

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. May 12, 2022 - 11:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't recognize that sceen.  Probably because I'm using MPLAB.

I'm a long term PIC user and this is my first AVR project.

It went surprizingly well, except for this odd PA0 issue.

 

I'm using PA0 as an input, and it is working properly as an input (less INVEN), and when connected to a SNAP programmer, it burns new code just fine.

The code built by MCC is setting:

 

.SYSCFG0 = CRCSRC_NOCRC_gc | RSTPINCFG_UPDI_gc,

 

Which seems right.

 

I just turned off the INVEN bits on all my inputs and flipped the logic in my code.  

I suspect that's what most folks do normally...  

My problem is bypassed but I hate having annomilies hanging around in my head.

 

Phil.

A fellow Aussie living in the Appalachian Mountains of the USA

 

 

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

Maybe check errata (or add to it)

 

Assuming you metered the actual pin to ensure you didn't accidentally install/wire one NC switch while all the others are NO types.  Suppliers are good at dropping wrong parts in a bag.

 

We had some loose bag zeners and a couple of 9V zeners got dropped into the 12V bag....caused havoc for a while !

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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



.SYSCFG0 = CRCSRC_NOCRC_gc | RSTPINCFG_UPDI_gc,

You need to configure that pin as I/O for correct operation from what I understand , the above sets it as UPDI which is the default setting ie RSTPINCFG[1:0] need to be both 0x00

 

WARNING!!!! you may lose programmability unless your programmer can do the High voltage program. NEVER used this chip so be careful. smiley

 

 

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Philbot wrote:

I just turned off the INVEN bits on all my inputs and flipped the logic in my code.  

I suspect that's what most folks do normally...  

As that seems to be a new feature for AVR0/1/dx, yes, freaks would normally do that in the s/w.....

 

Jim

 

 

FF = PI > S.E.T

 

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

Where would the "official" place to post this issue be? (just to get it on the record).

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

"Dare to be naïve." - Buckminster Fuller

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

Welcome to the Forum.

 

It is hinted to above, but I'll just straight out mention it.

Many MC AVR users avoid using the Reset\ pin as a general data - I/O pin.

 

Yes, it can be done.

But life is soooo much easier to just select a slightly larger micro.

 

The issue is that that pin as a very different hardware structure.

As JS mentioned, one often needs to change the mode of the Reset\ pin for it to function as an I/O pin, as desired.

And that action can lock one out of the ability to (easily) re-program the chip.

 

So, if your code is perfect, and you are building many devices, and the cost differential makes a difference, go for it.

Otherwise, life is too short for the headaches one can encounter when using the Reset\ pin as a general purpose I/O pin.

 

The SNAP programmer is a great little programmer.

It cannot, however, do "High Voltage" programming, which is what is, (I think), need to "recover" programmability if one changes the mode of the pin.

 

Good luck with your project.

 

Photos of projects are always welcomed on the Forum!

 

JC

 

 

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

When a pin is in UPDI mode, it just happens that you can also read it because UPDI is 'listening' on the same pin. You have no control over things like dir/out because UPDI needs to control those as its bidirectional, just as some other peripherals can override settings of a pin. Not hard to imagine that they take away your ability to effectively disable UPDI by setting INVEN, either. Probably tough to run the debugger when you happen to set the INVEN bit in your code, and also tough to debug while you are using that same pin as switch input (unless you never touch that pin).

 

You can change the pin to gpio as already mentioned, but if you do not have a way to get back into programming via high voltage, then its a one time switch with no more programming until you get a high voltage programmer.

 

You already have a solution which works. At least you get to use the pin as an input.

 

As a general rule, leaving the updi pin exclusive to programming is a lot easier. I would also choose an mcu with more pins than needed- you have some extra pins when needed, which usually happens, and you get to run a programmer/debugger without having to deal with hv programming or conflicts when using as your own input. It never makes much sense to choose the lowest pin count mcu until/unless you are talking large quantities.

Last Edited: Fri. May 13, 2022 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
I would also choose an mcu with more pins than needed- you have some extra pins when needed, which usually happens, and you get to run a programmer/debugger without having to deal with hv programming or conflicts when using as your own input. It never makes much sense to choose the lowest pin count mcu until/unless you are talking large quantities.

+1

 

 

FF = PI > S.E.T

 

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

 you have some extra pins when needed,

And always bring spare pins out to some pads*, especially in the early days, and especially when they are buried (like under a QFN package).   You will need them and save the day.

 

*vias even better, to insert a wire, scope probe, etc.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. May 13, 2022 - 06:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller