UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
247 posts / 0 new

Pages

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

Hey,

can we set lock bits ??
if i'm not wrong it's just another fuse bit.

btw, Thanks for your response, i'm a novice in microcontroller programming, it's pretty exciting.
 

vignesh

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

When will UPDI I/O type 3 be available? heart

/*
 * Available UPDI I/O types are:
 *
 * 1 - timer sofware UART:      Compatible only with Mega328P and other AVRs with identical 8 bit timer 0.
 *                                            Only the OC0A pin can be used for UPDI I/O. Slightly faster upload speed for a given UPDI_BAUD value.
 *
 * 2 - bitbang software UART:    Compatible with many chips and broad choice of UPDI pins are selectable.
 *                                              Slightly slower upload speed for a given UPDI_BAUD value. Download speed is the same.
 *
 * 3 - hardware USART:            Compatible with newer AVR chips with Fractional Baud Rate Generator.
 *                                             Maximum upload and download speed and timing accuracy for a given UPDI_BAUD value.

                                                Increased min/max UPDI_BAUD range. Fasten your seat belts!
 */

When considering types 1 and 2, which would be the best choice when using F_CPU defined at 10000000U?

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

dlloydev wrote:
When will UPDI I/O type 3 be available? heart

Lol. I'll look into it, no promises, I'm not very familiar with the AVR-0/1 USART.  I think it has a half duplex mode which would be useful for UPDI.

 

dlloydev wrote:

When considering types 1 and 2, which would be the best choice when using F_CPU defined at 10000000U?

Type 2 is basically always the right choice.

 

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

Thanks for your quick reply!
It looks like the megaAVR 0-series, tinyAVR 0/1/2 series and AVR-DA/DB all have very similar if not the same half duplex mode that could have its data frame matched to the UPDI spec.

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

Soory, i made a comment in wrong thread..

vignesh

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

Hiii @ Raving Lunatic ,
I tried this (#201) approach but i'm not getting expected output, i'll explain in detail what i did,

 

i'll attach my code below, i wrote the WDT fuse value as 0x0A and in my main function i call a function it gives a beep sound, then i made the main function to get stuck by writing a while(1) condition, as per 
my understanding the WDT should get reset automatically, since i'm not resetting it, if so the i should hear the beep sound continuously, but i didn't got such output.

at first i build the entire program in Atmel Studio 7, i took the generated hex file from the output files folder and dumped it using custom programming tool from Atmel studio, the flash section was working as exactly as i wanted it to be,
then i extracted the fuse section from elf file as you mentioned in your suggestion and made as separate Hex file then i dumped it, for my surprise, nothing happened,
i think while writing the hex containing the fuse data the previously written flash program is being erased,
my doubt is do i need to combine both the hex file them dump it ??
or do i need to try any other thing,

earlier El Tangas has suggested me to read the fuses back, but i'm failing to do the same, 

can anyone guide me through this, one more thing i understood how to code into the controller by reading the datasheet and few other example programs, is there any such way to learn stuffs like bootloader, fuse programming and reading(using custom tool), how to dump the hex by bit banging etc..

sorry for the boring language and less clarity of approach,

so here is my code..

 

Attachment(s): 

vignesh

Last Edited: Mon. Dec 7, 2020 - 05:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I'm having so many doubts,
i'll explain my understanding, please comment if i'm wrong
if i build the above example code,Atmel studio will generate an elf file, it'll contain data of all memories,
then i should use the command to extract fuse value and store it as a hex file,
now i'll have fuse values in a hex and i'll have a hex containing the application code which is generated by the atmel studio,
now what should i do,
should i combine both hex files ??
or should i follow some other way ??

 

vignesh

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

vignesh724452 wrote:

if i build the above example code,Atmel studio will generate an elf file, it'll contain data of all memories,
then i should use the command to extract fuse value and store it as a hex file,
now i'll have fuse values in a hex and i'll have a hex containing the application code which is generated by the atmel studio,

Yes, this is all correct.

 

vignesh724452 wrote:

now what should i do,
should i combine both hex files ??
or should i follow some other way ??

 

Now you write both hex files separately to different memory areas. Let's say you have files called

  • fuses.hex
  • appcode.hex

 

Supposing you are using avrdude and jtag2updi, the commands would be something like

avrdude -c jtag2updi -P com7 -p t414 -U fuses:w:fuses.hex

 and

avrdude -c jtag2updi -P com7 -p t414 -U flash:w:appcode.hex

Note the different memory areas each hex file goes into.

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

Debugging interface through UPDI - jtag2updi_terminal

 

I was starting to do some experimental work using an ATtiny412 and wandering what possibilities are there to get debug information from the running program into a PC.

Of course, that the first idea is to use the ATtiny412 USART to send debug information but that would be a waste 20%..40% of the pins available on this small device (5 GPIOs + UPDI).

The second idea was to try to use the UPDI pin itself by changing the operating mode, but that cannot be done.

 

My third idea was:

  • If the UPDI allow us to read and write bytes into the MCU memory space, can we implement a memory mapped interface to exchange data?
  • And would it be possible then to send the debug data to the PC through a serial interface?
  • And can this be done using an ATmega328P (Arduino) by extending the functionality of the JTAG2UPDI software to implement this interconnection?
    • Get data from the ATtiny412 (through UPDI) and send it to the PC through the TXD on the ATmega328P USART
    • Get data from the RXD on the ATmega328P USART and store it (through UPDI) on the ATtiny412

 

I’ve worked some hours on this idea and came up with the following solution:

  • Starting on the JTAG2UPDI source file I have added a new functionality (called it “Terminal”) running on the  ATmega328P that, when enabled does the following:
    • Direction ATtiny412 to PC:
      • The ATmega328P continuously reads a memory location - DEBUG_TXCNT - through UPDI from the ATtiny412
      • When the value on DEBUG_TXCNT changes it takes the data from another memory position - DEBUG_TX – and sends it through the USART TXD to the PC
    • PC to ATtiny412:
      • The ATmega328P continuously checks if new data has arrived on the USART RXD.
      • When new data is available, it stores the value on a memory position – DEBUG_RX - through UPDI inside the ATtiny412 and changes the value of another memory position - DEBUG_RXCNT – to signal the existence of new data
  • On the ATtiny412 implemented the following functions:
    • void debug_SendChar(char ch)
      • When called stores “ch” on DEBUG_TX and changes the value on DEBUG_TXCNT to signal the existence of new data
      • This function can’t be called at a very high rate because the ATmega328P needs to have time to get the data through UPDI. In my example, since it was just a proof-of-concept, I’ve used a for-loop to create the delay but on a real implementation it could be based on timers.
    • char debug_RecvRdy()
      • Checks if the value on DEBUG_RXCNT was changed since the last access. When that happens it signals the arrival of new data
    • char debug_GetChar()
      • Waits for the arrival of new data (using debug_RecvRdy) and gets the data from DEBUG_RX, registering the new value of DEBUG_RXCNT
  • The main idea is that the memory positions DEBUG_TXCNT and DEBUG_RXCNT are used to signal the existence of new data and the memory positions DEBUG_TX and DEBUG_RX are used for the data transfer
  • For enabling this new functionality, I have added a new JTAGICE MK2 command on JTAG2UPDI (called it CMND_TERMINAL – 0x70).
    • This functionality is automatically disabled as soon as a new JTAGICE MK2 command is received which allows to quickly fall back to the standard operation modes and go back to programming mode

 

I have tested it here on my setup and I’m sharingmy implementation here:

  • In my example I’ve used the GPIORn registers that are, in most cases, unused. This allowed me to use shorter UPDI instructions since the address only needs 8 bits.
    • #define DEBUG_TXCNT GPIOR0
    • #define DEBUG_TX    GPIOR1
    • #define DEBUG_RXCNT GPIOR2
    • #define DEBUG_RX    GPIOR3
  • When running the UPDI at the default rate 225000 bit/s I was able to achieve a data rate of ~2000 characters/second from ATtiny412 to the PC even if the USART interface of ATmega328P running at 115200. To simplify the examples, I have kept the serial interface between the ATmega328P and the PC running at 19200 baud

 

My implementation is in attachment (again, notice that it’s just a proof-of-concept). I have added in attachment a ZIP file including:

  • Updated JTAG2UPDI source with the new functionality to run on the ATmega328P
  • A directory “example” with an implementation of the required functions on the ATtiny412. In this case the "main" function is implementing a loopback where received  data is just sent back
  • A directory “terminal_test” with an implementation, in python and using a serial port (Real or USB based), of the required command sequence to enable the new functionality and after enabled implements a simple terminal to send and receive data

 

I will be using this in my own circuits and I hope that someone else finds it useful also...

 

Thank you,

 

Pedro Maia Alves

 

 

Attachment(s): 

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

Interesting, I'm always curious about derivatives of jtag2updi and will surely take a peek at your codesmiley

 

Anyway, wouldn't it be better to create a repository on github or the like to share it with a wider audience and get more feedback? Here buried in this thread few people will notice.

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

Welcome!

pmmgma@... wrote:
The main idea is that the memory positions DEBUG_TXCNT and DEBUG_RXCNT are used to signal the existence of new data and the memory positions DEBUG_TX and DEBUG_RX are used for the data transfer
Your idea could be extended to the realm of ASAM.

pmmgma@... wrote:
When running the UPDI at the default rate 225000 bit/s I was able to achieve a data rate of ~2000 characters/second from ATtiny412 to the PC even if the USART interface of ATmega328P running at 115200.
Two orders of magnitude faster than megaAVR OCDR.

 


ASAM MCD-1 XCP - Wiki

[History, Origin, beginning of second paragraph]

In the early 2000s, calibration interfaces were developed using microcontroller specific debug adapters (JTAG) or SPI, which were commonly available for microcontrollers. ...

due to AVR - Calibration & Daq toolchain? | AVR Freaks

GitHub - kuro68k/PDITest: Program one XMEGA from another via PDI

 

IDR Events | Microchip Studio (OCDR)

megaAVR® Special Considerations | Atmel-ICE (OCDR)

 

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

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

thank you very much for providing clear direction...

 

vignesh

Last Edited: Fri. Dec 18, 2020 - 05:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

i feel i'm almost near,
but while i try to dump the hex containing fuse 
this error is popping up,

avrdude.exe: Device signature = 0x1e9222 (probably t414)
avrdude.exe: reading input file "C:\Users\ELCOT\Desktop\wdtA.hex"
avrdude.exe: ERROR: address 0x820009 out of range at line 2 of C:\Users\ELCOT\Desktop\wdtA.hex
avrdude.exe: read from file 'C:\Users\ELCOT\Desktop\wdtA.hex' failed

anyone have an idea on this,
i'm not getting such thing while dumping flash program

 

vignesh

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

vignesh724452 wrote:
avrdude.exe: ERROR: address 0x820009 out of range at line 2 of C:\Users\ELCOT\Desktop\wdtA.hex

 

Probably just an address mismatch that can be solved by using raw binary format (.bin) instead of HEX.

In any case, can you post the faulty hex file with the fuses? I'd like to take a look, just to make sure you are not going to brick your chip.

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

yeah sure 
 

 

FUSES =

{

.WDTCFG = 0x0A,     // Watchdog Configuration (period mode with 4 second approximately)

.BODCFG = 0,        // BOD Configuration

.OSCCFG = 0x02,     // Oscillator Configuration

.TCD0CFG = 0,       // TCD0 Configuration

.SYSCFG0 = 0xC4,    // System Configuration 0

.SYSCFG1 = 0x07,    // System Configuration 1

.APPEND = 0,        // Application Code Section End

.BOOTEND = 0        // Boot Section End

};

 

this is the fuse structure i used in my code,
 

 

the generated Hex looked like this

:02000004008278
:090000000A00020000C407000020
:00000001FF
 

i copied the elf file generated by atmel studio to desktop and extracted the fuse section and saved it as wdtA.hex
using the comand

avr-objcopy -O ihex -R .text -R .eeprom -R .lock -R .signature -R .user_signatures "C:\Users\ELCOT\Desktop\GccApplication2.elf" "C:\Users\ELCOT\Desktop\wdtA.hex" 

then i dumped it using the following command

C:\apps\arduino-1.8.13\hardware\tools\avr/bin/avrdude.exe -C"C:\apps\arduino-1.8.13\hardware\tiny\megaavr/avrdude.conf" -v -pattiny414 -cjtag2updi -PCOM3 -Ufuses:w:"C:\Users\ELCOT\Desktop\wdtA.hex":i

 

just to make sure i tried to dump my flash code in the same way it's working pretty well
but while dumping fuses it's not working as expected

 

vignesh

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

Yeah, your fuses are ok. The problem is indeed the address.

In this particular case, it's easy, you just need to delete the first line of the hex file (it contains the high 16 bits of the 32 bit address information, which are meaningless to the AVR).

 

vignesh724452 wrote:
:02000004008278
:090000000A00020000C407000020
:00000001FF

 

In general, the solution is to use raw binary format instead, because the address information is discarded in this case.

avr-objcopy -O binary -R .text -R .eeprom -R .lock -R .signature -R .user_signatures "C:\Users\ELCOT\Desktop\GccApplication2.elf" "C:\Users\ELCOT\Desktop\wdtA.bin" 

then

C:\apps\arduino-1.8.13\hardware\tools\avr/bin/avrdude.exe -C"C:\apps\arduino-1.8.13\hardware\tiny\megaavr/avrdude.conf" -v -pattiny414 -cjtag2updi -PCOM3 -Ufuses:w:"C:\Users\ELCOT\Desktop\wdtA.bin":r

 

Last Edited: Sat. Dec 19, 2020 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the valuable guidance @Raving lunatic

 

i have few questions,

1, 

C:\apps\arduino-1.8.13\hardware\tools\avr/bin/avrdude.exe -C"C:\apps\arduino-1.8.13\hardware\tiny\megaavr/avrdude.conf" -v -pattiny414 -cjtag2updi -PCOM3 -Ufuses:w:"C:\Users\ELCOT\Desktop\wdtA.bin":r

in the above command line what is that means ":r" in the end ??

2,  i read back the flash code from my controller, but it was not same as the one i dumped, but the working is same,
then i created a dummy hex file and copied the content which i read from the controller to the dummy hex 
and i dumped it to controller back, it has the same working, leaving me in heap of doubts,
is there anything you can explain regarding this.

note : to make sure the behaviour i dumped a different program into controller then only i dumped the content i read. 

 

Btw i'm looking to set lock bit,
from all these steps i did, my understanding to this

 LOCK = {
  .LOCKBIT = 0,        /* setting lock bit since 0xC5 is to have the device open */
};

then 
 

avr-objcopy -O binary -R .text -R .eeprom -R .fuses -R .signature -R .user_signatures "C:\Users\ELCOT\Desktop\GccApplication2.elf" "C:\Users\ELCOT\Desktop\lck.bin"
C:\apps\arduino-1.8.13\hardware\tools\avr/bin/avrdude.exe -C"C:\apps\arduino-1.8.13\hardware\tiny\megaavr/avrdude.conf" -v -pattiny414 -cjtag2updi -PCOM3 -Ufuses:w:"C:\Users\ELCOT\Desktop\lck.bin":r

am i right ???

 

 

vignesh

Last Edited: Sat. Dec 19, 2020 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vignesh724452 wrote:

in the above command line what is that means ":r" in the end ??

It specifies the format of the file, "r" means "raw data", i.e., binary.

 

vignesh724452 wrote:

2,  i read back the flash code from my controller, but it was not same as the one i dumped, but the working is same,
then i created a dummy hex file and copied the content which i read from the controller to the dummy hex 
and i dumped it to controller back, it has the same working, leaving me in heap of doubts,
is there anything you can explain regarding this.

This is normal, the HEX format allows data to be represented in equivalent, but different ways.

Besides, when you dump flash from the controller, not only your program, but also unused flash may be dumped, so you will have a larger file than the one you burned. The extra data doesn't do anything, but the HEX file will be different.

 

vignesh724452 wrote:

Btw i'm looking to set lock bit,
from all these steps i did, my understanding to this

 LOCK = {
  .LOCKBIT = 0,        /* setting lock bit since 0xC5 is to have the device open */
};

then 
 

avr-objcopy -O binary -R .text -R .eeprom -R .fuses -R .signature -R .user_signatures "C:\Users\ELCOT\Desktop\GccApplication2.elf" "C:\Users\ELCOT\Desktop\lck.bin"
C:\apps\arduino-1.8.13\hardware\tools\avr/bin/avrdude.exe -C"C:\apps\arduino-1.8.13\hardware\tiny\megaavr/avrdude.conf" -v -pattiny414 -cjtag2updi -PCOM3 -Ufuses:w:"C:\Users\ELCOT\Desktop\lck.bin":r

am i right ???

 

Yes, I think so. Also, I think you should read carefully the avrdude manual  https://www.nongnu.org/avrdude/user-manual/avrdude.html

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

Thank you  Raving Lunatic,
i have successfully finished my project, only thing i couldn't do is setting the lockbit

i tried in both ways

case 1 :
 

FUSES =
{
    .WDTCFG = 0x0A,     // Watchdog Configuration (period mode with 4 second approximately)
    .BODCFG = 0,        // BOD Configuration
    .OSCCFG = 0x02,     // Oscillator Configuration
    .TCD0CFG = 0,       // TCD0 Configuration
    .SYSCFG0 = 0xC4,    // System Configuration 0
    .SYSCFG1 = 0x07,    // System Configuration 1
    .APPEND = 0,        // Application Code Section End
    .BOOTEND = 0,        // Boot Section End
    .LOCKBIT = 0        // setting lock bit since 0xC5 is to have the device open 
};
 

case 2
LOCK = 
{
    .LOCKBIT = 0        // setting lock bit since 0xC5 is to have the device open 
};

in both cases error is showing up....
 

vignesh

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

I got an idea,
by extracting the lock section using the command
 

avr-objcopy -O ihex -R .text -R .eeprom -R .fuses -R .signature -R .user_signatures "C:\Users\ELCOT\Desktop\GccApplication2.elf" "C:\Users\ELCOT\Desktop\lck.hex"
and changing the the lockbit value manually and converting it to binary.

is it a good way
because i don't want to throw the MCU away...

if it's good idea, i got the following hex value by running the above command

:02000004008278
:090000000A00020000C407000020
:00000001FF

 

i thought there will be C5 because in datasheet it's mentioned like, if the lock byte has 0xC5 device is in open is, so i was expecting C5 in that hex, unfortunately i couldn't find that..  

can you help me figure out what should i change,
even if u guide me to read some stuff or explore anything, i'm willing to do, i seriously don't want to annoy you guys by asking so many questions.

vignesh

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

Well that hex file is not correct, that's for sure. But there is another way to set the lock, avrdude can burn immediate data instead of a file. Use this command line option

 

-U lock:w:0x3A:m

The lock bit will get the value 0x3A, it's the one I use because it's the bitwise NOT of 0xC5, and the chip will be locked.

I have to warn you that jtag2updi has a known bug I never fixed (because it's a bit tricky) so that you will not be able to unlock the chip by erasing it using the -e option.

You will have to force entering avrdude terminal mode by using the "-F -t" options, then enter the "erase" command.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • If the UPDI allow us to read and write bytes into the MCU memory space, can we implement a memory mapped interface to exchange data?

Nice work.  Since UPDI is documented as capable of operating while the main CPU is actually running, I've been wondering for a while how difficult it would be to do something like this...

 

IIRC, ARM formalizes something similar via ITM_SendChar() (hmm.  ARMv7m; so CM3 and CM4, but not CM0?)

 

 

 

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

Hi El Tangas,

You wrote: 

 

Warning: only the UPDI pins of devices that support high voltage programming should be assumed to be high voltage tolerant. This is not the case for the MegaAVR 0-series or AVR-DA series! 

 

Is that the reason of using 4k7 series resistor? Does it mean (taking the presence of this resistor) that we can use V_prog > V_target for all 0-series and DA-series or we have to use level shiffter? Best regards... robiw

Last Edited: Mon. Feb 8, 2021 - 10:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

robiw wrote:
Is that the reason of using 4k7 series resistor? Does it mean (taking the presence of this resistor) that we can use V_prog > V_target for all 0-series and DA-series or we have to use level shiffter? Best regards... robiw

 

The resistor is there to prevent a short in case there is data collision, i.e. both sides try to write at the same time and one is logic high while the other is logic low (it's unlikely but we never know...)

But yes, the resistor will probably protect the UPDI pin in case V_prog > V_target, though I wouldn't recommend it.

Also note that if V_target < 70% of V_prog it's possible communication errors will occur due to incompatible logic levels.

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

So, it seems that it would be better to have simple logic shifter and the serial resistor, both for other purposes. One of the simplest:

 

 

Best regards... robiw

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

What is more, I thing that entire programmer would look like follows:

 

Best regards... Robert

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

Hi,

 

First I want to thank El Tangas for his great job on the jtag2updi! Thank you very much. I recently stepped over this project and gave it a try. In theory I have all the programmers you need but I cannot program AVR128DA chips using avrdude on macOS. It was already a major task to let avrdude talk to my Atmel-ICE because of Apples handling of USB. But I'm not able to talk to AVR128DA chips using atmelice_updi. But with jtag2updi and a USB to serial adapter this works.

 

The strange thing is that when I'm using avardude and avrdude.conf from the latest arduino IDE I get the following error

 

Peters-Mini:jtag2updi-master peter$ /Applications/Arduino.app//Contents/Java/hardware/tools/avr/bin/avrdude -C avrdude.conf.arduino -c atmelice_updi -pAVR128DA48
avrdude: usbhid_open(): No device found

avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: bad response to AVR sign-on command: 0xa0
avrdude: retrying with external reset applied
avrdude: JTAGEN fuse disabled?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude done.  Thank you.

 

Using jtag2updi works like a charm

 

Peters-Mini:jtag2updi-master peter$ /Applications/Arduino.app//Contents/Java/hardware/tools/avr/bin/avrdude -C avrdude.conf -c jtag2updi -P /dev/cu.usbserial-FTHBRLCS -pAVR128DA48

avrdude: jtagmkII_initialize(): Cannot locate "flash" and "boot" memories in description
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.07s

avrdude: Device signature = 0x1e9708 (probably avr128da48)

avrdude done.  Thank you.

Peters-Mini:jtag2updi-master peter$ 

In the meantime I enjoy a working jtag2updi, I don't care if it's only 115200baud.  I'm actually using a spare Atmega328P in a DIP28 package on a breadboard and programming AVR128DA works fine.

 

Peter

 

 

 

For more about my projects see http://www.5volts.ch

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

cbscpe wrote:
talk to my Atmel-ICE

I have nothing against jtag2updi... but if you have an atmel-ice and know a little Python you could try pymcuprog (https://pypi.org/project/pymcuprog/)

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

You can also level shift between the host side UART (I use an R-Pi RX & TX) and the UPDI. I use pins from the host (but a manual switch could be used) to select UPDI mode or UART mode to power one or another of the 74LVC2G07W6-7 (label Z4). In UART mode, I cross over the host RX to the MCU TX at the level shifter; hopefully, that is clear enough.  I guess pymucprog is going to replace pyupdi, which I have been using.

 

Might want to look at https://github.com/mraardvark/py... to see a simplified view of how the full-duplex RX and TX go into the half-duplex UPDI.

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

You are right, I was so busy and absorbed building and testing the Atmega328P version of jtag2updi that I completely forgot about this solution. And especially as I'm currently learning python.

For more about my projects see http://www.5volts.ch

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

to elaborate

https://github.com/MCUdude/DxCore#new-starting-in-130 (also an earlier instance in that page)

 

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

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

mraardvark wrote:

cbscpe wrote:
talk to my Atmel-ICE

I have nothing against jtag2updi... but if you have an atmel-ice and know a little Python you could try pymcuprog (https://pypi.org/project/pymcuprog/)

 

Nice, both atmel-ice and curiosity-nano working, thanks for pointing me to this solution

peter@Peters-Mini ~ % pymcuprog verify -m flash -d avr128da48 -f AVR-Projects/LED-AVR128DA/LED-AVR128DA/Debug/LED-AVR128DA.hex
Connecting to anything possible
Connected to Atmel-ICE CMSIS-DAP from ATMEL (serial number J41800094609)
Debugger firmware version 1.41.137
Debugger hardware revision 0
Verifying...
Verify successful. Data in flash matches data in specified hex-file
Done.
peter@Peters-Mini ~ % pymcuprog verify -m flash -d avr128da48 -f AVR-Projects/LED-AVR128DA/LED-AVR128DA/Debug/LED-AVR128DA.hex
Connecting to anything possible
Connected to nEDBG CMSIS-DAP from Microchip (serial number MCHP3280031800001205)
Debugger firmware version 1.17.514
Debugger hardware revision 0
Device mounted: 'avr128da48'
Verifying...
Verify successful. Data in flash matches data in specified hex-file
Done.
peter@Peters-Mini ~ % 

 

For more about my projects see http://www.5volts.ch

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

cbscpe wrote:
both atmel-ice and curiosity-nano working

Nice :)

A few things to be aware of:

- pymcuprog does not "erase before programming" (long story).  So do a pymcuprog erase first

- no need to specify device on the nEDBG unless you cut the debugger off - it already knows the device

- you can use "pydebuggerupgrade latest" to upgrade your nedbg fw

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

Thanks for the tip regarding erase. Short story, just another command in my make file.

When I cut off the debugger from the curiosity can I then use this as a general programming device for updi based AVRs? That would be a very cheap solution, even cheaper than an Arduino for jtag2updi.

For more about my projects see http://www.5volts.ch

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

cbscpe wrote:
When I cut off the debugger from the curiosity can I then use this as a general programming device for updi based AVRs?

Don't know why you couldn't, in fact IIRC it's documented in the curiosity users guide.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Yes, its possible - but maybe not as cost-effective as buying a Snap? 

The nEDBG on Curiosity Nano is not "locked" to a device, although it reports its "mounted" device to front-ends which ask.  You can even cut the debugger off a PIC board and use it to debug an AVR if you want.  Check the hardware user guides for cut-strap descriptions if you are not up to actually sawing it... ;)

You can use the -d switch in pymcuprog for example to override the mounted-device detection; in Studio you can "show unsupported devices" in the options, then select which ever device you want from UPDI devices... (and maybe SAMs).

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

mraardvark wrote:
Yes, its possible - but maybe not as cost-effective as buying a Snap? 

 

Hmm, I never got my snap to work. Linux, win10, win10 on second computer all failed to recognize my SNAP.  The customer service rep suggested I buy another programmer as a final solution. If I was to buy another programmer it would not be SNAP. Maybe not even Microchip. Off topic, i know... just saying, be careful.

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

Ideally should appear in lsusb or Windows 10 Device Manager.

MPLAB debuggers are factory set for PIC.

90 day warranty :

Development Tools Warranty | Microchip Technology

 

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

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

SNAP costs 25USD, the AVR128 curiosity Nano 15USD and I have some curiosity laying around that are no longer used as they did their Job to learn about the new Chips. So i thought why not cut it off and put it as a permanent debugger on one of my projects 

For more about my projects see http://www.5volts.ch

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

cbscpe wrote:
as a permanent debugger on one of my projects

If you are going as far as soldering it onto something else, then you should probably look at changing the device name/kit name using the pydebuggerconfig package.  Its not really meant for 'normal' end users, but once you saw your nano in half your warranty is quite void anyway ;)

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

Hi El Tangas,

Don't you think that would it be resonable to add an extra LED called PGM to signal that the chip is being programmed? Best regards... Robert

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

For programming (MPLAB X IDE, XC8 Compiler) of ATtiny202 I am using MPLAB Snap. It's working perfectly. You just need to make a small modification of Snap tool - see ETN #36 MPLAB® SNAP AVR UPDI/PDI/TPI Interface Modification. You can use the Snap tool for UART monitoring too, (pins 8-TX, 7-RX) COM Port over USB.

Last Edited: Sat. Feb 20, 2021 - 09:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ElTangas,

 

thanks for your awesome work so far! Does jtag2updi also support flashing of Attiny series 2, like the ATTINY1626?

 

Thanks & Greetings,
Timm

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

timmbo85 wrote:

Does jtag2updi also support flashing of Attiny series 2, like the ATTINY1626?

 

 

Yes, it currently supports the tiny 162x chips. I will soon add support for 42x and 82x so it will support all available tinyAVR-2.

 

edit: in fact I just pushed the update, so tinyAVR-2 support is now complete.

Last Edited: Thu. Jun 10, 2021 - 04:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:

timmbo85 wrote:

Does jtag2updi also support flashing of Attiny series 2, like the ATTINY1626?

 

 

Yes, it currently supports the tiny 162x chips. I will soon add support for 42x and 82x so it will support all available tinyAVR-2.

 

edit: in fact I just pushed the update, so tinyAVR-2 support is now complete.

 

Hey there. Wow, this is great! Really appreciate all the work you put in there. Incredibly valuable.

Pages