Using custom Atmega 8u2 programmer. Need advices.

[troisiemetype]

Hello.

I've designed a programmer, based on the Atmega 8u2, that I'm trying to get to work with megaTinyCore.
The programmer can be found here, it's intended to be both a ISP and UPDI programmer, with a switch for changing mode.
Please note that while testing, I've removed the mosfets on the lines, I figure out they were not needed, as well as the physical pull-up resistors. The actual setup is :
TX ----- BAT54 diode ----- (RX) ----- 470R ----- to board (and back to MISO, unset, so 3-stated input)
(Of course I've also added VCC to the uC. Can't believe I miss that when reviewing the board !)

The code is quite simple, just echoing back Serial USB to hardware UART, and back.

But I can get it to work with any of the programmers options available in megaTinyCore. What I have tried so far :

• Attaching the programmer to an Arduino echoing serial, to check that something is indeed send. It is, but what is strange is that the programmer doesn't echo back when connected to the other Arduino.
• Upload to the target board using Arduino nano as jtag2updi. As the board I want to program is custom-made, I wanted to be sure that it's ok. jtag2updi is successful.
• Changing usb endpoints and serial buffer size in Arduino core. They default to 16 bytes for uC that have less than 1024 bytes of SRAM. Changing it to 32 bytes doesn't change anything.
• Trying different serial speed for the hardware UAT used on the 8u2. 115200 and 57600 tried.
• Adding a size limit in the send() function in the python script, as suggested here. No more success.
• Try the only USB to serial adapter I have, which is based on the CP2102 USB to serial. No success.
• Try to use pymcuprog with my programmer, from outside Arduino, this is ok.

You'll find above the program uploaded to the 8u2, as well as the output of Arduino when trying to upload a simple blink program to the Attiny 816.

At this point I'm stuck, I really don't know where to look, any advice would be very welcome.

Thank you.

/*
8u2 Pinout
[NC] = Not connected on ISP/UPDI programmer

[NC]	D0 - PB0 PCINT0
		D1 - PB1 PCINT1 					SCK
		D2 - PB2 PCINT2 					MOSI
		D3 - PB3 PCINT3						MISO
		D4 - PB4 PCINT4						BOARD RESET
		D5 - PB5 PCINT5 					MOS_MISO
[NC]	D6 - PB6 PCINT6
		D7 - PB7 PCINT7 TIMER1C 			LED_3

[NC]	D8 - PC7 INT4
		D9 - PC6 PCINT8 TIMER1A 			LED_1
		D10 - PC5 PCINT9 TIMER1B 			LED_2
[NC]	D11 - PC4 PCINT10
		D12 - PC2 PCINT11 					MODE

[NC]	D13 - PD0 INT0 TIMER0B
[NC]	D14 - PD1 INT1
		D15 - PD2 INT2 USART1 				RX
		D16 - PD3 INT3 USART1	 			TX
[NC]	D17 - PD4 INT5
		D18 - PD5 PCINT12		 			MOS_UPDI
[NC]	D19 - PD6 INT6
		D20 - PD7 INT7 					 	BOARD_RESET_SW
*/


#include "Arduino.h"

// By default, use hardware SPI pins:
#ifndef PIN_MOSI
#define PIN_MOSI 	MOSI
#endif

#ifndef PIN_MISO
#define PIN_MISO 	MISO
#endif

#ifndef PIN_SCK
#define PIN_SCK 	SCK
#endif

// Configure the baud rate:

//#define USB_BAUDRATE	19200
#define USB_BAUDRATE	115200
//#define USB_BAUDRATE	1000000

#define UPDI_BAUDRATE 57600


const uint8_t RESET = 4;
const uint8_t LED_HB = 9;
const uint8_t LED_ERR = 10;
const uint8_t LED_PMODE = 7;
const uint8_t MODE_SW = 12;

const uint8_t RX = 15;
const uint8_t TX = 16;

const uint8_t MOS_MISO = 5;
const uint8_t MOS_UPDI = 18;

const uint8_t BOARD_RESET_SW = 20;

void setup() {
	Serial.begin(USB_BAUDRATE, SERIAL_8E2);

	Serial1.begin(UPDI_BAUDRATE, SERIAL_8E2);
//	Serial1.begin(UPDI_BAUDRATE);

	// Serial pins
	pinMode(RX, INPUT_PULLUP);
	pinMode(TX, OUTPUT);

	// LED pins
	pinMode(LED_PMODE, OUTPUT);
	pinMode(LED_ERR, OUTPUT);
	pinMode(LED_HB, OUTPUT);

	// mode switch
	pinMode(MODE_SW, INPUT_PULLUP);

	// board reset switch
	pinMode(BOARD_RESET_SW, INPUT_PULLUP);

	// MOSFET pins (UPDI or SPI select), direction then, immediately, value
//	pinMode(MOS_MISO, OUTPUT);
//	digitalWrite(MOS_MISO, 1);

//	pinMode(MOS_UPDI, OUTPUT);
//	digitalWrite(MOS_UPDI, 1);

	// pulse leds
/*
	pulse(LED_PMODE, 2);
	pulse(LED_ERR, 2);
	pulse(LED_HB, 2);
*/
}

uint8_t hbval = 128;
int8_t hbdelta = 4;
void heartbeat() {
	static unsigned long last_time = 0;
	unsigned long now = millis();
	if ((now - last_time) < 10) return;

	last_time = now;
	if (hbval > 250) hbdelta = -hbdelta;
	if (hbval < 5) hbdelta = -hbdelta;
	hbval += hbdelta;
	analogWrite(LED_HB, hbval);
}

void loop(void) {
  // light the heartbeat LED
	heartbeat();

	if (Serial.available()) {
	    Serial1.write(Serial.read());
 	}

	if (Serial1.available()) {
		Serial.write(Serial1.read());
	}
}

updi upload.txt

[SpenceKonde]

That is the same error you would expect if there were no response whatesover from the target.

Please clarify what yo mean by "Try to use pymcuprog with my programmer, from outside Arduino, this is ok." Which pymcuprog? The one we supply, or the virgin version of it from microchip? The two are almost completely different after I got through improving the (miserable) performance. for SerialUPDI.

What values are you using for read chunk and write chunk, if any?

When you connect the updi line to your oscillocsope, what do you see? Compare the initial signalling that works with iniitial signaling that doesn't work. You should be able to see the line getting pulled low, and that one side is better able to pull it low than the other, resulting in the minimum values on the UPDI line all being one od two values a fraction of a volt above ground.

Is the wiring that does and doesn't work the same?
I wonder if you're runn

[troisiemetype]

Hi Spence, Thank you for your answer. I'm away for a week, but there are questions I can answer from here.

The pymcuprog I've used is the one for Microchip, I believe. The one installed using Pip.

I've tested the progam by echoing between the programmer and another Arduino using two instances of a serial terminal. I use short words, like "echo", or "follow".

I won't be able to try oscilloscope until I come back (and I will have to make another programmer, it seems I've bricked both with a disconnection during programming), but I'll sure have a look and will tell you.

The wiring is the same when using Serial2UPDI inside Arduino, or microchip's pymcuprog. Both for the programmer and for the target board. The first one was wrong, but I've changed it after looking and reading better at all the resources available on this repo.

[SpenceKonde]

Hmmmmm......... Wasn't the pymcuprog from microchip miserably, unbearably slow? It generally is (as in, to an insane extent; that's because no effort was exerted by them to maximize performance. Few adapters are capable of getting > 1kbyte/s.

On a serial console, with other end connected to a normal serial adapter, turn off the automatic line endings on both serial console programs.
Try sending a message of length 31, 32, 33 bytes, and 63, 64, and 65. Similarly, try sending messages of those lengths from the classical (well-behaved) adapter.

My prediction is either:
a) 32 or 33 bytes and everything larger will break because of the buffer size.
b) 64 byte data packets are handled wrong (it's a cursed size in USB, and this afflicts many

a) indicates that the buffer you mentioned must be large enough to hold all the data to be sent or that was received. This means you could make it work by specifying a sufficienctly short read and write chunk size. This will impact performance severely.

No ATmega u2-series part has sufficient sram to have a maximum length outgoing message and a maximum length incoming message buffered; the maximum length the computer sends in one go is like 540ish and the most we ask the target to read back is the mximum it is capable of, 256 words or 512b. A 30 cent CH340N will get the job done and unlike the ATmega u2 series, you wouldn't have burned out two of them so far without doing anything violently wrong with them (the u2, on the other hand, will burn out if you intently at the power supply rails and imagine voltages outside the specs.

b) on the other hand indicates that there is a bug in the code running on the 8u2 and you should complain to the author of the core or maintainer of that firmware. whenever there is a payload of exactly 64b size the protocol mandates the host send a subsequent message with length of zero (a "ZLP").

The reason we use te crazy buffer sizes we do is to imoprove performance by eliminating USB transfer latencty cycle. Even with my having removed any that could be combined with adjacent commands, at TURBO speeds on a tinyAVR, the transfer time is still more than 50% of the time just sitting around waiting for the OS to finally check if the serial port got anything and deliver it to the application with the open serial port. By globbing together a whole bunch of consecutive commands (including Response Signature Disable, which is a night-and-day difference on write; we turn it back on while not writing so we know if we're our of sync). Meanwhile the big trick for read is to do a REP255 (repeat next command 255 times) followed by LD *ptr++intruction, which increments the address it's reading from hence reading 512b at a time. Reading 1 word at a time takes many times longer.

[SpenceKonde]

The use of an additional serial adapter as a "spy" is also an incredible help for seeing what exactly your device is doing. Just take a third serial adapter, and tie it's RX to the UPDI line, and the ground to ground. Most adapters don't have added pullups on RX that would interfere.

[troisiemetype]

Hi Spence. Thank you for this really complete answer. I believe the most important thing in your answer is he part about the memory available on the 16 / 32u2. I should have think of it before I start this design. So instead of a SPI + UPDI programmer I end with an SPI only programmer. At least it's far more handy thant the nano I've used for years ! :)

For UPDI I will probably follow your advice, and do something with a FTDI or some other USB to serial adapter. I knew that USB speed can be drastically optimized by using the right packet size, there is a clear write about it somewhere at PJRC, about Teensy.

Back to the drawing board. :)