Changed Fuses Bricked ATtiny1616

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

Reference this thread, https://www.avrfreaks.net/forum/tiny1616-fuse-setting-erroras it seems my problem is directly a result of accidentally setting the fuses on my ATtiny1616 per the settings in the OP there.  Fuse settings copied here for completeness;

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,  // WDT = OFF
    .BODCFG     = LVL_BODLEVEL7_gc | SAMPFREQ_1KHZ_gc | ACTIVE_ENABLED_gc | SLEEP_SAMPLED_gc,  // BOD level = 4.3V 
    .OSCCFG     = FREQSEL_20MHZ_gc,
//  .TCD0CFG	=
//  .SYSCFG0	=
//  .SYSCFG1	=
//  .APPEND     =
//  .BOOTEND	=
};

I added the fuse settings to main.c in my project only to see if I could recreate the issue Kabasan was having and never intended to program a device with them.  I forgot to remove them, and since the project was built with those fuse settings, when I programmed the chip I lost the ability to reconnect to the chip with the Atmel-ICE.

 

The Atmel-ICE is known to be functioning properly as I have no problem connecting to another ATtiny1616 and many other chips as well.

 

My question is, how do I connect to the ATtiny1616 with the Atmel-ICE again.  Is it possible to use UPDI Enable with 12V Override of RESET pin mode to erase the chip?  The ATtiny1616 datasheet and Atmel-ICE documentation are vague and confusing to say the least.

 

Any ideas?  Has anybody used the UPDI 12V mode with an Atmel-ICE?

 

ATtiny1614/ATtiny1616/ATtiny1617 Datasheet

 

Atmel-ICE User Guide

 

 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Tue. Mar 6, 2018 - 06:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

New info:  I have tried the Arduino based UPDI programmer written by El Tangas and have confirmed that the chip is in some strange configuration.

 

avrdude, running with the avrdude.conf that El Tangas provided in his project, returns the value RSP_ILLEGAL_MCU_STATE when a reset command is sent.  Also note the message, Illegal MCU state: Running, just above that.  Need more info about what those indicate in the grand scheme of things.

 

c:\avrdude>avrdude -c jtag2updi -P com3 -p t1616 -v -v -v

avrdude: Version 6.3, compiled on Feb 17 2016 at 09:25:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "c:\avrdude\avrdude.conf"

         Using Port                    : com3
         Using Programmer              : jtag2updi
avrdude: jtagmkII_open_pdi()
avrdude: jtagmkII_getsync()
avrdude: jtagmkII_getsync(): Sending sign-on command:
avrdude: jtagmkII_send(): sending 1 bytes

avrdude: jtagmkII_recv(): Got message seqno 0 (command_sequence == 0)

Sign-on succeeded

JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
S_MCU:
  boot-loader FW version:        1
  firmware version:              6.00
  hardware version:              1
Serial number:                   00:00:00:00:00:00
Device ID:                       JTAGICE mkII
avrdude: jtagmkII_getsync(): Using a 298-byte device descriptor
avrdude: jtagmkII_setparm()
avrdude: jtagmkII_setparm(): Sending set parameter command (parm 0x03, 1 bytes):
avrdude: jtagmkII_send(): sending 3 bytes

avrdude: jtagmkII_recv(): Got message seqno 1 (command_sequence == 1)

OK

avrdude: jtagmkII_getsync(): Sending get sync command:
avrdude: jtagmkII_send(): sending 1 bytes

avrdude: jtagmkII_recv(): Got message seqno 2 (command_sequence == 2)

OK

         AVR Part                      : ATtiny1616
         Chip Erase delay              : 0 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 0
         StabDelay                     : 0
         CmdexeDelay                   : 0
         SyncLoops                     : 0
         ByteDelay                     : 0
         PollIndex                     : 0
         PollValue                     : 0x00
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           prodsig        0     0     0    0 no         61   61      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuses          0     0     0    0 no          9    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           usersig        0     0     0    0 no         32   32      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash          0     0     0    0 no      16384   64      0     0     0 0x00 0x00
                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom         0     0     0    0 no        256   32      0     0     0 0x00 0x00

         Programmer Type : JTAGMKII_PDI
         Description     : JTAGv2 to UPDI bridge
avrdude: jtagmkII_getparm()
avrdude: jtagmkII_getparm(): Sending get parameter command (parm 0x01):
avrdude: jtagmkII_send(): sending 2 bytes

avrdude: jtagmkII_recv(): Got message seqno 3 (command_sequence == 3)

parameter values:
0x01  0x01

avrdude: jtagmkII_getparm()
avrdude: jtagmkII_getparm(): Sending get parameter command (parm 0x02):
avrdude: jtagmkII_send(): sending 2 bytes

avrdude: jtagmkII_recv(): Got message seqno 4 (command_sequence == 4)

parameter values:
0x00  0x06  0x00  0x06

         M_MCU hardware version: 1
         M_MCU firmware version: 6.00
         S_MCU hardware version: 1
         S_MCU firmware version: 6.00
         Serial number:          00:00:00:00:00:00
avrdude: jtagmkII_getparm()
avrdude: jtagmkII_getparm(): Sending get parameter command (parm 0x06):
avrdude: jtagmkII_send(): sending 2 bytes

avrdude: jtagmkII_recv(): Got message seqno 5 (command_sequence == 5)

parameter values:
0x88  0x13

         Vtarget         : 5.0 V

avrdude: jtagmkII_initialize(): trying to set baudrate to 115200
avrdude: jtagmkII_setparm()
avrdude: jtagmkII_setparm(): Sending set parameter command (parm 0x05, 1 bytes):
avrdude: jtagmkII_send(): sending 3 bytes

avrdude: jtagmkII_recv(): Got message seqno 6 (command_sequence == 6)

OK

avrdude: jtagmkII_set_devdescr(): Sending set device descriptor command:
avrdude: jtagmkII_send(): sending 299 bytes

avrdude: jtagmkII_recv(): Got message seqno 7 (command_sequence == 7)

OK

avrdude: jtagmkII_reset(): Sending reset command:
avrdude: jtagmkII_send(): sending 2 bytes

avrdude: jtagmkII_recv(): Got message seqno 8 (command_sequence == 8)

Illegal MCU state: Running

avrdude: jtagmkII_reset(): bad response to reset command: RSP_ILLEGAL_MCU_STATE
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: jtagmkII_close()
avrdude: jtagmkII_close(): Sending GO command:
avrdude: jtagmkII_send(): sending 1 bytes

avrdude: jtagmkII_recv(): Got message seqno 9 (command_sequence == 9)

OK

avrdude: jtagmkII_close(): Sending sign-off command:
avrdude: jtagmkII_send(): sending 1 bytes

avrdude: jtagmkII_recv(): Got message seqno 10 (command_sequence == 10)

Illegal MCU state: Running

avrdude: jtagmkII_close(): bad response to sign-off command: RSP_ILLEGAL_MCU_STATE

avrdude done.  Thank you.

 

Looking for a solution as this issue may become more relevant with these new ATtiny's (Xtinys) becoming more popular.

 

Section 33.3.2.5 UPDI Communication Error Handling in the datasheet might be relevant, though stand alone code would have to be written to accomplish what is written there.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Tue. Mar 6, 2018 - 06:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
Looking for a solution as this issue may become more relevant with these new ATtiny's (Xtinys) becoming more popular.

 

Is the transaction any different with reset not connected at all ?    

If reset is disabled from UPDI, I'd imagine getting connection becomes tricky.  Maybe power cycling, under PC control ?

 

I see the messages do mention parallel programming, not sure what that means ? 

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

Who-me wrote:
I see the messages do mention parallel programming, not sure what that means ?
That is because El Tangas used the jtagice mk2 protocol in his code.  Read his README.md ​at the project GitHub repository for more info on that.  So not even sure if the responses are valid, though a working chip reports back just fine *.  Perhaps El Tangas will comment further on this subject.

 

EDIT: Remember that UPDI is a one wire UART based half-duplex interface, all communication goes through the UPDI pin.  Note that I only used El Tangas progranmmer because AS7 only reported that it could not communicate with the chip, at least his programmer reported something more.

 

EDIT2: * RE: reports back just fine;  Many messages appear to be non-valid responses based on the jtagice mk2 protocol in use.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Tue. Mar 6, 2018 - 08:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
EDIT: Remember that UPDI is a one wire UART based half-duplex interface, all communication goes through the UPDI pin.  Note that I only used El Tangas progranmmer because AS7 only reported that it could not communicate with the chip, at least his programmer reported something more

 

Yes, but it needs a break on the reset pin.

Looking at the Tiny817 data (because I have that open) it says this

 

During power-up, the Power-on Reset (POR) must be released before the 12V pulse can be applied. The
duration of the pulse is recommended in the range from 100us to 1ms, before tri-stating. When applying
the rising edge of the 12V pulse, the UPDI will be reset. After tri-stating, the UPDI will remain in reset until
the RESET pin is driven low by the debugger. This will release the UPDI reset, and initiate the same
enable sequence as explained in UPDI Enable with Fuse Override of RESET pin.
The following figure shows the 12V enable sequence.
Figure 33-6. UPDI Enable Sequence by 12V Programming

 

I suspect you may need to do that 100us~1ms at 12V pulse, then 10~200us at 0v, then Vdd ?

I wonder if a UART handshake line can enable the 12V, and meet timing ?

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

My programmer tries to enter program mode when either the "reset" or "enter program mode" jtagice mk2 commands are received.

Why reset enters program mode is related to the way avrdude works and my laziness and is not important for the problem at hand...cheeky

 

The error "illegal MCU state" means the MCU is not running in "default" mode when the programmer tries to connect. It always returns "running" because the actual return values the protocol has available are not really useful for UPDI.

 

I can change it to return the UPDI system status instead. This is not valid under the jtagice mk2 protocol, but might help to debug the actual problem.

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

Ok, I created a debug branch that hopefully will return useful information instead of

Illegal MCU state: Running

 

However, this info will not be compliant to jtagice 2 standard, so it may be necessary to set avrdude to lvl 4 verbosity to see the error (-v -v -v -v).

 

here is a direct link: https://github.com/ElTangas/jtag...

 

edit: I think I already found a bug that may or may not be responsible for this problem. If it is, then Atmel software has the same bug, probably.

Larry, does your project put the tiny in sleep mode? If it does, then my programmer would fail with that error, I believe. But to be sure, the best way is to run the debug version of the programmer.

Last Edited: Tue. Mar 6, 2018 - 12:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
Ok, I created a debug branch
Thank you for taking the time.

 

The only significant change in the avrdude report is that it now returns Illegal MCU state: Stopped instead of Illegal MCU state: Running.

 

El Tangas wrote:
edit: I think I already found a bug that may or may not be responsible for this problem. If it is, then Atmel software has the same bug, probably.
Yes, the bug seems to be that section 33.3.2.5 UPDI Communication Error Handling and/or 33.3.9 Sleep Mode Operation have not been implemented.  AS7 gives up at the first sign of a UPDI communication error, I do not believe that they have implemented any of the UPDI error handling protocols.

 

El Tangas wrote:
Larry, does your project put the tiny in sleep mode? If it does, then my programmer would fail with that error, I believe. But to be sure, the best way is to run the debug version of the programmer.
My project does not, but the version programmed into the chip, including Fuse settings as explained in the OP, has the BOD level = 4.3V and BOD operation mode in sleep is sampled.  BOD is enabled.  VCC is a solid 5V. Sleep has not been enabled. 

 

I have also tried applying an external clock with no change in results.

 

I do believe that somehow the chip is sleeping, o muerto :\, though it would be nice to have the tools to absolutely confirm this.  I am starting to think that writing a standalone UPDI tool from scratch is the way to go, though it would be a considerable undertaking (pun intended).

 

Thanks again.

 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Tue. Mar 6, 2018 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:

The only significant change in the avrdude report is that it now returns Illegal MCU state: Stopped instead of Illegal MCU state: Running.

 

That means the UPDI ASI_SYS_STATUS register is 0x00. I've never seen that value returned during my testing. Normally it will be 0x82 to indicate the MCU is running, although both set bits are not documented in the current datasheet. Maybe I should also accept 0x00 as valid (?)

It also means the UPDI is operating without communication errors, or else nothing would be returned (I did not implement an input timeout, but in practice random fluctuations would eventually cause something to be returned after some time. The long delay would be noticeable and avrdude would probably complain of timeout).

 

larryvc wrote:

Yes, the bug seems to be that section 33.3.2.5 UPDI Communication Error Handling and/or 33.3.9 Sleep Mode Operation have not been implemented.  AS7 gives up at the first sign of a UPDI communication error, I do not believe that they have implemented any of the UPDI error handling protocols.

 

Indeed I did not implement either. I will at least implement sleep mode, or else MCUs in sleep mode will not be programmable.

 

larryvc wrote:

BOD is enabled.  VCC is a solid 5V. Sleep has not been enabled. 

 

Maybe taking VCC to its limit (5.5V) would help? The xtinys have a pre-brown-out (VLM) that activates at 5, 15 or 25% above brow-out. 4.3V plus 25% is ~5.4V. I have a feeling this might be related to the problem.

 

Last Edited: Tue. Mar 6, 2018 - 11:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
That means the UPDI ASI_SYS_STATUS register is 0x00. I've never seen that value returned during my testing. Normally it will be 0x82 to indicate the MCU is running, although both set bits are not documented in the current datasheet. Maybe I should also accept 0x00 as valid (?) It also means the UPDI is operating without communication errors, or else nothing would be returned (I did not implement an input timeout, but in practice random fluctuations would eventually cause something to be returned after some time. The long delay would be noticeable and avrdude would probably complain of timeout).

 

What does it return, if UPDI is not active ?

Seems if you disable UPDI and make pin reset-only, you must then use the 12V + break pulse I detailed above ?

 

I wonder if a UART handshake line to optocoupler_to_12V, or similar, can meet timing for the 12V pulse ?

 

larryvc wrote:
I do believe that somehow the chip is sleeping, o muerto :\, though it would be nice to have the tools to absolutely confirm this.

 

Do the fuses disable the UPDI ?

 

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

Who-me wrote:
Seems if you disable UPDI and make pin reset-only, you must then use the 12V + break pulse I detailed above ?
Nowhere was the UPDI pin made reset only, nor was this implied.  Reread the OP.  Info above is great for future reference. Thanks for responding, I missed that.

Who-me wrote:
Do the fuses disable the UPDI ?
Only if the fuses put the chip to sleep, but in this case I do not see how sleep would have been enabled, thus my comment that the chip may be dead.

 

No but special UPDI handling is required to enable UPDI communications if the chip is sleeping.  Read the datasheet for everything about UPDI.

 

EDIT: Misread the question, see El Tangas post below

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Wed. Mar 7, 2018 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who-me wrote:

 

What does it return, if UPDI is not active ?

Seems if you disable UPDI and make pin reset-only, you must then use the 12V + break pulse I detailed above ?

 

 

Disabling the UPDI pin is done with fuse SYSCFG0, which was not changed in this case. The worst case would be setting that pin as GPIO, an then the MCU software setting it as output. In that case you could not send the 12V pulse, it would burn the pin.

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

El Tangas wrote:
Maybe taking VCC to its limit (5.5V) would help? The xtinys have a pre-brown-out (VLM) that activates at 5, 15 or 25% above brow-out. 4.3V plus 25% is ~5.4V. I have a feeling this might be related to the problem.
Testing this now.

 

EDIT: Note that I have been receiving avrdude timeout complaints all along.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Wed. Mar 7, 2018 - 12:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
That means the UPDI ASI_SYS_STATUS register is 0x00.

 

0x00 does sound rather like a 'nothing there' reply - is the MCU driving the UPDI pin to send this ?

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

Who-me wrote:

0x00 does sound rather like a 'nothing there' reply - is the MCU driving the UPDI pin to send this ?

 

My software UART, which is connected to the UPDI, waits for a start bit (a one to zero transition), then samples 8 data bits. So, if a random fluctuation cause the pin to be zero it will indeed read 0x00 even if the UPDI is not sending anything.

This combined with avrdude complaining of timeouts tells me that the UPDI is in fact not responding.

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

I tried 5.5V and the problem remains.  I will keep the chip around for future attempts, perhaps future avrdude and AS7 UPDI programming software will be more robust.

 

The MCU is dead!  Long live the MCU!

 

Thanks El Tangas and who-me for your helpful insight.

 

 

 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

I think I understand what happened. I tested to see how does the generated ".fuse" section looks like using the code in the OP:

 

Contents of section .fuse:
 820000 00e60200 00000000 00

This seems quite a problem. The fuses that are not explicitly set all become 0x00, including, unfortunately, SYSCFG0. This results in the UPDI pin being configured as GPIO, among other things. So to unbrick the MCU, the 12V method will have to be used...

 

edit: I think Atmel really messed this one up. Lots of people will accidentally brick their xtinies and then can't bring them back. Few people have access to a 12V programmer that knows UPDI.

Last Edited: Wed. Mar 7, 2018 - 01:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

I think I understand what happened. I tested to see how does the generated ".fuse" section looks like using the code in the OP:

 

Contents of section .fuse:
 820000 00e60200 00000000 00

This seems quite a problem. The fuses that are not explicitly set all become 0x00, including, unfortunately, SYSCFG0. This results in the UPDI pin being configured as GPIO, among other things. So to unbrick the MCU, the 12V method will have to be used...

 

edit: I think Atmel really messed this one up. Lots of people will accidentally brick their xtinies and then can't bring them back. Few people have access to a 12V programmer that knows UPDI.

Exactly why I think we need to solve this one.  Think you're up to modifying your code to trigger the 12V circuit that who-me said he was designing? ;-)

 

​So we need to refer to who-me's post #5 at this stage and come up with a good method that is easy to implement both in software and hardware.  Consider this the How to Rescue your Bricked XTINY thread from now on.

 

BTW, In my haste I had not taken the time to map out the actual effects of the fuse values.  Thanks for bringing it up and reminding me.

 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Wed. Mar 7, 2018 - 07:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

I think I understand what happened. I tested to see how does the generated ".fuse" section looks like using the code in the OP:

 

Contents of section .fuse:
 820000 00e60200 00000000 00

This seems quite a problem. The fuses that are not explicitly set all become 0x00, including, unfortunately, SYSCFG0. This results in the UPDI pin being configured as GPIO, among other things. So to unbrick the MCU, the 12V method will have to be used...

 

edit: I think Atmel really messed this one up. Lots of people will accidentally brick their xtinies and then can't bring them back. Few people have access to a 12V programmer that knows UPDI.

 

Yup, a default of 0 for undefined, is clearly a serious oops, and they need to correct that asap...

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

larryvc wrote:

...  Think you're up to modifying your code to trigger the 12V circuit that who-me said he was designing? ;-)

 

I think the simplest circuit to test is an opto-coupler to +12V, with series signal R, and perhaps a clamp zener ?

The UART handshake line goes LOW to activate. Perhaps 5mA drive to a > 100% CTR opto ?

The Opto CTR acts as a natural current limiter, so you cannot damage a MCU driving low for example.

Most Vpp signals are just high-threshold gates, there is very little current involved.

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

Ok, protect the programmer side from the 12V with a Zener to ground? Or a Schottky to VCC? Or some other method?

 

edit: maybe I can just make the programmer pin output low during the 12 V pulse. The 4.7k resistor will allow just 2.5mA current from the 12V source, this is not a problem for an AVR pin, this way there are less parts.

 

edit2: I think this should do it:

 

Last Edited: Wed. Mar 7, 2018 - 04:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmh, so this is sort of in between the wood and the fire... 

 

Not filling out elements structs means that they will be default constructed. As per current GCC wording:

Omitted field members are implicitly initialized the same as objects that have static storage duration.

The elf will then contain 0s in the fields that was not initialized. When we get around to programming said elf, it clearly says to write 0.

 

This is how avr-libc has done it (and the same argument holds for every single AVR that uses the avr/fuse.h struct to initialize the fuse section). This issue is also spelled out in the manual:

You must initialize ALL fields in the __fuse_t structure. This is because the fuse bits in all bytes default to a logical 1, meaning unprogrammed. Normal uninitialized data defaults to all locgial zeros. So it is vital that all fuse bytes are initialized, even with default data. If they are not, then the fuse bits may not programmed to the desired settings.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Last Edited: Wed. Mar 7, 2018 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And what about the fuse at offset 0x03? It's not documented and factory value is 0xFF. Is it ok that it will always get programmed with 0x00?

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

meolsen wrote:

Hmh, so this is sort of in between the wood and the fire... 

 

Not filling out elements structs means that they will be default constructed. As per current GCC wording:

Omitted field members are implicitly initialized the same as objects that have static storage duration.

The elf will then contain 0s in the fields that was not initialized. When we get around to programming said elf, it clearly says to write 0.

 

This is how avr-libc has done it (and the same argument holds for every single AVR that uses the avr/fuse.h struct to initialize the fuse section). This issue is also spelled out in the manual:

You must initialize ALL fields in the __fuse_t structure. This is because the fuse bits in all bytes default to a logical 1, meaning unprogrammed. Normal uninitialized data defaults to all locgial zeros. So it is vital that all fuse bytes are initialized, even with default data. If they are not, then the fuse bits may not programmed to the desired settings.

Even with the hidden covering clause, this still looks fundamentally broken. The impact of this is large.

 

If the flow must assign 0, smarter might have been to call the section NOTfuse, so that 0 was treated as default/erased, and 1 is activate.

 

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

El Tangas wrote:

Ok, protect the programmer side from the 12V with a Zener to ground? Or a Schottky to VCC? Or some other method?

or, a series N-FET Logic level like NX138/BSS138/FDV301 etc can isolate and level shift.

 

El Tangas wrote:

edit: maybe I can just make the programmer pin output low during the 12 V pulse. The 4.7k resistor will allow just 2.5mA current from the 12V source, this is not a problem for an AVR pin, this way there are less parts.

 

edit2: I think this should do it:

I think you need to drive the opto LED, from a UART handshake line? - as 12V needs to pulse (nominally 100us to 1ms) then Break (10 – 200us) and then Sync. 

Data suggests 13.5ms max delay before for sync, so timing is tight.

 

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

meolsen wrote:
Not filling out elements structs means that they will be default constructed. As per current GCC wording:

Omitted field members are implicitly initialized the same as objects that have static storage duration.

The elf will then contain 0s in the fields that was not initialized. When we get around to programming said elf, it clearly says to write 0.

 

This is how avr-libc has done it (and the same argument holds for every single AVR that uses the avr/fuse.h struct to initialize the fuse section). This issue is also spelled out in the manual:

You must initialize ALL fields in the __fuse_t structure. This is because the fuse bits in all bytes default to a logical 1, meaning unprogrammed. Normal uninitialized data defaults to all locgial zeros. So it is vital that all fuse bytes are initialized, even with default data. If they are not, then the fuse bits may not programmed to the desired settings.

Thanks for that.

 

Why are the fuse defaults not defined in iotn1616.h, or is this something that has been deprecated without telling anyone that it has been, and why does the fuses macro not use those fuse defaults to fill the unspecified fields?  At least then if the user consciously specifies a wrong fuse setting then the blame is on the user.  That the fuses macro just blindly takes the fuses = values is just plain wrong.  Nobody should be using that macro without a big flag warning that asks do you really want to do that and only then provides a macro value to set to allow it to happen.  EDIT: I suppose that would be a tall order to fill, though in the interim a bolded large font note in the datasheet warning of the effects of changing the SYSCFG0 RSTPINCFIG bits would seem prudent. 

 

Written in the manual:

Each device I/O header file also defines macros that provide default values for each fuse byte that is available. LFUSE_DEFAULT is defined for a Low Fuse byte. HFUSE_DEFAULT is defined for a High Fuse byte. EFUSE_DEFAULT is defined for an Extended Fuse byte.

If FUSE_MEMORY_SIZE > 3, then the I/O header file defines macros that provide default values for each fuse byte like so: FUSE0_DEFAULT FUSE1_DEFAULT FUSE2_DEFAULT FUSE3_DEFAULT FUSE4_DEFAULT ....

For this case those would be: WDTCFG_ DEFAULT BODCFG DEFAULT OSCCFG_ DEFAULT RESERVED_ DEFAULT TCD0CFG_ DEFAULT SYSCFG0_ DEFAULT SYSCFG1_ DEFAULT APPEND_ DEFAULT BOOTEND_ DEFAULT. 

 

Re: "This is how avr-libc has done it..., maybe it is time to think about changing it so that Microchip customers don't have to jump through hoops to recover UPDI capability, or are Microchip planning on selling a $30 add on for the Atmel ICE, as a fix instead.devil

 

​I see this as a big problem for Microchip customers using devices that have UPDI.  You have to admit that when something like this happens to more and more Microchip customers, as it probably will, Microchip will need to provide them with a fix.  Anything more that Microchip can offer other than what we have already discussed above?

 

​Thanks for listening.

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Thu. Mar 8, 2018 - 12:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But notice:

When enabled by 12V, only a POR will disable the UPDI configuration on the RESET pin, and restore the default setting.

It seems the 12V pulse enables updi until the chip is powered down.

 

So, I've been thinking: maybe just manually jolting the updi pin with 12v will put it in updi mode (with programmer disconnected, of course).

Then, making sure the target is not power cycled, connect the programmer and see if it can establish a link.

Last Edited: Wed. Mar 7, 2018 - 07:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

But notice:

When enabled by 12V, only a POR will disable the UPDI configuration on the RESET pin, and restore the default setting.

It seems the 12V pulse enables updi until the chip is powered down.

 

So, I've been thinking: maybe just manually jolting the updi pin with 12v will put it in updi mode (with programmer disconnected, of course).

Then, making sure the target is not power cycled, connect the programmer and see if it can establish a link.

 

Worth trying...

You could even check a capacitor voltage doubler impulse ? - a simple DPDT switch, and 100nF/470R in series. On way it charges from 5V, the other way it adds to 5V to give 10V (briefly). 10V may be enough.

The series R and Zener could allow the programmer to stay connected ?

 

Perhaps a series switch to a RST pin, to remove any loads and Caps, can allow a finger-touch to fire the flip-flop you mention ? - but that is less precise...

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

The voltage is spec'd in the ds, in the section "External Reset Characteristics". It's 11.5 to 12.5V, so a simple doubler would not cut it.

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

El Tangas wrote:

The voltage is spec'd in the ds, in the section "External Reset Characteristics". It's 11.5 to 12.5V, so a simple doubler would not cut it.

 

Yeah, that's the target range (because 12V is a standard supply), but like HCMOS Logic, what actually matters is the threshold. That will be quite a bit lower. ( ~ 7.5V FWIR)

Last Edited: Wed. Mar 7, 2018 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas, are you also attempting to rescue a chip now?cheeky​ Starting to sound like you may have intentionally bricked one.

 

I have a separate issue with the bad chip, it is now overheating and no 12V testing has even begun yet.  Maybe the chip had started to self destruct to begin with.

 

I am willing to sacrifice another chip for the cause. and will report back soon to pick up from here.  Thanks again to both of you, great ideas and advice!

 

EDIT: self destruct

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Last Edited: Thu. Mar 8, 2018 - 01:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

larryvc wrote:
El Tangas, are you also attempting to rescue a chip now?cheeky​ Starting to sound like you may have intentionally bricked one.

 

It has crossed my mind, but not yet...

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

In case the simpler CAP doubler does not work, an alternative Vpp pulse  generator could be this L based design (attached image)

- Spice says these need to be reasonably good inductors.

Too much Rs, and that limits the current that can be injected before flyback, due to the forward diode action of D2.   (sub 200R is good, sub 100R is better)

At flyback, D1 clamps to 12V, duration is set by Inductor and Current

(L1+R1) is the inductor, and M1 can be a push-button, for manual 12k Kick (or driven from a handshake line for auto). R2 is optional, reduces ringing decay time.

 

Spice says values down to ~1.5mH will still give 12V, but the pulse width shrinks in proportion to L (other things being equal), and I expect there will be some minimum threshold time needed. Tests may reveal what that is ?

 

Addit: a Variant circuit added that allows higher Series R inductors - here a low cost 100mH/300R gives ~ 124us pulse.

 

Addit2 : Revised 100mH with better active rectifier design, auto-floats at end of impulse, slight improvement in time to ~ 137us pulse. (note 11V Zener + Vbe for 12V net )

Attachment(s): 

Last Edited: Mon. Mar 12, 2018 - 10:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the purpose of R2?

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

El Tangas wrote:

What is the purpose of R2?

Added in my edits, while you were typing.