why does LarduinoISP fail verification step?

[whyameye]

When I use LarduinoISP I noticed that the -V flag is set so the verification step is skipped. I tried using LarduinoISP without the -V flag and the verification step fails. I'm assuming this is expected and explains why the -V flag is set. Do we know why the verification fails? Is there a way to verify that the code was written successfully?

[whyameye]

AFAICT we don't have a way currently to verify that code is correctly uploaded to the LGT8Fx boards and when debugging flakey issues I'm finding this unnerving. Looking into this, I wrote a simple sketch to verify that the 1st 80 bytes are written correctly by comparing what is in address 0 of PROGMEM with the hex of the compiled program. I'm finding the beginning 20 or so bytes often have small discrepensies for the LGT8Fx board and not for the ATMEGA328p nano board I am comparing it with. I used the bootloader for both boards. I'm also finding that when loading in the same code into the LGT8Fx board, the descrepencies seem inconsistent. Why would this be and does it signify a bigger issue?

test code:

void readMem() {

  for (uint16_t addr = 0; addr < 16*5; addr += 1) {
    uint16_t myByte = pgm_read_byte_near(addr);
    if (!(addr % 16))
      Serial.println();
    if (myByte < 0x10)
      Serial.print("0");
    Serial.print(myByte, HEX);
  }
  return;
}

void setup() {
  Serial.begin(115200);
}

void loop() {
  Serial.println();
  Serial.println();
  Serial.println();
  readMem();
  delay(5000);
}

LGT8F328p output from serial port:

0C94003A0C9465000C9465000C946500
0C9465000C9465000C943D000C946500
0C9465000C9465000C9465000C946500
0C9465000C9465000C9465000C946500
0C94A7010C9465000C9413020C94ED01

LGT8F328p data extracted from HEX file:

0C943D000C9465000C9465000C946500
0C9465000C9465000C9465000C946500
0C9465000C9465000C9465000C946500
0C9465000C9465000C9465000C946500
0C94A7010C9465000C9413020C94ED01

LGT8F328p raw contents of HEX file:

:100000000C943D000C9465000C9465000C94650004
:100010000C9465000C9465000C9465000C946500CC
:100020000C9465000C9465000C9465000C946500BC
:100030000C9465000C9465000C9465000C946500AC
:100040000C94A7010C9465000C9413020C94ED0120

ATMEGA328p output from Serial Port:

0C9435000C945D000C945D000C945D00
0C945D000C945D000C945D000C945D00
0C945D000C945D000C945D000C945D00
0C945D000C945D000C945D000C945D00
0C94A2010C945D000C9412020C94EC01

ATMEGA328p data extracted from HEX file:

0C9435000C945D000C945D000C945D00
0C945D000C945D000C945D000C945D00
0C945D000C945D000C945D000C945D00
0C945D000C945D000C945D000C945D00
0C94A2010C945D000C9412020C94EC01

ATMEGA328p raw contents of HEX file:

:100000000C9435000C945D000C945D000C945D0024
:100010000C945D000C945D000C945D000C945D00EC
:100020000C945D000C945D000C945D000C945D00DC
:100030000C945D000C945D000C945D000C945D00CC
:100040000C94A2010C945D000C9412020C94EC012F

[vklimk]

Bootloader changes vector table which is located in the very beginning of flash.

[whyameye]

@vklimk thanks for this. I'm trying to find documentation about this vector table and how the flash is laid out. Are you referring to the virtual boot partition?

[vklimk]

There is a datasheet fot lgt8f328p translated from Chinese to English. You can start with it. Or you can start with documentation for atmega328p. Vector table starts from 0x0 for both MCUs. And bootloader has to modify the table in order to run at restart. After bootloader made its job it passes control to uploaded user application.

[whyameye]

I found the interrupt vector table on page 60 of this datasheet. Thanks for getting me down this path.

[whyameye]

I'm finding that LArduinoISP actually passes the verification step at least some of the time, so I think it most likely that a verification fail is actually a connection or other hardware error.