Trying to build a reliable command-line tool to Linux to update and query DataFlash partitions for my application, but hitting unreliable read behavior. Have traced the problem down to the SPI layer without encountering any anomalous return codes or parameter value issues. I am using the MTD ioctl interface from a C application, after encounting problem with the MTD utilities and JFFS2, and trying to isolate the problem. Here is what I think I know at this point:

1) Erases work fine
2) Writes work fine
3) Reads work erratically
o Bad data is often returned with no error indication
o Retry will always *eventually* return correct data (this is why I say I have a read problem only)

I am slavishly observing erase-block size and page orientation, word alignment of buffers, and checking every possible error return code. I have put a bunch of printk() statements in the low-level MTD drivers, and everything works perfectly down to the spi layer, which is always returning success codes. This is a custom board, but it is running with a standard 18.432 MHz crystal and talking to an 8MB DataFlash part (AT45DB642D in default 1056 mode). The spi configuration specifies a 10 MHz max speed for SPI, which seems reasonable, although I have no idea how that value should be related to the crystal frequency or the DataFlash part spec (at least 33 MHz).

So, I think the problem is indeed in the spi read code. Does anyone understand that level well? Could this be a DMA problem? A clock speed problem? How to debug if no errors being detected (or possibly not reported) by the low-level spi driver?

- Michael

Hi there

Are there any other SPI devices on your board?
I've encountered a DataFlash I/O problem when two SPI devices have different SPI clock rates specified (DF at 15 MHZ and serial flash at 25 MHZ). When both devices have the same clock rate, DF works fine.

Have you tried a more recent kernel?

BTW how are you sure write ops are OK? Are you verifying using U-Boot?

Regards

Hi blue_z,

There is only the one SPI device on my board, the DataFlash part, so unless the 10 MHz clock setting is inappropriate, then the clock speed should not be an issue.

I know the writes work because when I do a multi-page 'blind' write (without trying to read-back and verify) and reboot, I can recover the data eventually (I can recognize success because it is crc checked), but my experience is that:

1) If I read immediately after boot, I get a good read consistently (once).
2) If I wait a few seconds after boot, I get good reads intermitently (perhaps once every 5 tries).

Today I tried to port my application forward onto the 2.6.30.5 kernel level, and have *almost* succeeded. The primary problem I am having now is that I can't get the SPI layer to work at all on the 2.6.30.5 kernel! During kernel initialization, I get an error about spi0.0 initialization failing, and then of course the MTD subsystem doesn't come up at all, so my /dev/mtdx devices are never created. This is ironic to say the least. I was hoping that the changes between 2.6.26.5 and 2.6.30.5 would improve the reliability of the SPI subsystem, but instead it seems to be completely broken. I will look into it more tomorrow, perhaps there is something simple that I can adjust.

After fighting with the spi support in the 2.6.30.5 kernel, I admitted defeat and reverted to the 2.6.26.5 kernel that I was using before. I tried to get the bit-banging spi driver working, but could never figure it out.

I did finally get the normal dma/irq driver working however! The key change was to reduce the clock speed from the 10 MHz that was configured. I dropped to 2 MHz and all the problems vanished. I have not explored how high I can push it, probably at least to 5 MHz, because I really don't need speed for my application.

This is really puzzling and unexpected, as my DataFlash part is supposed to work to at least 33 MHz, and spi is a synchronous interface that should not be particularly sensitive to clock jitter, for instance. Perhaps it is some limitation on the dma channel? Anyone have any insight into this?

Sorry for bumping this old topic, but we have exactly the same situation now.

Hardware: custom AT91SAM9XE and AT91SAM9260 boards based on the AT91SAM9260-EK kit. The same dataflash chips (the 2nd one is instead of external dataflash card on the EK board).

Software: Linux 2.6.38.2 with forward-ported AT91 patches.

The problem:
- flash write with flashcp to /dev/mtdX works ok (with or without kernel flash write verification enabled). Internal kernel verification during write passes;
- first read by flashcp utility during verification stage may fail (50/50);
- first read/compare with cmp or else may fail too (50/50);
- following reads pass.

All this was observed on a different custom boards with different CPUs (9260 and 9XE256). But all is ok with original EK kit.

Do you have any ideas?

Perhaps you should start by enumerating how your design (schematic, component, supplies and layout) differs materially from the 9260-EK that works properly.

Try taking Linux out of the equation, and validate the SPI performance with stand-alone applications running on the board directly. Look at it with a scope/analyzer.

[quote]Perhaps you should start by enumerating how you design (schematic, component, supplies and layout) differs materially from the 9260-EK that works properly.[/quote]
Looks like that. The ony difference is another tracing of board. It wasn't our design (we are software developers only for this particular project), and we are also sure that the board deign isn't perfect. But since we cannot change it due to some reasons, we have to find a software-only solution for the moment. Maybe lowering of SPI frequency can help.

Whether it is your design or not, it would behoove you to understand the difference so you can validate your software fix.

The design is a copy of EK board, so original uImage for 9260-EK works on the board. The only difference regarding the SPI is that instead of single dataflash chip and DF card slot there are two dataflash chips (of the same type). So only hardware could be the source of the problem (if timing change helps like in the 1st case of this topic).

>> How many software engineers does it take to change a light bulb? None, it's a hardware problem.

Let's hope your solution addresses all the termination, reflection, timing, clock slew issues across production/part variations, and across temperature.

If it's anything like some of the other posters, settling for under 10% of the parts spec'd speed would seem to leave a lot on the table, and still not understand the failure mode.

I'd look very closely as the placement of the chip selects, and how it transitions between devices, and examine where the signal integrity is breaking down.

Anyhow, go kick the hardware designers in the ankles for giving you such a crappy design.

[quote="CptTitanic"]Anyhow, go kick the hardware designers in the ankles for giving you such a crappy design.[/quote]

It seems to be the best solution, as for me, since it can arise in other places too.

But for now disabling the mtd write verification at the kernel level solved this symptom (but, of course, it is not the best way to go).

Anyway, the write verification never faulted, and flashcp performs data compare after write. Since the application mostly does not use the mtd rather than for booting and for kernel+fs updates from the linux level, it might be the temporary solution.