UPDI programmer - pymcuprog vs ElTangas jtag2updi

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

Hello

 

For several years now I've been using ATMega microprocessors, so this is the first time I'm using ATTiny which is programmed with UPDI programmer. I'm not going to buy Atmel's ICE programmer. There are two other popular ways. One is USB to UART adapter directly into MCU, using pymcuprog script. Other is using arduino nano, flashing jtag2updi code there and using it as a programmer.

 

Can anybody tell me what are advantages and disadvantages of both methods? pymcuprog seems very very simple, but usually when things are simple there's a big disadvantage there.

Last Edited: Wed. Mar 16, 2022 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not a jtagi2updi user, but I am I pymcuprogger... but mostly "native" mode (not serial).

Still, I can share some insight:

 

Some drawbacks:

- python can be a hassle and dependency management a pain if you make some bad choices along the way

- pymcuprog by serial port is slow as the round-trip is long via python.

- it can depend on the serial adapter - i have heard that some are better than others

 

Some plusses:

- pymcuprog can both do updi via curiosity nano / atmel-ice (as a future upgrade) as well as serial port using the same python-based CLI.

- if you already use python, you can use pymcuprog as a "backend" and call it from other python code

- pymcuprog is a Microchip product and should get new device support before you can even get the device

 

If you have a serial adapter already, why not just give it a try?

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

i14r10 wrote:
There are two other popular ways.
Three (a variant of jtag2updi that's on a USB SAM)

ArduinoCore-megaavr/firmwares/MuxTO at master · arduino/ArduinoCore-megaavr · GitHub

 

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

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

Thanks. I have a serial adapter and I will try it. What's interesting is that there aren't any ready to use cheap programmers like usbasp. 

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

Interesting, but the prices of Arduino Uno wifi are pretty high and I couldn't find cheap chinese clones.

Last Edited: Thu. Mar 17, 2022 - 07:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

Ah, ok. I only searched for Uno wifi rev2 as written in the link. Aliexpress nanos have 328p on them.

 

gchapman wrote:

Arduino Nano Every — Arduino Online Shop

Inexpensive mega4808 boards have a WCH USB UART.

Nano Every use ATmega4808 | Page 2 | AVR Freaks

 

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

The development version of Avrdude now supports "pymcuprog-style" programming. 

https://github.com/avrdudes/avrdude

 

Avrdude calls this programmer option serialupdi.

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

MCUdude wrote:

The development version of Avrdude now supports "pymcuprog-style" programming. 

https://github.com/avrdudes/avrdude

 

Avrdude calls this programmer option serialupdi.

 

Thanks, I'll look into it, I already use avrdude.

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

MCUdude wrote:

The development version of Avrdude now supports "pymcuprog-style" programming. 

I'm assuming (hoping) "pymcuprog-style" means avrdude can talk in the UPDI protocol directly via a USB/serial adapter.

 

In principle that would be the best option. Since mraardvark already mentioned the shortcomings of his program, I'll mention the problems of jtag2updi.

Basically there is one: by it's own nature, jtag2updi is a translation layer from the jtagice mk2 protocol to the UPDI protocol.

This means there is about 2x data traffic compared to what a software that talks UPDI directly can achieve. Plus the translation/error checking overhead, which is not much really.

Now, pymcuprog talks UPDI but can't really achieve theoretical speed because it's written in python, but avrdude might.

 

At the time I wrote jtag2updi, avrdude could not talk UPDI and it's development was stalled, so I didn't expect it ever would.

If this new avrdude feature is working well, I fully expect it to become adopted as the preferred method, as far as low cost UPDI programming is concerned.

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

I'm assuming (hoping) "pymcuprog-style" means avrdude can talk in the UPDI protocol directly via a USB/serial adapter.

Correct. It incorporates most of the improvements found in the SerialUPDI version bundled with DxCore, mainly improved speed.

After the project was moved from Savannah to Github, lots of new volunteers have started to contribute to the project, myself included.

I'd argue that the project is highly active again, and new volunteers that can help out with the reported issues are always welcome.

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

MCUdude wrote:
I'd argue that the project is highly active again

Indeed its good to see!

 

pymcuprog will continue to be maintained since its a necessary part of test infrastructure, but the strategy there (as is already in place) is to push snapshot builds to pypi and source to github.  This offers a python alternative for those interested, and can also be used as a 'second-opinion' for avrdude-maintainers when new devices turn up.

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

There are still things pymcuprog can do that Avrdude can't, most noticeably support for high-voltage UPDI programming using a PicKit4 or a Powerdebugger.

I technically got it to work, but it needs some work in order to be as functional and practical as the pymcuprog implementation is.

I'm by no means a Python programmer, and I'm having a hard time following the pymcuprog program flow, so I have basically given up and moved on.

 

</off topic>

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

For $35 the SNAP programmer/debugger works with MPLAB and Studio, and supports UPDI according to the documentation

 

jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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


Dear,

The software  for windows available at https://github.com/Polarisru/upd... and a CH340 USBtoSERIAL (2 to 3$ aliexpress) adaptor with 2  1.5k resistors works like a charm. I usually program my attiny804 with the setup described in the github page. cheap and best

Regards

 

 

darth vader

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

jgmdesign wrote:

For $35 the SNAP programmer/debugger works with MPLAB and Studio, and supports UPDI according to the documentation

 

jim

 

This one? https://www.microchip.com/en-us/...

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

darth vader wrote:
The software  for windows available at https://github.com/Polarisru/upd... and a CH340 USBtoSERIAL (2 to 3$ aliexpress) adaptor with 2  1.5k resistors works like a charm.

 

Nice, I didn't knew there was a C version of pyupdi yes

 

Looking at the source code I can see it doesn't support the AVR-Dx yet. This too quite a bit of work for jtag2updi.

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

i14r10 wrote:

jgmdesign wrote:

For $35 the SNAP programmer/debugger works with MPLAB and Studio, and supports UPDI according to the documentation

 

jim

 

This one? https://www.microchip.com/en-us/development-tool/PG164100

 

yup.  Thats it

 

jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Man, the Snap costs $35 now? I think I paid half of that.

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

El Tangas wrote:

Man, the Snap costs $35 now? I think I paid half of that.

 

And the other programmer, i think it's called ICE costs 150 euros...

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

i14r10 wrote:
And the other programmer, i think it's called ICE costs 150 euros...

 

That one has always been expensive, but the Snap was cheap when it was launched.

 

Here is a quote from this thread  https://www.avrfreaks.net/forum/mplab-snap-feb20

 

david.prentice wrote:
Farnell has 15 of them in Stock.   Priced at £5.79.  £1.16 VAT.    No Coupon required.

 

Oh, well, I guess that was when there was an actual supply chain for electronics.

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

El Tangas wrote:

i14r10 wrote:
And the other programmer, i think it's called ICE costs 150 euros...

 

That one has always been expensive, but the Snap was cheap when it was launched.

 

Here is a quote from this thread  https://www.avrfreaks.net/forum/mplab-snap-feb20

 

david.prentice wrote:
Farnell has 15 of them in Stock.   Priced at £5.79.  £1.16 VAT.    No Coupon required.

 

Oh, well, I guess that was when there was an actual supply chain for electronics.

 

yeah, chip shortage sucks...

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

HI 

i have question on  ATtiny1626 ic , can we program the ATtiny1626 controller using Pickit4 .  if yes what is hardware and software setting .

 

thank you 

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

Welcome!

prajalya wrote:
can we program the ATtiny1626 controller using Pickit4 .
Yes

prajalya wrote:
if yes what is hardware and software setting .
Answer is dependent on PC/workstation/server operating system.

pymcuprog is a creation of the ones at Microchip Technology (Python)

 


http://packs.download.atmel.com/#collapse-Atmel-ATtiny-DFP-pdsc (Microchip Studio)

Atmel.ATtiny_DFP.2.0.368.atpack

unzip (an atpack is a zip file)

search for tiny1626 in pdsc

                  <at:interface type="updi" name="UPDI"/>
                  <at:tool id="com.atmel.avrdbg.tool.atmelice"/>
                  <at:tool id="com.atmel.avrdbg.tool.edbg"/>
                  <at:tool id="com.atmel.avrdbg.tool.edbgc"/>
                  <at:tool id="com.atmel.avrdbg.tool.ice4"/>
                  <at:tool id="com.atmel.avrdbg.tool.jtagice3plus"/>
                  <at:tool id="com.atmel.avrdbg.tool.jtagicemk3"/>
                  <at:tool id="com.atmel.avrdbg.tool.medbg"/>
                  <at:tool id="com.atmel.avrdbg.tool.nedbg"/>
                  <at:tool id="com.atmel.avrdbg.tool.pickit4"/>
                  <at:tool id="com.atmel.avrdbg.tool.powerdebugger"/>
                  <at:tool id="com.atmel.avrdbg.tool.snap"/>
                  <at:tool id="com.atmel.avrdbg.tool.stk600"/>
                  <at:tool id="com.atmel.avrdbg.tool.simulator"/>

 

Microchip PIC&AVR Tools · GitHub

 

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

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

Thank you  @ gchapman

Thank you fro quick response. I will go through the link and check

one more thing is which are all pins  connection between Attiny1626 to Pickit4  , as Attiny1626 has only one pin that's UPDI.  and any pull or pull down resistor or capacitor required? .

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

PK4 should work out of the box.   Look in the docs to see the UPDI connections.

It is only SNAP that requires a minor hardware mod for UPDI / PDI.

 

PK4 should work in both AS7.0 and MPLABX.

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

Thank you.

 

Sorry i am not clear , can you share the document link which clarify the connection details .

 

 - we have small project using in tools to read the voltage and temp.  Is plan is use to ATTiny1626 with MPLABx and Xc8 compiler  and Pickit4 debugger .

 - please corrected me  if my selection compatibility is wrong . 

 - One more thing  is  MCC (mplab code configurator)  supports for ATtiny controller ?

 

Thank you

 

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

You're welcome.

prajalya wrote:
which are all pins  connection between Attiny1626 to Pickit4  , as Attiny1626 has only one pin that's UPDI. 
Answer's in the MPLAB PICkit 4 operators manual.

prajalya wrote:
and any pull or pull down resistor or capacitor required? .
Though UPDI isn't as high frequency as PDI, do limit the capacitor's value.

No additional pull as UPDI must tri-state (pulls are by the AVRxt UPDI controller and the tool); in lieu of pull, consider series termination approximate to free space impedance (increases ESD tolerance, reduces EMI)

R-C-R (100 ns) is effective on ESD though R-TVS-R is more so; UPDI frequency < 1 MHz.

 


Pinouts for Interfaces | MPLAB® PICkit™ 4 In-Circuit Debugger User's Guide (web doc, formal is the PDF)

MPLAB® PICkit™ 4 Debugger Pinouts for Interfaces - Developer Help (web page)

 

UPDI | tinyAVR® 2 Family

[top for UPDI enable, bottom for Table 2 (by design)]

UPDI is a match for USB HID and USB low-speed; tool's UPDI speed is a parameter.

TinyX-OCD (UPDI) Special Considerations | Atmel-ICE

Serial port UPDI (pyupdi) | GitHub - microchip-pic-avr-tools/pymcuprog: a Python utility for programming various Microchip MCU devices using Microchip CMSIS-DAP based debuggers

 

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

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

david.prentice wrote:
PK4 should work in both AS7.0 and MPLABX.
MPLAB PICkit 4 firmware update is by MPLAB X or MPLAB IPE.

MPLAB PICkit 4 ship in PIC mode (PIC, PIC24/dsPIC, PIC32)

Can't remember if Microchip Studio can switch from PIC mode to EDBG or the switch is by an MPLAB IDE/IPE.

Wouldn't be surprised if there's some Python to do the switch.

 

https://packs.download.microchip.com/#collapse-Microchip-PICkit4-TP-pdsc (MPLAB X has tool packs)

 

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

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

prajalya wrote:
Is plan is use to ATTiny1626 with MPLABx and Xc8 compiler  and Pickit4 debugger .
fyi, FSF AVR GCC and/or Microchip AVR GCC is available; likely there's a toolchain pull-down menu though am not an MPLAB X operator.

 

MPLAB XC8 for AVR advantages :

  • regression testing
  • portability across XC (Common C Interface [CCI], up to C99 inclusive, ease porting to/from AVR and PIC)
  • functional safety (some versions)

AVR GCC advantages :

  • progression in computer language standards
  • completely open source (many instances, MPLAB XC8 for AVR is an instance of GCC though with proprietary libraries)
  • a few computer languages via configuration
  • C++ is usually OOTB

 

Before performing the plan, consider a trial of a tinyAVR 2-series Curiosity Nano (reasons: MPLAB X has [had?] some version instability though MPLAB X v6 is feature enhanced, on sale through today)

prajalya wrote:
is  MCC (mplab code configurator)  supports for ATtiny controller ?
AVRxt tinyAVR; Melody lacks AVRrc, AVRe, AVRe+, and AVRxm.

 


Come Join Us (MPLAB Now Supports AVRs) | Page 8 | AVR Freaks

6.1      Compilers & Assemblers

...

Atmel Compiler (1)

...

  1. It is recommended that you install compilers in the same location as MPLAB XC compilers so MPLAB X IDE can find them.

ATTINY1627 CURIOSITY NANO EVALUATION KIT | Microchip Technology

 

Come Join Us (MPLAB Now Supports AVRs) | Page 8 | AVR Freaks

 

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

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

mraardvark wrote:

- pymcuprog by serial port is slow as the round-trip is long via python.

https://github.com/microchip-pic-avr-tools/pymcuprog/blob/main/CHANGELOG.md#313---may-2022

...

  • DSG-4172 github-10 Disable ACK response signature on serialUPDI block write (speed-up)

...

 

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

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

I am trying to do debugging through the UPDI interface using open source tools. What I have tried and works is to read out SRAM data while the program is running. I assume that reading IO registers would also work. (This is a custom program for this purpose and it is not in a status to be publicated yet. It accesses the uniform memory similar to jtag2updi so I guess that would also work if you manage to put the CPU in running state while UPDI is connected and read addresses of SRAM - These addresses are 0x3800 to 0x3FFF on my ATtiny1624)

 

What I would like to implement is a simple watcher that periodically reads out values from RAM based on a list of watch variables and the map file generated by the avr-gcc compiler. This is all accessible using the features documented in the datasheet.

 

I would also want to implement breakpoints and stepped execution. Is there any documentation available about how to implement a breakpoint and letting the CPU run again after the breakpoint has executed? Access to the instruction pointer would also be required. I could not find these in the datasheet even though these are mentioned to be features in the beginning of the UPDI section.  I guess it is something that is designed to remain proprietary by Microchip. Am I right?

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

Welcome!

rizsi wrote:
Is there any documentation available about how to implement a breakpoint and letting the CPU run again after the breakpoint has executed?
Am unaware of such wrt UPDI stream.

rizsi wrote:
I guess it is something that is designed to remain proprietary by Microchip. Am I right?
Yes; EDBG is in lieu of.

https://github.com/microchip-pic-avr-tools/pyedbglib/blob/main/pyedbglib/protocols/avr8protocol.py#L420

 


AVR - Calibration & Daq toolchain? | AVR Freaks

 

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

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

gchapman wrote:

Welcome!

Thanks! Yes, this was my first comment. I was a lurker until now.

 

Also thanks for the link! As far as I understand the UPDI protocol is implemented within the EDBG tool and accessible through this library that you linked?

 

Since my last comment I have tried to write to SRAM and to the IO ports and that also works! I could toggle a pin in PORTA by writing to the PORTA.DIRTGL (0x403) and PORTA.OUTTGL (0x407) registers through UPDI. (Writing this address is similar to the programming sequence except that the NVMCTRL commands need not be executed.) Combined with the variable watch feature this will be a very useful debugging tool.

 

It is already more than what I am used to. Until now I have only used serial output and oscilloscope to debug MCU programs.

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

rizsi wrote:
I could toggle a pin in PORTA by writing to the PORTA.DIRTGL (0x403) and PORTA.OUTTGL (0x407) registers through UPDI.

 

Yup, I did that too during my experiments when writing jtag2updi - blink a LED via UPDI. Interestingly, UPDI can write some bits that are read only for the CPU, such as peripheral interrupt flags IIRC.

Also, if you are writing a new program, I would recommend that you extract the MCU memory regions from the "atdf" files that come from Microchip IDEs instead of using some kind of proprietary definitions, it will save work later.

For example, I need to manually update avrdude.conf with definitions each time a new UPDI chip comes into production.

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

El Tangas wrote:

For example, I need to manually update avrdude.conf with definitions each time a new UPDI chip comes into production.

 

May I ask why? Avrdude 7.0 support jtag2updi without any modifications and pretty much all current AVRs with UPDI are present in the avrdude.conf shipped with 7.0.

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

MCUdude wrote:
May I ask why?

 

Because I haven't been following the new versions of avrdude I guess. Anyway, someone needs to update the avrdude.conf file in any case.

 

edit: BTW, releasing a major version, 7.0, takes courage and boldness. I'll take a look soon and see if my favorite bugs are still there cheeky

Last Edited: Tue. Jul 19, 2022 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rizsi wrote:
the UPDI protocol is implemented within the EDBG tool and accessible through this library that you linked?
UPDI is implemented in the tool with EDBG as a documented protocol.

rizsi wrote:
Until now I have only used serial output ...
Standard output is common; less common is standard error (assertions, exceptions)

rizsi wrote:
... and oscilloscope to debug MCU programs.
An oscilloscope for verification of signal integrity; consider a logic analyzer for digital signals in bulk.

 


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

to the tools listed add MPLAB PICkit 4 and MPLAB Snap after it has been switched to EDBG from the factory setting (PIC)

Tool Actions | Microchip Studio

[bottom]

Communication Mode

Open a dialogue to set the MPLAB® PICkit or Snap tool in AVR or PIC mode. However, Microchip Studio will automatically enable the tool in AVR mode when it communicates with the debugger. If required, use this option to force the tool into a given mode.

 

Adding Automatic Debugging to Firmware for Embedded Systems by Jack Ganssle

 

Troubleshooting real-time software issues using a logic analyzer - Embedded.com

 

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

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

El Tangas wrote:

BTW, releasing a major version, 7.0, takes courage and boldness. I'll take a look soon and see if my favorite bugs are still there cheeky

 

That would be great, and even better if you could open an issue so we could get rid of them once and for all!

 

A lot has happened since the project was moved to Github, and several skilled and courageous developers have joined.

An issue or a PR is usually resolved within a few days and not years like before. 

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

MCUdude wrote:
That would be great, and even better if you could open an issue so we could get rid of them once and for all!

 

Will do. Some of the bugs are in terminal mode, which apparently I'm the only person using frown

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

El Tangas wrote:

Will do. Some of the bugs are in terminal mode, which apparently I'm the only person using frown

 

I'm not so sure about that! The terminal has seen a major overhaul, and the latest upstream Avrdude version has a lot of edge cases sorted out.

And in case you didn't know, terminal write mode now supports  1, 2, 4, and 8-byte integers, 32 and 64-bit floats, strings, characters, and "fill mode"!

 

Usage: write <memory> <addr> <data>[,] {<data>[,]} 
       write <memory> <addr> <len> <data>[,] {<data>[,]} ...

Ellipsis ... writes <len> bytes padded by repeating the last <data> item.

<data> can be hexadecimal, octal or decimal integers, double, float,
C-style strings and chars. For numbers, an optional case-insensitive suffix
specifies the data size: HH: 8 bit, H/S: 16 bit, L: 32 bit, LL: 64 bit, F:
32-bit float. Hexadecimal floating point notation is supported. The 
ambiguous trailing F in 0x1.8F makes the number be interpreted as double;
use a zero exponent as in 0x1.8p0F to denote a hexadecimal float.

An optional U suffix makes a number unsigned. Ordinary 0x hex numbers are
always treated as unsigned. +0x or -0x hex numbers are treated as signed
unless they have a U suffix. Unsigned integers cannot be larger than 2^64-1.
If n is an unsigned integer then -n is also a valid unsigned integer as in C.
Signed integers must fall into the [-2^63, 2^63-1] range or a correspondingly
smaller range when a suffix specifies a smaller type. Out of range signed
numbers trigger a warning.

Ordinary 0x hex numbers with n hex digits (counting leading zeros) use    
the smallest size of 1, 2, 4 and 8 bytes that can accommodate any n-digit hex
number. If a suffix specifies a size explicitly the corresponding number of
least significant bytes are written. Otherwise, signed and unsigned integers
alike occupy the smallest of 1, 2, 4, or 8 bytes needed to accommodate them  
in their respective representation.

 

Apparently, support for generic flash write in terminal mode for most ISP and UPDI(?) programmers are also on its way.

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

I've already found a problem with the new avrdude version, which causes incompatibility with "older" versions of avrdude.conf including my own. Probably the cause of the problem reported in this thread: https://www.avrfreaks.net/forum/...

 

Now it's way past my bedtime, more details to follow tomorrow...

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

I guess the bug report will be something along these lines:

 

The jtag2updi programmer fails to recognize parts with PDI interface i,e, "has_pdi = yes".

In particular this affects avrdude.conf files where, for compatibility with old avrdude versions, UPDI parts are defined with "has_pdi = yes" instead of "has_updi = yes".

In theory, this would also prevent xmega parts from being programmed with jtagice mkII via serial link, since jtag2updi uses the jtagmkii_pdi programmer as parent.

However it doesn't. Using the "jtag2pdi" programmer and a xmega part, or UPDI part with "has_pdi = yes" the part is recognized.
But using the "jtag2updi" programmer definition, it's not.

Simple experiment: create a new programmer in avrdude.conf, named jtag2xxx, which is an exact copy of jtag2updi definition except for the name.
Now, UPDI parts with a "has_pdi = yes" definition work just fine.

This means jtag2updi was special cased, hardcoded, inside avrdude, to fail for "has_pdi = yes". I fail to see what useful purpose this serves.

Please remove this behaviour (revert to original behaviour of older versions of avrdude).

 

 

Really, why do this? Hardcoding jtag2updi to fail in specific cases even though it supports such cases, looks like poor programming practice to me.

The jtag2updi programmer is not a base programmer like jtagmkii_pdi for example, it should not be hardcoded inside avrdude. Sheesh... this is basic stuff...

 

edit: on a positive note, the bugs in terminal mode seem to have been corrected, and the new baud rates for jtag2updi are working fine, thanks @MCUdude for implementing this yes

Last Edited: Wed. Jul 20, 2022 - 10:04 AM