ATMEGA4809-PF Programming with AVRdude

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

Hello everyone,

 

The question would be related to new AVR line from Microchip, the Atmega 4809-PF. I was wondering if someone here have tried to use the regular AVRdude 6.3, or 5.5 or any other version, and the #include <avr/io.h> header file to program the device as it is normally done by the other ATmegas, (328, 1284p, or any other device populated inside the header file) mention above.

Basically my plan is to follow the exactly same procedure of programming  ATmega4809-PF, as I would any other AVR. Would this still be possible?

 

Thanks in advance

 

Greetings

This topic has a solution.

work in progress...

Last Edited: Fri. Jan 24, 2020 - 08:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt if Avrdude v5.5 knows about UPDI.

 

But Avrdude v6.3 can use :

-c atmelice_updi

-c jtag2updi

-c powerdebugger_updi

-c xplainedpro_updi

 

What programmer hardware do you own?

 

I suspect that future avrdude might support PICKIT4 and SNAP.

 

David.

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

Hello David and  thanks for the information,

Currently I've got a Atmel AVR Mk2 ISP programmer, and have additionally an arduino Uno setup as ISP programmer.

Mostly I program "avrdude -p m1284p -c avrisp -P com4 -b 19200"

 

 

work in progress...

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

Your AVRISP-mk2 does not support UPDI.

 

Google for "UPDI Uno" and you get https://github.com/SpenceKonde/megaTinyCore/blob/master/MakeUPDIProgrammer.md

 

You upload the software to your Uno.   And then use avrdude -c jtag2updi

 

Making a permanent UPDI programmer from a Nano looks like a good idea.

 

Personally,   I would just buy a SNAP,  PICKIT4 or ATMEL-ICE.   And then you get full debugging for all AVR, ARM and PIC chips.

 

David.

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

maybe for the first run I will turn my Uno into UPDI programmer, and afterwards, Atmel -ICE would be a nice option to have. As you already mentioned it does cover all the range from AVR, SAMs, and now also the megaAVRs.

 

Do you think it will be possible to use the Atmel -ICE with a make files, or it is binded to the AS7 IDE environment.

Thanks a for sharing the information.

 

work in progress...

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATMEL-ICE can be driven by avrdude.  i.e. Makefile.

 

You can also use Microchip command line tools e.g. atprogram.exe

 

Yes,  it seems wise to try the Uno first.

 

atprogram.exe supports:
 

  -t  --tool <arg>           Tool name: avrdragon, avrispmk2, avrone, jtagice3,
                             jtagicemkii, qt600, stk500, stk600, samice, edbg,
                             medbg, nedbg, atmelice, pickit4, snap,
                             powerdebugger, megadfu or flip.

So you can buy the cheap SNAP or PICKIT4.    Note that you need to make your own ribbon cables.

 

David.

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

There are a couple of other projects that use an Arduino as a UPDI programmer:

https://github.com/ElTangas/jtag...

https://github.com/MCUdude/micro...

 

Or you could take the part of the Nano Every circuit that uses a SAMD11 running the MuxTO firmware.

 

Of course, if you burn a serial bootloader, then the standard avrdude approach applies.

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

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

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

david.prentice wrote:
You can also use Microchip command line tools e.g. atprogram.exe
in addition, IPECMD in MPLAB IPE should work with MPLAB X MDB for a debugger.

https://www.avrfreaks.net/forum/trouble-flashing-attiny3217-xplained-pro-board-mdb#comment-2834981

https://microchipdeveloper.com/search:site/a/p/q/MDB/

MPLAB® IPE - Developer Help

 

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

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

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

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

Good Morning,

 

I'm personally unable to spot the advantages of this new UPDI programming method, if the data is clocked over a single line, does'nt it make the in-system programming process longer?.

Despite the fact that the 3 SPI GPIOs are free on target device, what else makes any resaonable difference. By the way, in regular ISP-programming mode does not interfere with the device attached to SPI Bus, if I am not wrong.
 

 

 

work in progress...

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

Dave_Zeb. wrote:
I'm personally unable to spot the advantages of this new UPDI programming method
Dave_Zeb. wrote:
if the data is clocked over a single line,
Surely you just answered your own question?

 

ISP takes 3 pins, JTAG takes 4. An interface (presumably inspired by earlier debugWire) that uses just 1 pin is surely the supposed advantage. More pins a re left for your application? presumably you would not have picked to use a 40/48 pin chip in your design if you did not intend to use pretty much all of those pins? (smaller/cheaper "cut down" versions are available in the AVR-0/AVR-1 families)

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

Dave_Zeb. wrote:
if the data is clocked over a single line, does'nt it make the in-system programming process longer?.
No

4ms/page for page erase and write

128B/page

8b/B * 128B/page * 1page/4ms = 256000b/s

Atmel-ICE UPDI is up to 750Kb/s

(don't know MPLAB PICkit 4's UPDI speed)

flash write is the long pole in the tent

Dave_Zeb. wrote:
what else makes any resaonable difference.
XMEGA PDI can reach 30MHz though that would be via an FPGA and may cause effects due to arbitration

(bus matrix masters : CPU, Prog/Debug Controller (PDI), DMAC)

PDI and UPDI share instructions; both are available for moving data to and from memory.

 


ATMEGA4809 - 8-bit Microcontrollers

Features | Atmel-ICE

 

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

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

Dave_Zeb. wrote:
unable to spot the advantages of this new UPDI programming method

 

It is UART based; maybe I need to repeat that a few times. UART, UART, UART. Those things work everywhere.

 

Some adventures fool might even figure out how to make it work over RS-485 transceivers, perhaps even multidrop with no bootloader on the target. The more I think about it, the more interesting it sounds.