Skip to main content
Topic: Problems with SPI binary mode (Read 3758 times) previous topic - next topic

Problems with SPI binary mode

Hi,

I am testing the v3 and v4 hardware in API mode using the binary protocol.

My first goal is to send-recv 4 bytes of data across the SPI bus using cmd 0x04 or 0x05 (write-then-read command).
The documentation says "The write and read operations happen all at once", however I observe 8 bytes transferred on the SPI bus, not 4.

My guess is that it is writing 4 bytes, discarding the 4 recv bytes, then clocking out another 4 bytes of garbage to recv 4 bytes.

Same behavior on both v3 and v4.

I am using this command rather than the bulk-spi-transfer command because I often need to transfer more than 16 bytes.

Second problem - the v4 hardware switches to binary bit-bang mode (0x00) ok, then switches to SPI mode (0x01) ok, but only the first time. If I switch it back to bit-bang mode (0x00) then it will not longer switch to SPI mode - each time I send a 0x01 command it responds with BBIO1.

Nick

Re: Problems with SPI binary mode

Reply #1
I switched the code to use the Bulk SPI Transfer mode - this seems to work, but only 16-bytes per sequence.

SPI speed - if I set 1MHz or 2MHz it works as expected (at 1MHz/2MHz). If however I set 2.6MHz, 4MHz, or 8MHz the resulting speed it much much slower - setting 8MHz results in a 125kHz clock.

Testing with 2MHz... the clock is correctly running at 2MHz = 500ns / bit = 4us per byte, however there is a 11us delay between each byte. One 16 byte operation should take 64us but actually takes 240us.

Nick

Re: Problems with SPI binary mode

Reply #2
It looks like the Bulk SPI Transfer command is taking 2ms to send-recv 16 bytes (v4 hardware).

This means it will take ~35 minutes to read a 16MB flash chip.
(My other USB-SPI tool will read it in under 5 minutes).

v4 hardware so the bandwidth shouldn't be limited by the virtual uart connection.

Re: Problems with SPI binary mode

Reply #3
[quote author="jafa"]My guess is that it is writing 4 bytes, discarding the 4 recv bytes, then clocking out another 4 bytes of garbage to recv 4 bytes.[/quote]
With SPI, you actually read and write at the same time. When you are sending out some data through MOSI, you also receive some data through MISO. But you are right, binary mode doesn't have a write & read type command, the garbage is 0xff. The behavior can be added in a future firmware, have to adjust a couple of things in the firmware. It is both in v3 and v4 as most of the code is the same for both versions.

[quote author="jafa"]SPI speed - if I set 1MHz or 2MHz it works as expected (at 1MHz/2MHz). If however I set 2.6MHz, 4MHz, or 8MHz the resulting speed it much much slower - setting 8MHz results in a 125kHz clock.[/quote]
This was a bug in one of the old versions. Try firmware version 6.3. It was corrected on firmware 6.2 but it had some bugs so it never got released. 6.3 is under test and you should be able to find it here on the forum.

Re: Problems with SPI binary mode

Reply #4
Hi,

I was running the official release firmware (6.1). I upgraded to the 6.2 beta firmware today... not seeing a 6.3 beta.

I have it reading/writing SPI flash via both Windows and Linux, however the Bus Pirate seems to have a performance problem - each 16-byte operation takes 2ms (sometimes 3ms) to complete.

The odd thing is that the time to complete is always near 2ms or near 3ms... it suggests something might be polling on a 1ms timer.

I understand the v3 hardware is speed limited by the UART bridge, however the v4 hardware shouldn't have this limitation.

My goal is to replace my old slow USB-SPI dongle which takes 4m30s to read 16MB of flash, however the Bus Pirate is currently taking ~40 minutes to read the same 16MB flash.

Nick

 

Re: Problems with SPI binary mode

Reply #5
[quote author="jafa"]I was running the official release firmware (6.1). I upgraded to the 6.2 beta firmware today... not seeing a 6.3 beta.[/quote]
Check out: viewtopic.php?t=5052

[quote author="jafa"]I have it reading/writing SPI flash via both Windows and Linux, however the Bus Pirate seems to have a performance problem - each 16-byte operation takes 2ms (sometimes 3ms) to complete.

The odd thing is that the time to complete is always near 2ms or near 3ms... it suggests something might be polling on a 1ms timer.[/quote]
Hmm, I checked out the firmware. Couldn't find any delays on SPI transmit-read and user interface transmit-read functions. Will check more.

[quote author="jafa"]I understand the v3 hardware is speed limited by the UART bridge, however the v4 hardware shouldn't have this limitation.[/quote]
You are right, it should be faster. At least for some of the stuff it is faster. However, if you're right and we have some sort of delay in the firmware, then our bottleneck is being caused by that delay, not hardware speed limitation.

[quote author="jafa"]My goal is to replace my old slow USB-SPI dongle which takes 4m30s to read 16MB of flash, however the Bus Pirate is currently taking ~40 minutes to read the same 16MB flash.[/quote]
Bus Pirate was initially designed for trying out new ICs easily, it was never meant to do most of the stuff it is doing now. SPI read-writes are the same: It takes too long to program an AVR, Flashrom takes too long etc. The code is so complex now that even Ian has a hard time going through it, there is too much stuff going on.

One suggestion to make things faster would be to write a new firmware for Bus Pirate. Most of the functions are in there, SPI and UI related. Yes, you have to change firmwares but bootloader makes it easier than using a programmer. During that phase, one can actually identify possible bottlenecks, solve them and incorporate them to the BP code.