1
\$\begingroup\$

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.

ATtiny Schematic

ATtiny PCB Layout

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.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – NStorm
    Aug 30, 2021 at 13:44
  • \$\begingroup\$ Thanks for the input. That makes sense, but I'm still uncertain as to how the fuses could have been overwritten. I am assuming I have followed the programming procedure correctly as I have been able to read the correct device signature bytes. I can see the signal come over MISO on the scope during the initial exchange, but after performing the chip erase, the MISO line is just low amplitude noise during attempted SPI exchanges. \$\endgroup\$
    – DFunke
    Aug 30, 2021 at 15:33
  • 1
    \$\begingroup\$ 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)? \$\endgroup\$
    – NStorm
    Aug 31, 2021 at 8:51
  • 1
    \$\begingroup\$ I think that might have been it. I added in a poll RDY/nBUSY function following issuing the chip erase command and it appears to be working now. Thanks for your help! \$\endgroup\$
    – DFunke
    Aug 31, 2021 at 15:29

1 Answer 1

1
\$\begingroup\$

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)?

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.