SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Hacking multi-tool. Get one for $30, including worldwide shipping.

SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby awagner » Mon Dec 10, 2012 8:15 am

I am writing a set of tools in Python to read/write SPI
devices. They use the standard commandline interface of the
BP, as I did not get binary mode to work and this is
sufficient for my needs. They run on Linux using PySerial.

Now I have run into a bizarre problem, that depending on the
write-size, data gets corrupted in a predictable fashion.

When writing 32 bytes at a time, it works and gives the expected
write pattern (the one 0x00 is intended to be there):
Code: Select all
$ hd flash_data.img
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000020  ff ff ff ff ff 00 ff ff  ff ff ff ff ff ff ff ff  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000680

When writing 64 or 128 bytes, there is an extra 05 at offset 0x27
from the start. For 64 bytes it repeats 4 times in the first
256 bytes, for 128 bytes it repeats two times.

64 bytes written:
Code: Select all
$ hd flash_data.img
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000020  ff ff ff ff ff 00 ff 05  ff ff ff ff ff ff ff ff  |................|
00000030  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000060  ff ff ff ff ff ff ff 05  ff ff ff ff ff ff ff ff  |................|
00000070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000000a0  ff ff ff ff ff ff ff 05  ff ff ff ff ff ff ff ff  |................|
000000b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000000e0  ff ff ff ff ff ff ff 05  ff ff ff ff ff ff ff ff  |................|
000000f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000700

Things I have checked:
- Verified the device erase works by reading it fully
- Tried with a second flash chip (these are AMIC A25L40)
- Ran a memory checker on the host computer
- Programmed more data in 32 byte steps (80kB, including
quite a bit of non-0xff values)

SPI commands used in this sequence:
[0x06 r:0] -> set WREN
[0x02 <3 byte address> <data bytes> r:0]
[0x05 r:1] -> repeat until bit 0 is zero, i.e. write finished

Versions:
- Python 3.2
- PySerial 2.6
- Kernel 3.4.19
- Bus Pirate v3b Firmware v5.10 (r559)
Bootloader v4.4 DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)

Does anybody have an idea what the problem can be?
So far I suspect a firmware bug in the BP or defecitve RAM
in the BP, but I found no notes about this having been fixed
in the newer release notes.
awagner
Newbie
Newbie
 
Posts: 5
Joined: Mon Dec 10, 2012 8:01 am

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby Sjaak » Mon Dec 10, 2012 8:25 am

Did you try entering the commands send by your script manually? Did you try adding delays?
User avatar
Sjaak
Fellow
Fellow
 
Posts: 3056
Joined: Sun Jan 03, 2010 2:45 pm
Location: Hiero

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby awagner » Mon Dec 10, 2012 10:13 am

Delays: No effect. PySerial already forces delays, as there is no other way than timeout to tell a read has finished. Whether I use 20ms or 100ms makes no difference. Just to be sure, a try with 1s had the same effect.

Manual entry: Also no effect. BUT: the BP only echoes the first 39 (=0x27) bytes written in "WRITE:"
and the last one is wrongly 0x00, but 0x05 gets written to the flash to that position.

Interesting.

Now I am convinced this is a BP bug, as it must echo 0x05 if it writes 0x05, but it echos 0x00,
i.e. what it echos and what it writes are different.

Can I use the newest firmware (6.1) with a v3.5c BusPirate? My impression was that 5.10 was the latest
firmware for that hardware, but I did not find anything definite. If 6.1 can be put on my BP, I will
try that next.
awagner
Newbie
Newbie
 
Posts: 5
Joined: Mon Dec 10, 2012 8:01 am

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby awagner » Mon Dec 10, 2012 1:25 pm

I think I have it: There seems to be a line-buffer of 255 or 256 bytes in the BP, and instead of giving an error message, it just writes trash to the SPI bus when it is exceeded.

I would call that a serious defect. It also leads to an asymmetry in the command set: You can read up to 255 bytes, but can only write something like 40, which makes this a design error in addition.
awagner
Newbie
Newbie
 
Posts: 5
Joined: Mon Dec 10, 2012 8:01 am

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby Sjaak » Mon Dec 10, 2012 3:22 pm

You can upgrade to the latest version, but I doubt It will solve your problem (it wont). The mode you are using is mend to be interfacing an human on a 80 char width terminal, so the max length for a command is set to 256 (which should be enough imho). An ASCII 'Bell' is played when about to overflow and it should ignore the char.

The maximum length a command is defined here: http://code.google.com/p/dangerous-prot ... cMenu.h#20

For scripting the BP has a binary mode, which is far more suitable for interfacing a script. You might want to read more about the binmode here: http://dangerousprototypes.com/docs/Bus ... pting_mode
User avatar
Sjaak
Fellow
Fellow
 
Posts: 3056
Joined: Sun Jan 03, 2010 2:45 pm
Location: Hiero

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby awagner » Mon Dec 10, 2012 5:25 pm

The upgrade did indeed not solve the problem.

The bell is not adequate. The adequate reaction is to refuse the command and give an ASCII error, not only a bell (bell in addition to a proper error message is certainly fine). One particular problem is that if the terminal is line-buffered (a perfectly fine setting), the bell is only issued when the command is sent. The user has then no idea what has happened. Also, an user may be cutting&pasting commands and may well exceed the 256 char limit.

In no way is writing wrong data to the SPI bus acceptable, even a short write would be better (but still fundamentally broken).

As to the binary mode, I tried the Bulk "SPI transfer" but could not get any reaction out of my flash device. My guess is that the dummy output bytes that cannot be avoided confuse the flash device. That is why I moved to the interactive mode. I did not try the "write-then-read" command though, maybe I will give it a try.

Anyways, thanks for the help I can now work around this bug.

Is there a formal way to file a bug report about the wrong byte that gets written to the SPI bus and a wish-list item for a proper error message? Alternatively, this limit and behavior may just be _very_ clearly added to the documentation.
awagner
Newbie
Newbie
 
Posts: 5
Joined: Mon Dec 10, 2012 8:01 am

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby Sjaak » Tue Dec 11, 2012 4:06 am

Only the characters that fit into the buffer will get printed. I would opt against a warning message since this will mess up the screen IMO. I did alter the documentation to reflect the 256 buffer limit (it did state incorrectly 4000+ bytes).

Documentation about the userinterface: http://dangerousprototypes.com/docs/Bus ... _interface

An we have a bugtracker here: http://dangerousprototypes.com/track/
User avatar
Sjaak
Fellow
Fellow
 
Posts: 3056
Joined: Sun Jan 03, 2010 2:45 pm
Location: Hiero

Re: SPI 4Mbit flash writing: Extra 0x05 at offset 0x27

Postby awagner » Wed Dec 19, 2012 5:01 am

Thinking about this again form a bit of a distance, I think the corrected documentation will do fine.

Thanks again!
awagner
Newbie
Newbie
 
Posts: 5
Joined: Mon Dec 10, 2012 8:01 am


Return to Bus Pirate Support