AVR Freaks

Level: Raving Lunatic

Joined: Sun. Mar 25, 2007

Posts: 2238 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: 4206 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: 2238 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: 2919 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: 2919 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: 4206 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: 2919 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: 2238 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: 4206 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: 2919 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: 4206 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: 2238 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: 2919 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: 4206 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: 2919 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: 4206 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: 2238 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: 2238 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: 2919 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: 3483 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 Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Level: Raving Lunatic

Joined: Thu. Jul 14, 2016

Posts: 2919 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: 2238 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: 2238 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: 4206 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: 2919 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: 2238 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: 2919 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: 2238 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: 4206 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: 2919 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: 2238 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: 2919 View posts

#34

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

What is the purpose of R2?