AVR Freaks

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#3

Posted by Who-me: Tue. Mar 6, 2018 - 05:32 AM

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 ?

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#4

Posted by larryvc: Tue. Mar 6, 2018 - 05:45 AM (Reply to #3)

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 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

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#5

Posted by Who-me: Tue. Mar 6, 2018 - 08:23 AM

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 ?

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#6

Posted by El Tangas: Tue. Mar 6, 2018 - 09:59 AM

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...

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.

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#7

Posted by El Tangas: Tue. Mar 6, 2018 - 10:34 AM

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

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#8

Posted by larryvc: Tue. Mar 6, 2018 - 05:04 PM (Reply to #7)

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

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#9

Posted by El Tangas: Tue. Mar 6, 2018 - 11:12 PM (Reply to #8)

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

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#10

Posted by Who-me: Tue. Mar 6, 2018 - 11:44 PM

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 ?

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#11

Posted by larryvc: Wed. Mar 7, 2018 - 12:17 AM (Reply to #10)

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

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#12

Posted by El Tangas: Wed. Mar 7, 2018 - 12:18 AM

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.

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#13

Posted by larryvc: Wed. Mar 7, 2018 - 12:27 AM

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

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#14

Posted by Who-me: Wed. Mar 7, 2018 - 12:33 AM

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 ?

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#15

Posted by El Tangas: Wed. Mar 7, 2018 - 12:40 AM

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.

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#16

Posted by larryvc: Wed. Mar 7, 2018 - 12:59 AM

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

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#17

Posted by El Tangas: Wed. Mar 7, 2018 - 01:38 AM

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

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#18

Posted by larryvc: Wed. Mar 7, 2018 - 07:11 AM (Reply to #17)

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

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#19

Posted by Who-me: Wed. Mar 7, 2018 - 07:28 AM

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...

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#20

Posted by Who-me: Wed. Mar 7, 2018 - 07:33 AM

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.

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#21

Posted by El Tangas: Wed. Mar 7, 2018 - 11:58 AM

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

meolsen

Level: Site Admin

Joined: Wed. Jul 27, 2011

Posts: 3823 View posts

Location: Microchip, Arizona

#22

Posted by meolsen: Wed. Mar 7, 2018 - 02:03 PM

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 Microchip, yes, I do this in my spare time, now stop sending PMs)

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Wed. Mar 7, 2018 - 02:05 PM

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#23

Posted by El Tangas: Wed. Mar 7, 2018 - 02:16 PM (Reply to #22)

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?

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#24

Posted by Who-me: Wed. Mar 7, 2018 - 06:50 PM

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.

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#25

Posted by Who-me: Wed. Mar 7, 2018 - 07:06 PM

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.

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#26

Posted by larryvc: Wed. Mar 7, 2018 - 07:44 PM (Reply to #22)

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.

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

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#27

Posted by El Tangas: Wed. Mar 7, 2018 - 07:54 PM

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

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#28

Posted by Who-me: Wed. Mar 7, 2018 - 08:07 PM

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...

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#29

Posted by El Tangas: Wed. Mar 7, 2018 - 08:39 PM

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.

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#30

Posted by Who-me: Wed. Mar 7, 2018 - 09:00 PM

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

Level: Raving Lunatic

Joined: Thu. Dec 6, 2007

Posts: 4229 View posts

Location: Redmond, WA, USA

#31

Posted by larryvc: Wed. Mar 7, 2018 - 09:51 PM

El Tangas, are you also attempting to rescue a chip now? 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

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#32

Posted by El Tangas: Wed. Mar 7, 2018 - 10:14 PM

larryvc wrote:

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

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

12V_Vpp_impulse_12Z_PNPr.PNG

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#33

Posted by Who-me: Thu. Mar 8, 2018 - 03:39 AM

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):

12V_Vpp_impulse.PNG

Last Edited: Mon. Mar 12, 2018 - 10:02 PM

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#34

Posted by El Tangas: Wed. Mar 7, 2018 - 11:56 PM

What is the purpose of R2?

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2348 View posts

#35

Posted by Who-me: Thu. Mar 8, 2018 - 12:25 AM

El Tangas wrote:

What is the purpose of R2?

Added in my edits, while you were typing.

vignesh724452

Level: New Member

Joined: Sun. Oct 11, 2020

Posts: 18 View posts

#36

Posted by vignesh724452: Fri. Dec 4, 2020 - 05:21 PM

Hiiii,
I'm trying to upload fuse setting by the application itself, but i'm failing, i attached the code section below, can anyone guide me ???

#define F_CPU 3333333
#include <avr/io.h>
#include <avr/delay.h>

FUSES = {
   .WDTCFG = 0x0a, // Watchdog Configuration (period mode with 4 second approximately)
   .BODCFG = 0, // BOD Configuration
   .OSCCFG = 0x02, // Oscillator Configuration
   .TCD0CFG = 0, // TCD0 Configuration
   .SYSCFG0 = 0xC4, // System Configuration 0
   .SYSCFG1 = 0x07, // System Configuration 1
   .APPEND = 0, // Application Code Section End
   .BOOTEND = 0 // Boot Section End
};

void beep()
{
   PORTA.OUT |= 0X08;
   _delay_ms(50);
   PORTA.OUT &= ~0X08;
}

int main()
{
   PORTA.DIR |= 0X08;// buzzer pin activation
   while(1)
   {
       beep();
       _delay_ms(2000);
       beep();
       while(1);
   }
}

as per my understanding i'm configuring wdt in period mode with 4 second period, then the main code executes 2 beep sound, then it'll stuck in while(1), but i started the wdt so it has to reset the controller so that i can make my code execute continously,

but my results are not as i expected, the 2 beep sound is getting executed, after that the code gets stuck in while(1),
i even tried turning off & on the controller, because i have read that fuses will get into action only after a reset, even this doesn't helping me..

vignesh

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#37

Posted by El Tangas: Fri. Dec 4, 2020 - 10:54 PM

How exactly did you upload the fuses? Read them with avrdude, to see if they are correct.

Level: New Member

Joined: Mon. Dec 21, 2020

Posts: 5 View posts

#38

Posted by dduehren: Mon. Dec 21, 2020 - 07:13 AM

What is the current status/understanding of these issues. I have recently started working with an ATtiny1604 and have bricked 4 of 5 and I'm trying to figure out both a) How to stop doing that and b) how to recover the ones I have bricked.

I followed the basic outline of these two: http://www.technoblogy.com/show?... and https://github.com/SpenceKonde/m... whose advice varies from that of El's at https://github.com/ElTangas/jtag....

If I follow El's advice, I have problems because I had Vtarg>Vprog (5.4V to 5V) and/or did not use the UNO 5V to program the targ. In addition I did not disable the auto-reset feature on the UNO after downloading the program. Note it would be good to understand why this is necessary. Finally there's a difference between Spence Konde and El over the value of the resistor" 4.7K vs 470 ohms.

So for part a), some clarification on how to program these devices without bricking them right away, or shortly after. and b) What is the status of trying to unbrick them with a 12V pulse.

Along those lines, what do you think of these posts: http://nerdralph.blogspot.com/20... and https://www.electronics-lab.com/...

David Duehren
Old Guy Doing Hacking and More

Level: New Member

Joined: Mon. Dec 21, 2020

Posts: 5 View posts

#39

Posted by dduehren: Mon. Dec 21, 2020 - 07:49 AM

A few more questions as I've continued to research this. I'm a newbie with these parts, and not too advanced in Arduino development. I've been programming it via the Arduino IDE and have not yet tackled avrdude to be able to try the -e option and erase these chips. Do you think that will work? And what version of jtag2updi should I download for a 1604/1614 chip.

Thanks,

David Duehren

David Duehren
Old Guy Doing Hacking and More

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#40

Posted by El Tangas: Mon. Dec 21, 2020 - 03:14 PM

dduehren wrote:

I have recently started working with an ATtiny1604 and have bricked 4 of 5 and I'm trying to figure out both a) How to stop doing that and b) how to recover the ones I have bricked.

To brick them you need to change the SYSCFG0 fuse. Sometimes it's changed inadvertently, as in the first post of this thread; you omit the value and this causes it to be zero -> bricked.

To recover the bricked ones, you will need to use high voltage programming. A simple 12V pulse worked (sometimes) for older hardware, but not for recent chips.

You could try this fork of jtag2updi: https://github.com/Dlloydev/jtag2updi by Dlloydev, which supports HV programming.

The erase option will only work if the "bricking" is caused by the chip being locked. But -e won't work on locked chips because of a bug. Use -F -t, to force enter terminal mode, then enter the "erase" command.

dduehren wrote:

In addition I did not disable the auto-reset feature on the UNO after downloading the program. Note it would be good to understand why this is necessary.

Actually it's not. I thought it was earlier and the idea just took over, even though I corrected it later.

dduehren wrote:

Finally there's a difference between Spence Konde and El over the value of the resistor" 4.7K vs 470 ohms.

This is not very important. In fact you can just remove the resistor, it's just for safety (to protect the pins from overcurrent in case of some bug causing a data collision in the UPDI line).

Level: New Member

Joined: Mon. Dec 21, 2020

Posts: 5 View posts

#41

Posted by dduehren: Mon. Dec 21, 2020 - 06:50 PM (Reply to #40)

Raving Lunatic wrote

To brick them you need to change the SYSCFG0 fuse. Sometimes it's changed inadvertently, as in the first post of this thread; you omit the value and this causes it to be zero -> bricked.

I'm using the Arduino IDE and it's not clear to me where to make sure it set. Or do I go to the avrdude process for more control? I went through the list presented, and I'm keeping the UPDI pin as UPDI. Is there somewhere in the code that this is done that I could change?

Thanks for the response, I'm looking into 12V reprogramming too.

David Duehren
Old Guy Doing Hacking and More

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 3433 View posts

#42

Posted by El Tangas: Mon. Dec 21, 2020 - 08:32 PM

Well, if you are using the Arduino IDE, that means the MegaTinyCore in this case. It should be quite safe, I really can't understand what went wrong. Do you set any fuses in your code using a FUSES structure (like on post #1 on this thread)?

Level: New Member

Joined: Mon. Dec 21, 2020

Posts: 5 View posts

#43

Posted by dduehren: Tue. Dec 22, 2020 - 04:55 AM (Reply to #42)

I have no FUSES structure anywhere. I checked the jtag2updi code and it doesn't have anything in it. I'm a bit spooked now in trying to program another one because there doesn't seem to be rhyme or reason for what happens. My setup is very simple. I have a separate board with ATtiny1604 on a breakout board plugged in. I have programmed both with the Arduino 5V supply as well as a separate 5V supply that runs a bit high (5.4V). I have 470 ohm resister from Pin 6 of the UNO to the UPDI pin of the 1604. And I have been using the Blink code to test if the code was downloaded properly.

My last run, I was very careful, got the Blink program downloaded, blinking away. Removed the programmer. Powered on and off a couple of times - I was testing to see if I needed to use a POR chip to guarantee startup on powerup. All seemed fine. I left it for a few hours and plugged power on again and it just sat there. I tried to reprogram it, but got the notorious

RSP_ILLEGAL_MCU_STATE

It was at that point that I started to search for what I may be doing wrong and how to fix the chips. But so far, the only thing that I can see may be a problem is that my voltage at 5.4 volts maybe a bit hot. Meanwhile I'm looking into building the circuit to reset the fuses.

David Duehren
Old Guy Doing Hacking and More

12oclocker

Level: Hangaround

Joined: Sun. Apr 19, 2009

Posts: 365 View posts

#44

Posted by 12oclocker: Tue. Dec 22, 2020 - 06:43 AM

I created a 12-volt programmer for updi and I can tell you that the datasheet explanation for 12 volt programming timing is flat out wrong. It took a long time and lots of trial and error to get the timing correct for 12 volt programming to work every time.
recent chips are much more picky about the timing.
Basically the pulse of 12 volts has to occur at certain time after boot and it must be a specific length, the pulse must also occur at a specific point in time directly before the updi commands as well, if all that timing is not correct, updi will not enable and you will not get back in.
Their absolutely is a way to make it work every time flawlessly, I also have a schematic for safely applying the 12 volt pulse, I am out on holiday but when I get back to my office I will post up the data for it.

Last Edited: Tue. Dec 22, 2020 - 07:05 AM

12oclocker

Level: Hangaround

Joined: Sun. Apr 19, 2009

Posts: 365 View posts

#45

Posted by 12oclocker: Tue. Dec 22, 2020 - 08:18 PM

ok, this is directly from my UPDI 12v programmer, it works 100% of the time on every TinyAvr0 TinyAvr1 variant I have tested, even the new chips that are more picky on timing...

1) UPDI programmer must be open collector output design and must have 15K pull-up resistor (to slave MCU pwr)!

2) The 12v pulse must be 1ms, then release the 12v and let the 15K pull-up to MCU VCC for 5ms, then immediately send the UPDI programming commands.

3) If you are using the pin as a GPIO see my NOTE below in the code section.

Some may have noticed "I can program my UPDI without a pull-up, the slave AVR has a pull-up in the UPDI internal circuit" that may be true when NOT using HV programming, but the internal circuit pull-up for the slave MCU being programed at 12v has issues recovering from a 12v pulse, maybe the internal resistance is too high and maybe to much pin capacitance inside the AVR, whatever the reason, if you do not use an open collector design with 15K pull-up on your programmer for HV programming, you will not have a 100% success rate on all your TinyAvr0/1's that you program.

// NOTE:
// UPDI must be open collector design and must have 15K pullup
// resistor to 3.3v or 5v, whatever your MCU supply is!
// 12v pulse will overpower the pullup resistor just fine.
//
// if your device uses the UPDI pin as GPIO, you must measure another
// pin on the scope to see when the device powers up.
// then you must also measure the UPDI pin to see when it turns into a GPIO
// between those two times is when you nail it with the high edge of the 12v pulse
pwm_on(); _delay_ms(100); //init the charge pump pwm, give it time to charge up to 12v
mcu_on(); _delay_us(XX);  //power up the mcu we are programming, see note above.
HIV_ON;   _delay_ms(1);   //1ms is max recommended according to datasheet
HIV_OFF;  _delay_ms(5);   //datasheet says 0.1ms, but that almost never works, 5ms works every time.
pwm_off();                //turn off charge pump (saves battery life if we are running on battery)
updi_prog();              //program the slave TinyAvr0/1 chip now

Last Edited: Tue. Dec 22, 2020 - 08:36 PM