UDPI interface can't be disabled in ATtiny817

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

In Atmel Studio 7.0.2594 I trying to disable the IDPI interface by writing 0xF3 to the SYSCFG0 fuse register. After pressing the Program button, I see a message "Write registers..OK", but reading the fuse registers shows that the register SYSCFG0 has not changed its value and contains 0xF7.

 

How else I can switch PA0 pin to GPIO mode?

Last Edited: Wed. Sep 14, 2022 - 01:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Welcome!

 

Reset, cycle power, etc.

Configuration and User Fuses (FUSE) | tinyAVR® 1-series

 

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

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

gchapman wrote:

Welcome!

 

Reset, cycle power, etc.

Configuration and User Fuses (FUSE) | tinyAVR® 1-series

 

Thanks for answering my question!

 

What is the right way to do a reset in this case so that the recorded fuse configuration is saved correctly?

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

Fuse data is saved though latched during exit of reset.

Configuration and User Fuses (FUSE) | tinyAVR® 1-series

[second sentence]

The fuses are available from the device power-up.

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

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

gchapman wrote:

Fuse data is saved though latched during exit of reset.

Configuration and User Fuses (FUSE) | tinyAVR® 1-series

[second sentence]

The fuses are available from the device power-up.

 

In my case, after reset or power-up, the fuses retain their previous values. I tried to flash the fuses from the code. Something like

 

const char fusedata[] __attribute__ ((__used__, __section__ (".fuse"))) = {0x00, 0x00, 0x02, 0x00, 0xF3, 0x07, 0x00, 0x00};

 

Didn't find enough documentation on this for 1-series and not sure about the correct sequence of fuse values. But the first attempt firmware led to blocking the chip.

 

 

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

Are you using a Kit by any chance?

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

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

meolsen wrote:

Are you using a Kit by any chance?

 

I use a ATtiny817 Xplained Kit as a programmer and debugger:

 

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

LogikPlus wrote:
meolsen wrote:
 Are you using a Kit by any chance? 

I use a ATtiny817 Xplained Kit as a programmer and debugger 

3.2.2 mEDBG Fuse Filter
(DS50002657B-page 7)

 

The truth is more important than the facts. (Frank Lloyd Wright / Unsourced)

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

The SUFFER-register always make me smile :-)

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

What are you trying to do?

 

It looks as if you just want to program/debug an external UPDI  chip using the mEDBG device from your Xmini-817 board.

 

In which case you physically disconnect the Tiny817's updi pin.

And connect the mEDBG to the external chip.

 

You might be able to disable the Xmini Tiny817 in software.

But a simple hardware jumper to select internal t817 or external UPDI chip is much more reliable.

 

I am pretty certain that the Xmini manual explains how to use mEDBG externally.

If you confirm that that is what you want,  I will test it myself with an Xmini-817 and external mega4208 chip.

 

David.

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

And once UPDI is disabled, I hope you have thought about getting back in again. 

The Xplained Mini by default prevents this action as it does not have the means (high-voltage) to get back in,

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


Looking at the XMINI-817 PDF

Disconnect UPDI link.   Solder a 2-pin header strip to empty pcb header pads e.g. R7, Q7.   Run two small wires from your "disconnected" UPDI link to R6, Q6.

Now you can mount a jumper link to enable the internal Tiny817 or a Dupont cable to your external chip.

 

Your photo in #7 looks like a yellow jumper-link enabling internal Tiny817

I can't see what your Blue jumper cable is doing.   But you only want one UPDI device listening at any one time.

 

As mraardvark has explained,  several "features" are disabled on the XMINI.

The hardware option is not too difficult.  

 

You might even choose to put a standard 3x2 on the user area e.g. P3-N4.   Then you can use a regular 6-way ribbon to your target chip.

 

Oh, you have to tell AS7.0 to accept external targets for the mEDBG.

 

David.

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

https://www.jsykora.info/2019/04...

 

here is some more info

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

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

I was intrigued.  So I followed my advice in #12.

In AS7.0  Tools (Main Menu) -> Options ... -> Tools -> Hide Unsupported Device -> False

 

Connected UPDI from mEDBG R7.  VCC, GND from the XMINI 3x2 SPI header.

AS7.0 Ran mEDBG->Device Programming.  Selected AVR128DA28 s target.   Read Signature correctly.

 

However Flash programming failed in AS7.0

Flash programming failed in Arduino DXCore.

Subsequent attempts to read the Signature failed in AS7.0

 

I suspect that someone, somewhere has got mEDBG from XMINI-817 working ok.

It should be easy enough to implement simple UPDI programming on XMINI or any Arduino.

 

But the real attraction is to have full Debug facilities in AS7.0

 

If this is a serious hobby,  buy a SNAP, PK4, ATMEL-ICE, ... you will get fast programming and debug.

The nEDBG on Curiosity boards should work fast.   A much safer bet than mEDBG.  But I have not tried it with external chips.

 

David. 

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

mEDBG predates the Dx family significantly, and was never meant to access >32k flash, so it simply won't work on that DB... but of course it will try, and manages at least to read the signature... It should work for tiny0, 1, and 2 though.

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

I only have ATmega4808, AVR128DA28, AVR128DB28 as bare UPDI chips.

I would need to buy some bare XTiny chips.

 

I still reckon that SNAP is a better way to go.  SNAP supports all of the "Atmel" chips as well as "PIC".   And should be future proof.

Last Edited: Sun. Sep 18, 2022 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

je_ruud wrote:

The SUFFER-register always make me smile :-)

 

I appreciated your sarcasm, but I am more important with ARM :-)

 

david.prentice wrote:

What are you trying to do?

 

Thanks for the answer! I am trying to switch Pin PA0 from UDIP mode to GPIO mode. The programmer itself works well, with a debugging and firmware there were no surprises.

 

 

mraardvark wrote:

And once UPDI is disabled, I hope you have thought about getting back in again. 

The Xplained Mini by default prevents this action as it does not have the means (high-voltage) to get back in,

 

I'm not going to turn on the UDPI again, because firmware already written in the final version using PA0 due to lack of pins.

 

david.prentice wrote:

Your photo in #7 looks like a yellow jumper-link enabling internal Tiny817

I can't see what your Blue jumper cable is doing.   But you only want one UPDI device listening at any one time.

 

You're right, the yellow jumper allows to switch between internal and external devices.

 

avrcandies wrote:
here is some more info

 

Thanks

Last Edited: Mon. Sep 19, 2022 - 12:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LogikPlus wrote:

I'm not going to turn on the UDPI again, because firmware already written in the final version using PA0 due to lack of pins.


People often want to steal a programming pin for GPIO.  Especially from 8-pin devices.   Seldom required for your 20-pin chip.

There are several tips and tricks for sharing GPIO pins.   In other words avoiding the urge to steal a pin (and subsequent difficulties)

 

Yes,  you can do it but it effectively means OTP One Time Programming)

Much easier to share GPIO or choose a better endowed  package.

 

What does the Blue jumper cable do ?

 

David.

 

p.s. it made me experiment with external target for mEDBG.   I possess both ATMEL-ICE and SNAP.   So I have never needed to try mEDBG.

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

david.prentice wrote:

People often want to steal a programming pin for GPIO.  Especially from 8-pin devices.   Seldom required for your 20-pin chip.

 

In the project, it is necessary to change the state of 8 pins at the same time (desynchronization is unacceptable). The chip itself was chosen due to features, size and price.

 

david.prentice wrote:

Yes, you can do it but it effectively means OTP One Time Programming)

 

I agree, looks pretty funny)))

 

david.prentice wrote:

What does the Blue jumper cable do ?

 

The blue wire is UDPI. The wires were selected quickly without paying attention to the colors. So for example, yellow and green are +3.3V and GND.

 

 

Do I understand correctly that I need to change the state of the programmer fuses to allow changes to critical device fuses?

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

Ah-ha.  If you want a full port then you are stuck with PORTA.   And making PA0 as GPIO.

 

I still reckon that there will be a trick in software.  Do you really need to change 8-pins in 50ns ?

It does not take long to write PA1-PA7 with a single OUT and PC0 with a SBI/CBI on any AVR.

 

But you might be able to use Event or CCL to "do it in hardware"

 

David.

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

LogikPlus wrote:
Do I understand correctly that I need to change the state of the programmer fuses to allow changes to critical device fuses?

Yes - the mEDBG will try its best to prevent users shooting their own feet, for example by disabling UPDI.  There is a register in the debugger called SUFFER which can be manipulated to disable this:

read: http://ww1.microchip.com/downloa...

I can't remember the exact process to do this, but hopefully someone will... 

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

david.prentice wrote:

I still reckon that there will be a trick in software.  Do you really need to change 8-pins in 50ns ?

 

To save energy, a low frequency is used. This leads to large delays between switching, which is unacceptable within the terms of reference.

 

mraardvark wrote:

Yes - the mEDBG will try its best to prevent users shooting their own feet, for example by disabling UPDI.  There is a register in the debugger called SUFFER which can be manipulated to disable this:

 

Thank you very much! Apparently I missed this part of the documentation. I'll try to find a ready script.

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

LogikPlus wrote:
There is a register in the debugger called SUFFER which can be manipulated to disable this

 

Indeed - I could not remember the process... but seemingly left some breadcrumbs in github :|

 

https://github.com/mraardvark/py...