1
Bus Pirate Development / Firmware 6.1 - Binary SPI mode issues?
While writing my own SPI tool to read/write SPI EEPROMS (for those who care: It's on Github) I came across several issues (only tested with firmware 6.1).
a) Illegal firmware state. I got the firmware into modes where it was stuck in binary mode - sending a 0x00 resulted in BBIO1, sending 0x0f to return to Terminal mode just returned a 0x01). This usually happened after I aborted my program during a page read. There was another stuck mode where only powercycling could break me free, but I can't remember what it was...
b) CS pin control. Set CS Low / Set CS High Commands (0x02/0x03 in SPI mode) do no check for Hi-Z, so if it's Hi-Z setting with CS set to 1 via command 0x4x setting to 0 fails (pin still is input). Same is true for Write/Read with CS (0x04), though that one does not use IOLAT but SPICS. Only manually setting/clearing CS with Set Config (0x4x) got me anywhere. This is a bit annoying, since it will also always toggle the AUX pin to output if I read the firmware correctly.
c) Not a binary mode issue, just an observation: sniffing in Terminal Mode gets stuck in overrun mode once an overrun occurs. From the firmware source code there's no clearing of the overflow flag.
d) Sniffing in "Sniff All" Mode (0x0d) will not read the CS flag, thus reporting every pair of data in [] regardless of CS state. It also gets me garbage only, but see e) below.
e) Sniffing in "Sniff CS Low" Mode (0x0e) gets me only a fraction of the read data (though I'm not sure what the data rate is, since the chip can run on upto 75MHz...). I can clearly tell that the first byte that is sniffed is not a valid EEPROM command.
f) command 0x01 does not re-setup SPI, just print the version string.
Any input for the above issues is appreciated.
Regards,
Christian