2009-11-17 07:28 AM
Bulk erase bootloader command via SPI
2011-05-17 06:05 AM
STM8S105C6
I am trying to bulk erase the part via SPI using the precompiled bootloader write/erase routines provided by ST. I am able to write memory locations without issue, so I am fairly certain the SPI transactions are properly set up (though there is always room for error). Here is the code: { tUBYTE Request[4]; tUBYTE Response[4]; tUBYTE AckByte[2]; Request[0] = 0x7F;//SYNCHR Byte Request[1] = 0x80;//NSYNCHR Byte DigitalOutSetDigitalState(dHAL_DO_RESET_SECOND_MICRO, dINACTIVE); SleepMs(10); DigitalOutSetDigitalState(dHAL_DO_RESET_SECOND_MICRO, dACTIVE); SleepMs(5); SpiTransaction(&Request[0], &Response[0], 2); // Put ST into boot mode Request[0] = 0x43; // Erase command Request[1] = 0xBC; // compliment SpiTransaction(&Request[0], &Response[0], 2); // 2 bytes sent SpiTransaction(&AckByte[0], &AckByte[0], 1); // 1 byte sent if(AckByte[0] == 0x79) // ASCII 'y' { Request[2] = 0xFF; // Total erase code Request[3] = 0x00; // compliment SpiTransaction(&Request[2], &Response[2], 2); // 2 bytes sent SleepMs(500); // 500 millisecond delay SpiTransaction(&AckByte[1], &AckByte[1], 1); // 1 byte sent if(AckByte[1] == 0x79) // ASCII 'y' return(eTRUE); // Success } return(eFALSE); // Failure } I receive the ACK after the 500ms delay but when I cycle power, the application code has not been erased. Anyone see any glaringly obvious mistakes?2011-05-17 06:05 AM
*Comic slap to the forehead*
Argh. Order of operations issue. Should probably load the bootloader write/erase routines prior to trying to erase something. Duh! I need more sleep apparently.