UPDI programmer software for Arduino - compatible with avrdude

Go To Last Post
191 posts / 0 new

Pages

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

El Tangas wrote:

Strange... which one is working, the blue one or the black one?

 

I'm guessing the blue one works? It's modded with a cap on RST to GND, while on your first post you said you used a different mod, so the original must be the black one.

 

Well, the important thing is that you got it workingyes, I like the way you took advantage of the programming header of the nano to build your programmer, thanks for the pic.

Yep, the blue is working.

The black is after remove all extra components. With the same assembly, even the cap on RST to GND, it does not work. I don't know whyindecision

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

Hi El Tangas, 

I've just been trying to flash the source onto a Mega2560 via Arduino IDE. When it tries to compile, it spits an error for sys.cpp that "PRR" was not declared in the scope. 

Any ideas? 

Bevan 

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

This program is only compatible with Mega328P and other chips of the same AVR sub-family (i.e. Mega48/88/168).

I can't guarantee it will work with Mega2560, but you can do this:

 

Edit file sys.cpp and remove the following code:

	/* Disable unused peripherals */
	ACSR = 1 << ACD;		// turn off comparator
	PRR =
		(1 << PRTWI) |		// turn off 2 wire interface
		(1 << PRTIM2) |		// turn off timer 2
		(1 << PRTIM1) |		// turn off timer 1
		(1 << PRSPI) |		// turn off SPI interface
		(1 << PRADC);		// turn off the ADC

Then, rebuild and upload with the Arduino IDE. I _think_ it will compile OK, but will still not work, because the code needs to be modified in other files too, most notably updi_io.cpp.

 

The problem is, I use the OC0A pin for the UPDI interface. On the Arduino Mega, this is connected to an LED that will mess up communications. So, updi_io.cpp needs to be modified to use OC0B instead, which will be more or less hard depending on your experience with AVR programming.

 

I've been tweaking the code to make it easier to port, but it's not quite there yet... At least, I have confined most hardware specific code to these files, sys.cpp, updi_io.cpp and JICE_io.cpp.

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

I am having issues with the error avrdude: jtagmkII_getsync(): sign-on command: status -1

 

I have everything configured correctly as far as i can tell, and from reading the thread here.

 

I used a 120 ohm resistor from reset to 5v, i have a 4.7kohm resistor from Pin 6 on my arduino uno to reset/UPDI pin on my attiny404

 

I tried 2 versions of the firmware on my uno that were suggested above.

 

my bat file runs this command: avrdude -c jtag2updi -P com1 -p t404 in the folder with avrdude.exe and the .config file from the downloaded jtag2updi-master file located in the C:\Users\Luke\Documents\jtag2updi-master

 

I am looking at the pin with my scope and am not seeing any activity on pin6.

 

any ideas?

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

ssmithl379327 wrote:
I used a 120 ohm resistor from reset to 5v

That seems like a really really really strong pull up, have you tried a 10k?

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Isn't the 120 from reset to 5v on the Arduino meant to disable the reset? isn't that its purpose?

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

ssmithl379327 wrote:
Isn't the 120 from reset to 5v on the Arduino meant to disable the reset

Show me an Arduino with a 120 ohm reset pull up???

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

Its not a standard pullup, in the readme of the jtag2updi-master, to make this programmer work requires disabling the auto restart feature of the arduino.

 

https://github.com/unforgiven512...

 

Download it and have a read.

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

ssmithl379327 wrote:
I am looking at the pin with my scope and am not seeing any activity on pin6.  

 

That's the same thing the poster in #37 said. No signal on pin 6. He tried a different Arduino and then it worked... I can't figure it out, because I'm not able to reproduce this. All the Arduinos I tested work ok.

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

I misunderstood, this was on the programmer AVR reset pin. 

Thanks for the link.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I just got it to work, not sure what the issue was. I unplugged the Arduino and re plugged it in ans walla!

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

Good. Sometimes, you need to reset the programmer, it can get stuck in an infinite loop under certain conditions (especially communications failure with the UPDI interface). I need to fix that, one day...

 

edit: so basically, don't send avrdude commands if the target MCU is not powered or connected to the programmer. It will probably hang.

Last Edited: Wed. Dec 12, 2018 - 10:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quick Question, how do i set fuses now? I am having issues getting my ATTINY404 to run at 20MHz, its defaulting to the 20Mhz but the prescaler defaults to x6, So all i get is 3.3Mhz. I usually do it though atmel studio7.

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

You set the fuses by using the FUSES macro, like this:

FUSES = {
    .WDTCFG     = WINDOW_OFF_gc | PERIOD_OFF_gc,
    .BODCFG     = LVL_BODLEVEL7_gc | SAMPFREQ_1KHZ_gc | ACTIVE_ENABLED_gc | SLEEP_SAMPLED_gc,
    .OSCCFG     = FREQSEL_20MHZ_gc,
//  .TCD0CFG	=
//  .SYSCFG0	=
//  .SYSCFG1	=
//  .APPEND     =
//  .BOOTEND	=
};

 

Be careful, all fuses not explicitly set will be filled with zero and this can brick your ATtiny. Be sure to set the UPDI pin to UPDI mode. To upload, you can extract the fuse section from the elf file to a hex binary file like this:

 

avr-objcopy -j .fuse input_file.elf -O ihex binary fuses.hexbin

 

Then use avrdude to write the fuses.bin file to the MCU fuse memory.

 

You can only choose 20MHz or 16MHz via fuses. The CPU clock divisor is set by software.

Last Edited: Thu. Dec 13, 2018 - 01:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is my code, still is not running at 20MHz, any ideas?

 

#include <avr/io.h>
#define F_CPU 20000000L
#include <util/delay.h>

#define sbi(x, y) x |= _BV(y)                // set bit - using bitwise OR operator
#define cbi(x, y) x &= ~(_BV(y))             // clear bit - using bitwise AND operator
#define tbi(x, y) x ^= _BV(y)                // toggle bit - using bitwise XOR operator
#define is_high(x, y) (x & _BV(y) == _BV(y)) // check if the y'th bit of register 'x' is high

int main(void)
{
    CLKCTRL_MCLKLOCK = 0x00; // Unlock clock registers
    CLKCTRL_MCLKCTRLA = 0x00; //Set clock to the internal 20MHz oscillator
    CLKCTRL_MCLKCTRLB = 0x00; //Set No Prescaler on clock
    
    
    PORTA_DIR = 0xff; //Set PORTA to Output
    PORTB_DIR = 0x00; //Set PORTB to Input
    
    while (1)
    {

        _delay_ms(500);
        PORTA_OUT = 0xff;
        _delay_ms(500);
        PORTA_OUT = 0x00;

    }
}

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

Yeah, if you look at the datasheet, you will notice that those registers have the "Configuration Change Protection" property. This means there is a special procedure to write to them.

There is a macro you can use, like in this example:

 

void clock_init(void){
	_PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc | CLKCTRL_PEN_bm);
}

 

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

Thanks so much! I am a bit of an AVR noob.

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

No problem, these chips are new so this kind of information is not easy to find unless you already know where to look.

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

baxsie wrote:
* I have verified that I can manually use a bench supply to jam 12v into the uPDI pin to enable further programming. You will want to protect your circuitry that is connected to uPDI from the 12v. I used a 1K resistor figuring that it would limit the current driven into my circuit to ~ 9mA (12v-3.3v)/1K

 

Is there a magical procedure for this? On a 412 I set the UPDI pin to be GPIO and can't figure out how to change it back.  Using avrdude and the jtag2updi programmer always fails with this

 

avrdude: jtagmkII_recv(): Got message seqno 6 (command_sequence == 6)
avrdude: Recv: . [80]

Raw message:
0x80
OK

avrdude: jtagmkII_reset(): Sending reset command:
avrdude: jtagmkII_send(): sending 2 bytes
avrdude: Send: . [1b] . [07] . [00] . [02] . [00] . [00] . [00] . [0e] . [0b] . [01] . [f6] h [68]
avrdude: jtagmkII_recv():
avrdude: ser_recv(): programmer is not responding
avrdude: jtagmkII_recv(): Timeout receiving packet

avrdude: jtagmkII_reset(): timeout/error communicating with programmer (status -1)
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

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

I never tested it, but in theory you need to apply 12V to the UPDI pin (it needs to be disconnected from the programmer and anything else that might get damaged by 12V).

This will put the pin in UPDI mode until the next power cycle.

So, without disconnecting the target MCU from the power supply, remove the 12V source and reconnect the programmer, it should work (untested by me). You may need to reset or power cycle the programmer.

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

That's exactly what I did. After applying the 12v to the pin I can see on my scope that it is no longer a GPIO pin (it outputs a pulse 1/sec while in GPIO), also a power cycle puts it back to being GPIO. The programmer does start communicating with the 412, but always fails when it tries to do "Sending reset command".

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

That reset is the first time the UPDI interface is actually used, the previous commands are just an exchange of miscellaneous information between avrdude and the programmer.

So that error means the UPDI link is not working, to be honest I don't know why. Have you tried to reset/power cycle the programmer to see if it decides to start talking to the UPDI interface?

 

That is:

 

1) Disconnect programmer

2) Pulse 12V on UPDI pin

3) Connect programmer

4) use avrdude

5) if fail reset programmer then goto 4)

6) If you have repeated the above steps a few times without success, sorry.

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

Thanks for the response El Tangas. Unfortunately that exactly what I have tried many times without success.

Having done some digging it is never getting a response from the target when it requests the ASI_SYS_STATUS value when trying to enter progmode. I have checked it on a scope and I see the SYNC and the LCDS instruction, but there is never a response. The programmer doesn't deal with this well and goes into an infinite loop waiting for PD6 to go low, which it never does.

 

I have no idea why the target isn't responding. The 12V pulse has put it into UPDI mode as it succeeds doing the enable UPDI part.

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

Can you see the double break? These are 2 long low pulses of 24.6ms each. They are needed to initialize the UPDI and should come before the first UPDI command, which is SYNCH/STCS REG2, 0x06   (0x55, 0xC2, 0x06).

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

Yes I see those. Both are 24.6mS with a 2mS high signal between them, followed by the the SYNCH/STCS.

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

Today I etched a new carrier board and mounted a new ATTiny412 so I could plug it into a breadboard. With this fresh chip the programmer works. I suspect there is something about the 12V activation that Microchip aren't telling us in the datasheet. I am wondering if you have to apply the 12V within that 8.8mS timeout after POR, but I have no easy way to test this. For now I am switching to a device where the XDIR pin (that also not documented in the data sheet) is available on something other than the UPDI pin.

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

Hey, I never noticed that XDIR pin. Does it enables/disables the USART transmitter? Do you have any info?

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

Yes it is available on the T412 on the UPDI pin. When you configure the serial port to be External RS485 and fuse the UPDI as GPIO and then set it to be an output the USART automatically manages it for you to control an external driver. I am still waiting to find out what Internal mode is.

 

I found this out when I queried Microchip about some weird behaviour on the LUT-OUT pin when using the CCL.  They sent me a revised port multiplexing table and told me the datasheet was wrong. This new table has the XDIR in it, which is why I initially set the UPDI pin to GPIO so I could use it, but now I can't get it to change back. Microchip said they are working on a revised datasheet for the T412 to fix some errors.

 

 

This is the revised table they sent me. They did say this also may not be 100% accurate. But it explained the problem I was having. Unfortunately for the CCL when using start it uses the incorrect pins from the published datasheet (they are also going to fix that).

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Now, regarding that 12V activation to recover UPDI functionality, the documentation has not kept the same pace as the development.

 

First, for UPDI recovery the high voltage pulse threshold is around VCC*2, so a pulse between VCC*2 and 12V should work fine.

 

The procedure:

 - You can apply the high voltage pulse at any time.

 - When the pulse is applied the device will reset, and wait for a KEY.

    - If a KEY is not received within 65ms the device will continue operation as normal reset, and the pin will go back to it's non-UPDI configuration.

 - Enter the KEY as describe in the "Unified Program and Debug Interface (UPDI)" chapter in the datasheets. In most cases you would enter NVMPROG (0x4E564D50726F6720)

 - Then issue a reset for the KEY to take effect.

 - If you entered the NVMPROG KEY the device will now be in prog mode, and you can set the RSTPINCFG fuse back to UPDI mode.

Last Edited: Wed. May 22, 2019 - 07:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, in that case, since 65ms is about the limit of human perception of time, there is some chance that if you keep the programmer connected, and pulse the UPDI pin with 12V at the same time that you start avrdude, it will be able to connect within the 65ms window.

The 4.7k resistor should limit the current to the programmer's protection diode to (12-(VCC+diode drop))/4700 = less than 1.5mA assuming VCC = 5V. I suppose the protection diode can handle that for a moment. Maybe use an extra 1k resistor between the 12V power supply and the UPDI pin, to further limit current, since you just need about 10V.

 

That is, press S1, release at the same time you start avrdude. I wouldn't recommend this as it stresses the protection diode, but after a few tries it might be possible to connect.

Maybe put an extra Schottky protection diode to VCC would be a good idea?

 

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

Does the UPDI pin have a protection diode?  It was my understanding that the 12V tolerant /RESET pin on earlier AVR does not.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

No, I mean on the programmer's side, to protect it from the 12V.

 

like this:

Last Edited: Tue. Jan 8, 2019 - 07:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
No, I mean on the programmer's side, to protect it from the 12V.
Ah yes, I misunderstood the resistor you were referring to.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Hello El Tangas

 

Nice work.  I'm going to try to use your code as the basis of an ESP8266 program that to allows reprogramming of several connected ATTINY404s over WiFi, all running on 3.3v.  Ignoring the 12V need above, is there any actual reason for the 4.7k resistor between PD6 and UPDI ?  I'm designing the PCB first to accept these surface mount components directly so was wondering if I really need the resistor or not ?  I haven't seen any mention of it in the Microchip documents, but they are generally poor nowadays.

 

Many thanks in advance

 

                                             Vcc                     Vcc
                                              +-+                     +-+
                                               |                       |
 +----------+          +---------------------+ |                       | +--------------------+
 | PC       |          | Programmer          +-+                       +-+  Target            |
 | avrdude  |          |                     |      +----------+         |                    |
 |       TX +----------+ RX              PD6 +------+   4k7    +---------+ UPDI               |
 |          |          |                     |      +----------+         |                    |
 |       RX +----------+ TX                  |                           |                    |
 |          |          |                     |                           |                    |
 |          |          |                     |                           |                    |
 |          |          |                     +--+                     +--+                    |
 +----------+          +---------------------+  |                     |  +--------------------+
             JTAGICE MkII                      +-+     UPDI          +-+
             Protocol                          GND     Protocol      GND
Last Edited: Fri. Jan 11, 2019 - 10:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The resistor is not absolutely required, but since this is a bidirectional line, there is a small chance a short might develop if things go wrong.

I wouldn't omit the resistor. I adapted the design from pyupdi which was written by Atmel people and they use a resistor, so...

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

Ah ok - that makes sense.  Thanks very much

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

je_ruud wrote:

Now, regarding that 12V activation to recover UPDI functionality, the documentation has not kept the same pace as the development.

 

First, for UPDI recovery the high voltage pulse threshold is around VCC*2, so a pulse between VCC*2 and 12V should work fine.

 

The procedure:

 - You can apply the high voltage pulse at any time.

 - When the pulse is applied the device will reset, and wait for a KEY.

    - If a KEY is not received within 65ms the device will continue operation as normal, and the pin will go back to it's non-UPDI configuration.

 - Enter the KEY as describe in the "Unified Program and Debug Interface (UPDI)" chapter in the datasheets. In most cases you would enter NVMPROG (0x4E564D50726F6720)

 - Then issue a reset for the KEY to take effect.

 - If you entered the NVMPROG KEY the device will now be in prog mode, and you can set the RSTPINCFG fuse back to UPDI mode.

 

Back in September, I know for sure I was able to reprogram chips multiple times with the UPDI turned off, and I was doing it manually (no way it was timed within 65mS), touching a 12v supply lead to the programming pin.

 

Now I am not able to find any manual sequence that will allow me to reprogram the "bricked" chips -- which agrees with what  je_ruud says.

 

But what was allowing it to work manually before? I wish I had written down what I was doing more clearly :-(

 

For now, I have resigned myself that the 8-pin package ATtiny412 only has 5 pins that are usable, and left the UPDI as a dedicated pin. This invalidates the ATtiny412  for all but one of my intended uses.

 

Going with a (smaller, faster, more pins, reasonably usable and cheap SWD, and about the same price through my distribution) MKL03Z8VFG4 for the other projects :-(

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

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

Last Edited: Sat. Feb 2, 2019 - 08:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

baxsie wrote:
MKL03Z8VFG4
baxsie wrote:
Going with a (smaller, faster, more pins, reasonably usable and cheap SWD, and about the same price through my distribution) MKL03Z8VFG4 for the other projects :-(

 

That seems to be over a UK£1.   Surely the ATTINY412 is about one third the cost ?

 

But yes the whole programming the UPDI devices is a poorly documented mess !!   I'm using the 14 pin ATTINY404 which is cheapest at RS but leaving the UPDI pin unused for anything else.

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

Hi everyone, I'm playing with an ATtiny402. I'm able to write, compile and upload code to it through Atmel Studio and the jtag2updi running on an Arduino Nano. Having successfully connected the Nano to Atmel Studio for uploading purposes, does anyone have any ideas about how to get it recognised as a debugger? As the D in UPDI is for debugger and the JTAG part that Atmel Studio should be talking to can carry a debugging conversation between PC and uC, what would need to be done to get the Nano recognised as a debugger?

 

BTW, when I go to Tools\Device Programming in AS7, The Tool dropdown menu shows me a choice of Simulator or STK500 on my Nano's COM port. I know @ElTangas wrote this as an STK500 system (although I'd appreciate someone telling me how it identifies itself to AS7 as such) but can we do something that makes AS7 treat it as a debugger too? 

 

Thanks

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

smerrett79 wrote:
... but can we do something that makes AS7 treat it as a debugger too?
A very significant effort as the the debugger protocol is proprietary.

Edit : EDBG protocol is open and at Embedded Debugger-Based Tools Protocols User's Guide

 

 

 

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

Last Edited: Thu. May 16, 2019 - 01:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


smerrett79 wrote:
BTW, when I go to Tools\Device Programming in AS7, The Tool dropdown menu shows me a choice of Simulator or STK500 on my Nano's COM port. I know @ElTangas wrote this as an STK500 system (although I'd appreciate someone telling me how it identifies itself to AS7 as such) but can we do something that makes AS7 treat it as a debugger too? 

 

Actually, jtag2updi doesn't use the stk500 protocol, so you can't connect it to AS7 as an STK500. It uses a related, but different protocol called JTAGICE MkII.

The reason is that stk500 is quite old and doesn't support anything remotely similar to UPDI, while JTAGICE MkII supports PDI (xmega) which is close enough so that a little tweaking of the chip definitions inside the avrdude.conf file is enough to make it work with avrdude.

 

Now, why didn't I use something like stk600 or EDBG? The problem is that these use a USB interface instead of a COM port, and I have no experience with USB programming...

 

The problem of implementing a debugger is that the D in UPDI is (almost) undocumented. I have a bit on information, but certainly not enough to do something like that. At most, the programming interface could allow limited "debug" activities like r/w to SRAM and I/O registers, since it can access the whole memory space, not just flash and EEPROM.

 

 

edit: Basically, the programming/debugging tool is a bridge that translates the host/tool protocol to the tool/target protocol (in both directions).

Although the host/tool protocols are fully documented, the tool/target protocols are documented only in what regards programming; the debug part is proprietary. This makes it very difficult to make "homebrew" debugger tools.

 

Last Edited: Thu. May 16, 2019 - 09:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@gchapman thanks

 

@ElTangas thanks for all the work you did on jtag2updi and continuing to support those of us that want to know more. That diagram is very helpful. I did note your deliberate and efficient use of a COM based protocol when I first tried jtag2updi out - I would have done the same, were I to have your skills. I understand now that implementing the D in UPDI is a challenge.

 

You mention that we can read/write to memory so even reading a register value (which is the prime reason I would like a debugger) while the IC is running would be an amazing capability for me. Have I got any chance of this working with the current jtag2updi setup by using an avrdude command to read a memory address while the chip is running? I'm specifically thinking about the ADC conversion result in the ATtiny402 and perhaps a variable that I have set (although not sure quite how to give my variable a memory address that I know and will not change - you can smell the noob from there I imagine!).

 

  

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

Why dont you invest a little bit and buy Atmel ICE ? it supports the 0 series. it has full programming/debugging capability.

 

in the AS7, you can put the ADC_result value in the watch window if thats what you mean, there is also the I/O window so you can check all the registers value.

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

Moe123 wrote:

Why dont you invest a little bit and buy Atmel ICE ? it supports the 0 series. it has full programming/debugging capability.

I absolutely will. I'm also trying to make these chips more accessible for others who don't want to splurge on the ICE or similar if they're just dipping their toes in the water, for example if they want to take advantage of the 0 and 1 series ATtinys but have only used Arduinos before. With AS7, jtag2updi and beginner-friendly instructions, I think it's possible to equip someone to try these chips out and decide if they want to go further (perhaps investing in an ICE when they start to value the convenience and features).

Last Edited: Fri. May 17, 2019 - 09:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Moe123 wrote:
in the AS7, you can put the ADC_result value in the watch window if thats what you mean, there is also the I/O window so you can check all the registers value.

This is the effect I'd be trying to achieve in a less polished way with the jtag2updi/avrdude

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

El Tangas wrote:
maybe not everyone wants to invest in a Atmel-ICE

In this case:

- go to farnell.com

- search for ATTINY416-XNANO

- here you have integrated UPDI programmer and DEBUGGER for every chip with UPDI for only 7,85 EUR

 

Alternatively you can buy ATmega4809 Curiosity board. It has power supply with regulated voltage (setting in Atmel Studio). Cost of the board is 9,50 EUR.

 

No need for any avrdude anymore, no usbasp, no need to waste time on thinking how to do something that is already done and cheap

extronic.pl

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

extronic wrote:

El Tangas wrote:
maybe not everyone wants to invest in a Atmel-ICE

In this case:

- go to farnell.com

- search for ATTINY416-XNANO

- here you have integrated UPDI programmer and DEBUGGER for every chip with UPDI for only 7,85 EUR

 

Alternatively you can buy ATmega4809 Curiosity board. It has power supply with regulated voltage (setting in Atmel Studio). Cost of the board is 9,50 EUR.

 

No need for any avrdude anymore, no usbasp, no need to waste time on thinking how to do something that is already done and cheap

 

 

Although I almost agree with you. but i think his point is that he wants to develop something out of curiousity...maybe he thinks he can sell it for cheaper price, while me and you thinks that this is completly a waste of time, well, for him it looks different. In everycase I dont even see the point of the whole project that he is doing. but I wish him good luck, its nice to see new ideas always...

 

Regards,

Moe

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

extronic wrote:

 

Alternatively you can buy ATmega4809 Curiosity board. It has power supply with regulated voltage (setting in Atmel Studio). Cost of the board is 9,50 EUR.

 

No need for any avrdude anymore, no usbasp, no need to waste time on thinking how to do something that is already done and cheap

 

Well, those things were not around when I started the project. I even have a couple of SNAPs and ATmega4809 Curiosity Nano boards, I would never buy the Atmel-ICE which IMO is grossly overpriced. 

 

Moe123 wrote:
Although I almost agree with you. but i think his point is that he wants to develop something out of curiousity...maybe he thinks he can sell it for cheaper price, while me and you thinks that this is completly a waste of time, well, for him it looks different. In everycase I dont even see the point of the whole project that he is doing. but I wish him good luck, its nice to see new ideas always...

 

I agree with you, there is no point to the project _now_. But on late 2017, when I started it, the only way to program UPDI chips was with Atmel ICE.

You will notice that I rarely recommend people asking about "how do I program my UPDI chip?" to use my software, unless they really don't want to spend _any_ money and already have the needed materials (i.e. a Mega328 based Arduino).

 

On the other hand, my time is never "wasted", I'm semi-retired so I have plenty of free time and I mostly do only what I want wink this project was also a way for me to learn/experimenting with C++.

 

If I wanted to make an hardware product, it would need to be able to do high voltage (12V) UPDI programming, to offer an advantage over the cheap Microchip programmers (e.g. for debricking UPDI chips where the programming pin had be accidentally disabled).

Pages