# AT89LP51ED2 SPI ISP — First attempt to enter ISP mode after reset yields wrong data back, but second attempt works

I have a board using an AT89LP51ED2 from Atmel -- this is an 8051-derivative with on-board Flash program memory and a SPI ISP interface, which I am using my Bus Pirate to drive (30kHz speed, pullups ON and wired to the board Vcc, default SPI settings otherwise, the AUX pin driving /RESET). The ISP protocol is documented by Atmel, both in the datasheet and in this Atmel app note -- overall, it is superficially similar to AVR SPI ISP except for the use of 2 prefix bytes (which makes it incompatible with avrdude). Programming mode requires an entry command -- the two prefix bytes of 0xAA 0x55 followed by 0xAC 0x53 and a dummy 0x00, which should return 0x53 back to indicate the device is in ISP mode.

So, I have set out to implement the protocol myself, using the Bus Pirate binary SPI mode, its associated Python module, and a bit of custom Python scripting on my own end -- however, I noticed my Python script would only enter ISP mode intermittently. I was able to reproduce the fault manually using the Bus Pirate's terminal interface, starting from a cold boot of the board:

SPI>a
AUX LOW
SPI>{ 0xaa 0x55 0xac 0x53 0x00 ]
/CS ENABLED
/CS DISABLED
SPI>{ 0xaa 0x55 0xac 0x53 0x00 ]
/CS ENABLED
/CS DISABLED
SPI>


The fault in particular is that in the first command, the ISP interface echoes back 0xA7 instead of the 0x53 it should. Resetting the board allowed me to reproduce it again, and capture the sequence on my oscilloscope, including a glitch LOW for half a clock at the end of the last 0xFF it shifts out:

So, what am I doing wrong? Is this a protocol issue on my end? Or should I be suspecting a faulty microcontroller, or worse yet, an erratum in the programming implementation? Should I simply work around this in my ISP script?

• Created Atmel support case #36278 for this, BTW (this Q is linked in the case, as well) – ThreePhaseEel Mar 4 '16 at 4:17
• Atmel could not reproduce in the support case -- got past this using a workaround in my ISP script but leaving this up in case someone finally cracks this mystery. – ThreePhaseEel Aug 24 '16 at 0:53