ATtiny84a SPI communication disabled following chip erase

Question

I am attempting to serially program an ATtiny84a using an ATmega645a. I am able to enter programming mode and read the device signature bytes, but after issuing a chip erase command, the ATtiny stops responding. It appears as though the SPI bus has been disabled, as I can no longer enter programming mode, and data is no longer transmitted over MISO. The board with the ATtiny can be programmed using the Atmel ICE programmer without issue prior to my attempts to program it using the ATmega. However, once I've tried my ATmega programmer, I can no longer use the Atmel ICE, as the ATtiny fails to enter programming mode.

I suspect the SPIEN fuse is being corrupted during execution of the chip erase command, but I am not sure how or why. Per the ATtiny datasheet, the status of fuse bits is not affected by a chip erase. In fact, it explicitly states the SPIEN Fuse is not accessible in SPI programming mode.

I have attached a screenshot of the ATtiny in the schematic and its PCB layout for reference. The net labeled "A" is a 24V signal indicating the state of a G5V-1 relay. During execution of the programming code, 0.05V is present on the line. Pins PA3 and PA7 are inputs to the onboard ADC and are reading voltages off of two discrete voltage dividers. Pins PB1 and PB2 are not connected.

Additionally, here is the snippet of code where everything seems to go wrong:

static int isp_send_chip_erase_command(void) {
    const uint8_t command[] = {0xAC, 0x80, 0, 0};
    uint8_t response[4];
    spi_master_transfer(response, command, 4);
    if (response[1] != command[0]) {
        return -1;
    }
    return 0;
}

void spi_master_transfer(uint8_t *recv, const uint8_t *send, size_t n) {
    if (!send) return;
    for (size_t i = 0; i < n; ++i) {
        spi_master_transmit(send[i]);
        if (recv) recv[i] = spi_master_receive();
    }
}

void spi_master_transmit(uint8_t data) {
    SPDR = data;
    while (!(SPSR & (1 << SPIF))) {}
}

uint8_t spi_master_receive(void) {
    return SPDR;
}

I would appreciate any insight you might be able to share. I've already bricked two of these processors, and given the increasing difficulty of ordering silicon, I'd prefer not to ruin any more. Please let me know if there is any additional information I can provide that would assist in reaching a solution.

Answer 1

Note: This answer has been "converted" from the comments after OP @DFunke confirms that issue seems to be fixed by adding the required polling on RDY/nBUSY after issuing "Chip erase" command.

You could also overwritten RSTDISBL or clock source fuses to end up the same. Are you sure you've followed a correct programming procedure as described in section 19.5.1 of the datasheet? Also a bit offtopic suggestion - you can google for "AVR Fusebit Doctor" device which can be assembled from cheap parts and can "cure" your AVRs in HV mode.

Chip erase & write fuse bit commands are just 1-2 bit difference... still doesn't explains if you get this issue right after 1st chip erase attempt. Have you waited enough time after issuing chip erase command (as per datasheet)?