What's the difference between avrdude programmer types stk500v1 and arduino?

Development Tools Uploading
1

I don't seem to have issues using either programmer type when either using arduino with bootloader on USB or arduino as programmer connected to a target arduino over ICSP header. Only difference I see is that if I use bootloader, I get all zeros for fuse values regardless which programmer type I select.

More Nano clone failures
2

Bootloader does not provide such info. It just ignore the command for fuse reading and it is because of its size.

EDIT:
I'm using modified Optiboot for my needs for 1284P and it does the fuse reading. However, 1284p has the least boot region at 1kB. There is plenty of room.

3

Here is a snippet:

	/* STK500 Universal Command */
		} else if(ch == STK_UNIVERSAL) {		// universal command is ignored
			#if defined(BIGBOOT)				// real data
			/* read fuse and lock bits; it takes additional 80 bytes */
				uint8_t ucb1 = getch();			// universal command byte 1
				uint8_t ucb2 = getch();			// universal command byte 2
				getNch(2);						// discard universal command byte 3-4
				uint8_t ucr  = 0;				// response

			/* mapping algorithm for function parameter, optimized to save a space:
				ucb1(0x50), ucb2(0x00) -> GET_LOW_FUSE_BITS     (0x0000)
				ucb1(0x58), ucb2(0x00) -> GET_LOCK_BITS         (0x0001)
				ucb1(0x50), ucb2(0x08) -> GET_EXTENDED_FUSE_BITS(0x0002)
				ucb1(0x58), ucb2(0x08) -> GET_HIGH_FUSE_BITS    (0x0003)
			 */
				if((ucb1 & ~(0x08)) == 0x50 && (ucb2 & ~(0x08)) == 0x00) {
					ucb1  = ((ucb1 & 0x08) ? 1 : 0) | (ucb2 >> 2);
					ucr   = boot_lock_fuse_bits_get((uint16_t)ucb1);
				}
				putch(ucr);
			#else								// universal command is ignored
				getNch(4);						// 4 bytes of data/command
				putch(0x00);					// response
			#endif
4

The arduino programmer type is specialized for the auto reset circuit on the Arduino boards that allows uploading to them without needing to do the manual reset.

5

Thanks @Budvar10 and @pert ! I guess it really doesn't matter too much if I interchange them for the purpose of reading about firmware or writing firmware but for fuse settings, I need arduino as isp and use stk500v1 programmer type.

6

This one from Pololu works well.
Very inexpensive too

7

Yes. This is an interesting case where, even though we're using an Arduino board, we specifically don't want the auto-reset behavior because you don't want the programmer board to reset when you start an upload and the auto-reset on the target isn't used because you're not even doing a serial upload . So using the arduino programmer is problematic.

There were actually a few versions of the Arduino AVR Boards platform that had the Arduino as ISP programmer definition changed to using arduino protocol and this caused a large number of people to no longer be able to use the Arduino as ISP without adding a capacitor to disable the reset on the programmer board (which they had never had to do before, and that some newcomers don't even have the components on hand to accomplish).

This was resolved by reverting the change to the programmer definition and adding a new "Arduino as ISP (ATmega32U4)" programmer definition to support using the ATmega32U4 boards as programmers on Windows (for some reason the arduino protocol is required for this specific use case):

8

Unfortunately, the auto-reset behavior is "automatic" on most systems - the DTR signal used for reset goes "true" (which causes an AVR reset) when the COM port is opened by a PC-side application, and "false" when the port is closed. (this is why sketches will reset when you open/close the serial monitor, or other terminal emulators.)
The code in avrdude that does the explicit DTR wiggling was added to support the small number of systems that didn't do this, or that needed RTS wiggled instead of DTR (certain USB/Serial cables and adapters.)

Avrdude changed at some point, and uses a lot of "raw SPI command" STK500 exchanges instead of specific STK500 commands that would do the same thing. The bootloader has limited support for "raw spi command" (it's not using SPI, after all), and wants the old commands.

Here is stk500v1 reading a device signature:

avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00s
avrdude: Send: V [56] 0 [30] . [00] . [00] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [1e] 
avrdude: Recv: . [10] 
avrdude: Send: V [56] 0 [30] . [00] . [01] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [94] 
avrdude: Recv: . [10] 
Reading | #################                                  | 33% 0.03s
avrdude: Send: V [56] 0 [30] . [00] . [02] . [00]   [20] 
avrdude: Recv: . [14] 
avrdude: Recv: . [06] 
avrdude: Recv: . [10] 
Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9406 (probably m168)

And here is the same setup using the arduino programmer type:

avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00s
avrdude: Send: u [75]   [20] 
avrdude: Recv: . [14] . [1e] . [94] . [06] . [10] 
Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406 (probably m168)
1 Like
9

Thanks westfw. I observed this "raw SPI" behavior while I was porting this protocol to ESP-IDF for ESP32 to flash SPI-connected avr MCUs. I now understand that it was avrdude that made this change, not something that had to be done.

10

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.