UPDI speed

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

So my compiled code has 8 kB size. I'm programming the ATtiny1614 via UPDI with pyupdi and the recommended wiring, with a USB-Serial adapter FT232RL. The default speed is 115200 baud and the max. working that I am using is 230400 baud (there is no documentation whatsoever anywhere so I had to guess the actual baudrate to use). It takes a long time to complete, around 10 to 20 seconds. And often it fails. The whole thing is a highly unstable process. Very frustrating.

 

Then I've seen a video from Atmel where they demonstrate their touch demo board. They flash the chip at maximum speed (in the Mbaud range I guess) and that 8 kB demo program is flashed in just 1 or 2 seconds! How did they do that? A different protocol? I think new ATtinys only have UPDI.

 

Then I read the datasheet. It actually suggests max. 225 kbps at the default 4 MHz UPDICLKSEL setting. I guess I could set it to 8 MHz which would allow 450 kbps. But how am I supposed to do that? There's a register for that, but I'm not in the position to execute any code that would write to registers. I want to copy my application code onto the device, not run some connection configuration app on it. I don't get what that UPDICLKSEL thing is about. Can somebody please explain? And is there any way to speed up that process and/or make it more robust so that it doesn't fail that often?

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

ygoe wrote:
How did they do that?
mEDBG

https://youtu.be/dpKJYs4Mlto?t=243

ygoe wrote:
A different protocol?
UPDI bridge from USB HID

ygoe wrote:
But how am I supposed to do that?
baudrate?

https://pythonhosted.org/pyserial/pyserial_api.html#serial.Serial.baudrate

 

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

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

pyupdi is reading back the entire flash to verify which takes twice as long as just writing. These new chips can be verified by just reading the CRC of flash which is much quicker.

 

You can access the UPDI registers through the UPDI interface. In fact, you can access registers, RAM, Flash and EEPROM with the UPDI interface.

 

The phyisical layer of UPDI is new, but the access layer is the same as PDI in the XMegas. PDI is well documented in various projects and app notes.

 

 

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

That's because pyupdi uses a very conservative timing. You can try to speed it up by going to the link.py file, in the init() function you have this line:

 

 self.stcs(constants.UPDI_CS_CTRLA, 1 << constants.UPDI_CTRLA_IBDLY_BIT)

 

replace by

 self.stcs(constants.UPDI_CS_CTRLA, (1 << constants.UPDI_CTRLA_IBDLY_BIT) + 0)

Then, increase that zero to 1, 2 3,... up to 7 it will get faster and faster and probably less and less stable (that number is GTVAL on the UPDI CTRLA register). You could also try to change the first 1 to zero to disable the inter-byte delay.

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

gchapman wrote:

mEDBG

What exactly is that? I can't find information that describes it and lets me decide whether I have that or can use it.

 

Quote:

UPDI bridge from USB HID

What does that mean?

 

Exactly: not a single value. I've found recommended/common values of up to 115200, then it seems to double, but there is also a different series of baudrates. The AVR needs to support it, the USB-Serial adapter needs to support it, pyupdi may have a word to speak as well, or can I just make up values like 181937?

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

 

Exactly: not a single value. I've found recommended/common values of up to 115200, then it seems to double, but there is also a different series of baudrates. The AVR needs to support it, the USB-Serial adapter needs to support it, pyupdi may have a word to speak as well, or can I just make up values like 181937?

 

 

The FT232 chip has a fractional buadrate generate which will support almost any arbitrary speed. The UPDI interface also has a fractional baudrate generator which can handle almost any arbitrary speed. The UPDI will autodetect the baudrate from the SYNCH characters sent by the programmer.

Last Edited: Thu. Feb 13, 2020 - 10:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to correct my numbers. After counting the seconds more carefully, the smaller 4k program takes 20 seconds and the larger 8k program takes 40 seconds to flash.

 

So if pyupdi doesn't use the CRC verify function, can I enable it somehow, or will it have to be implemented in pyupdi first? Is that complicated? I don't understand much Python unfortunately.

 

El Tangas wrote:

(...)

Then, increase that zero to 1, 2 3,... up to 7 it will get faster and faster and probably less and less stable (that number is GTVAL on the UPDI CTRLA register). You could also try to change the first 1 to zero to disable the inter-byte delay.

 

I did that, all the way up to 7, and then the left value to 0. None of it had any effect. It always took the same time and was equally stable. Today it worked more often, but I had to un-power the chip after an error a few times in a row before it finally worked.

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

Really? Oh, I see there are other places in the code that change CTRLA

 

    def st_ptr_inc16(self, data):
        """
            Store a 16-bit word value to the pointer location with pointer post-increment
    
            Disable acks when we do this, to reduce latency.
        """
        self.logger.info("ST16 to *ptr++")
        ctrla_ackon = 1 << constants.UPDI_CTRLA_IBDLY_BIT # with acks enabled.
        ctrla_ackoff = ctrla_ackon | (1 << constants.UPDI_CTRLA_RSD_BIT) # acks off. (RSD)
        # (Response signature disable)
        self.stcs(constants.UPDI_CS_CTRLA, ctrla_ackoff)
        self.updi_phy.send([constants.UPDI_PHY_SYNC, constants.UPDI_ST | constants.UPDI_PTR_INC |
                            constants.UPDI_DATA_16] )
        self.updi_phy.send(data) # No response expected.
        # Re-enable acks
        self.stcs(constants.UPDI_CS_CTRLA, ctrla_ackon)

 

See if adding 0-7 to the highlighted lines does anything.

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

ygoe wrote:
What exactly is that?
mEDBG is EDBG on a mega32U4 (Xplained Mini) instead of an AVR32 UC3 (Atmel-ICE, Xplained Pro)

edit2 : or SAME70 (MPLAB PICkit4, MPLAB Snap)

ygoe wrote:
What does that mean?
A bridge links two physical interfaces (USB, UPDI); EDBG goes via USB HID for programming and debug.

ygoe wrote:
... or can I just make up values like 181937?
Possibly yes as some USB UART and USB MCU UART have FBRG such than that atypical baud will exist.

 


Mini Embedded Debugger | ATtiny817 Xplained Mini

EDBG-based Tool Implementations | Embedded Debugger-Based Tools Protocols User's Guide

MPLAB® PICkit™ 4 Debugger Block Diagram - Developer Help

FBRG - Fractional Baud Rate Generator

edit3 :

Standalone mEDBG UPDI programmer and issues with Avrdude | AVR Freaks

edit4 :

https://www.avrfreaks.net/forum/mplab-snap-feb20#comment-2845976

 

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

Last Edited: Fri. Feb 14, 2020 - 05:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote a patch to pyupdi.py which significantly speeds it up by disabling acks for each block, mraardvark merged this patch last year. I assume you are using the latest version, which has that patch.

 

I am sure there is still a lot of scope for improvement, I noticed that the official Atmel tools (the attiny xplained boards) do flash much faster. This might be because their serial port has a lot less latency - they've got another avr chip in there running the programmer, rather than speaking updi directly.

 

I've also noticed that different seemingly identical USB-serial dongles seem to give different performance, I've not investigated this too much.

 

There is potentially a lot of sensitivity to latency on the usb stack, OS, and the serial dongle itself. Try a few different usb-serial dongles, and possibly, if you're running Windows, try using Linux, it might be better (or indeed, worse). Myself, I usually use a Linux VM in Windows, which probably the worst solution. Try a different USB port in the same machine, if it has several controllers.

 

Finally, maybe try a Raspberry Pi's uart port instead of a usb-serial (I've not tried that one myself)

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

Perhaps focus on the reported "instability" first and then try to make it faster.  Do you get verify errors, or transmission failures when it fails?  Do share details.

 

In the end one of the xEDBG/Atmel-ICE tools will be much faster than pyupdi at doing operations like polling a ready bit in the NVM controller simply due to stack latency through to the host... 

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

Right now, it looks like mplab spends more time trying to decide whether it’s going to upgrade your firmware (eg for SNAP) than the “slow” programming  time you are reporting...

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

westfw wrote:
Right now, it looks like mplab spends more time trying to decide whether it’s going to upgrade your firmware (eg for SNAP) than the “slow” programming  time you are reporting...

Hehe.  What about if you select the "don't upgrade my firmware" option in the project properties?