1
Show Posts
This section allows you to view all Show Posts made by this member. Note that you can only see Show Posts made in areas you currently have access to.
Messages - csch
2
Bus Pirate Development / Re: Firmware 6.1 - Binary SPI mode issues?
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 ;)
3
Bus Pirate Development / Re: Bus Pirate firmware v6.2 development
I can confirm that the bpv3-spifix.hex indeed fixes the SPI clockrate issues.
Regards,
Christian
4
Bus Pirate Development / Re: Firmware 6.1 - Binary SPI mode issues?
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
5
Bus Pirate Development / Re: Bus Pirate firmware v6.2 development
Can you take a quick look at
http://http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=4367
and fix the speed line & think about how you'd change CS handling? Problems persist in 6.2-1862.
Regards,
Christian
6
Flashrom / Re: slow read M25P16
On first glance through flashrom (which I wanted to scavenge for their SPI flash code since that's what I'm toying with) it didn't look like it was switchig serial speed at all.
7
Bus Pirate Development / Re: Firmware 6.1 - Binary SPI mode issues?
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
8
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