Hi there!
While writing my own SPI tool to read/write SPI EEPROMS (for those who care: It's on Github (http://https://github.com/chrschmidt/spitool)) 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
Hi Christian and welcome! :)
Can you check the 6.2 firmware. There were lots of bugfixes in that, which may have addressed those issues. You can access it over here (http://http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=4007#p40057).
Hi tayken,
The CS (not) driving in Hi-Z mode bug is definitey still there.
The weird firmware state bug, too:
select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
Timeout, no data available for 100ms. This is just to clear any possibly pending data.
write(3, " ", 1) = 1
select(4, [3], NULL, NULL, {0, 2000}) = 1 (in [3], left {0, 950})
read(3, "BBIO1", 5) = 5
Looks like a successful switch to binary mode, but....
write(3, "17", 1) = 1
nanosleep({0, 20000000}, NULL) = 0
select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 99996})
read(3, "B", 1) = 1
select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 99996})
read(3, "B", 1) = 1
select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 99996})
read(3, "I", 1) = 1
select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 99996})
read(3, "O", 1) = 1
select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 99996})
read(3, "1", 1) = 1
select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
It refuses to leave the mode.
This strace output shows my program writing 17 (octal, 0x0F hex) and getting a reply of "BBIO1" and nothing more. I don't really know in what state it is in, but in BBIO1 mode it should jump back to terminal mode upon receiving 0x0F, I think. This occurs in a loop for 20 tries in a row, before my program gives up. My other comments were based on a software version checked out from sourceforge.
There's also some bug with SPI speeds. Using speeds > 2000 makes the program run far longer (bus pirate 3.5c).
static unsigned char binSPIspeed[]={0b00000,0b11000,0b11100,0b11101,0b00011,0b01000,0b10000,0b11000};
(SPI.c) should be
static unsigned char binSPIspeed[]={0b00000,0b11000,0b11100,0b11101,0b00011,0b01011,0b10011,0b11011};
There's also no reason to seprate binSPIspeed from SPIspeed, by the way. if you need to save 8 bytes, that's an option.
Regards,
Christian
Hi Christian,
SPI speed problem was addressed before, there is a fix about it in this message (http://http://dangerousprototypes.com/forum/viewtopic.php?f=40&t=3864&start=15#p41505) as an attachment. If that doesn't do it, I also did my own fix for v3, wtich you can find over here (http://http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=4340#p42691).
So you are saying issues a, b and f are still there am I right? Can you tell me about c,d and e in 6.2?
I have a couple of questions:
1) For a, did you try sending a couple of reset commands or just one? What about sending a couple of "Enter"s? In one of the libraries, there was a command like that to save it from stuck mode while you are at user interface mode (the non-binmode one)
2) For f, 0x01 in SPI mode is just there to get version, it has no other special property. If you want to go to default settings you either have to set them bu sending commands (like 0b0100wxyz commands) or go back to raw binmode and enter SPI mode again, there are functions there to reset it.
Hi tayken,
Yes, I saw the flashrom related discussion. I just fail to set up a firmware compiler here ;)
In a), the init I use works like this:
- send up to twenty 0x00. If there's a "BBIOx" reply, assume binary mode entered. Sometimes I get 0x07 back, sometimes 0x01 - no exact idea when that happens.
- if that failed, send up to 20 "r" (might be stuck in terminal mode in a questionaire) until there's something ending with ">" but not ")>", then retry the twenty 0x00. Abort init attempt if there's still no BBIOx reply.
- Once there's the BBIO reply, switch back to terminal mode by sending a 0x0f, and extract version information from the string. Up to twenty attempts, again. If that worked, assume Terminal Mode with HiZ state.
What I see is that the first 0x00 immediately gets the BBIO1 reply, but 0x0f does just the same. This state is mostly reached after aborting the program while the receive section of a Binary SPI mode subcommand 0x04/0x05 is running. This may or may not be related to a bug in the RTS/CTS serial port handhaking between the FT232 and the PIC - with hardware handshake enabled I can't communicate with the bus pirate at all. Maybe it's just a desync of the UARTs, and nothing but a reset can be done. Without the handshake the PIC will send its pending data to the FT232 which will just ignore it. That would explain the behavior, since I can't see a code path that would cause it.
For the sniffing issues I'd have to hook up the device I'm sniffing again, which is quite some effort. I might give it a try later today.
Regards.
Christian
One quick nore, there is no RTS/CTS handshaking. You have to connect to buspirate with 115200 baud, 8N1. If you enabled handshaking, that may cause some problems as there are no handshaking codes in the firmware as I know.
If you are using 0x04 or 0x05 commands, it can help to check out avrdude source. I was looking at it when we were trying to solve the reset problem after introducing BPv4 and it was nice to see an actual code piece for binary SPI operation, really nice example.
What are your problems about setting a complier? Maybe we can solve that too. :) BTW, I will be logging into IRC today (tonight), if you want we can discuss it more real-time over there.
Seems that sniffing works now - the results changed with your software (different from what I got earlier) :)
Thank you again!
Bus Pirate 3.5, Firmware 6.2 (r1862), Bootloader 4.4 found.
Entered binary SPI mode version 1.
Press any key to abort
CS Switched to low
'.' 03 3 - '.' 00 0
'.' 00 0 - '.' 00 0
'.' 00 0 - '.' 00 0
'.' 00 0 - '1' 31 49
'.' 00 0 - '1' 31 49
'.' 00 0 - '1' 31 49
'.' 00 0 - 'S' 53 83
'.' 00 0 - '8' 38 56
'.' 00 0 - '2' 32 50
'.' 00 0 - 'N' 4E 78
'.' 00 0 - '0' 30 48
'.' 00 0 - 'H' 48 72
'.' 00 0 - '3' 33 51
'.' 00 0 - '0' 30 48
'.' 00 0 - '0' 30 48
CS Switched to high
…
(interestingly it ends with the first byte of a read address sent, and CS low... hm... needs more LEDs ;)
OK, disregard the last part, buffer was overrun. At 2MBit serial speed it captured everything correctly.