Just got my first Dataflash up & running

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How i spend my sunday ......

Just spend an entire sunday trying to get my first dataflash up & running :? :?

I got a few dataflash as samples , but they are TSSOP :cry:

And i spend 3 hours fiddeling , making the the board with stripboard and thin wire.

Then it was time to test it , and i succesfully read the dataflash statusregister (it reads 0x9C) for a 4Mb dataflash that is "idle"..

Then i grabbed the GCC-Butterflly port of the dataflash files , and could still read the statusregister.

Step2 : I snipped some testcode from the butterfly test routines , and thats where the trouble began i always read 0xff :cry:

I did not want to wear out the dataflash , so the fistt thing i did was to write 50 bytes to the dataflash and then read it back .. just once.

Then i looped in a while(1) , and read and printed the statusbyte.

I spend like 6 hours debugging , and was uncertain if i had broken a wire on the adapterboard ... I couldnt test that as i had encapsulated the wires in glue. Because last time i tried this TSSOP trick with wires i broke off one of the dataflash legs , while i was fiddeling with the wire.

So this time i used a gluegun this time to enforce the dataflash end :wink:

The disadvantage of this is that you can not measure on the dataflash legs , and remember not to cross the wires before gluing. So that you are sure what wires comes from what pin. Because the glue is only transparent until it gets cold , and then you just have some wires sticking out of that glue stuff.

I got desperate and got out my LSA , but the timing was fine ,
CS_high was 480ns , and SCK was around 60ns (well maybe pushing a bit..)... but i still read the statusbytes fine , and still read just 0xff from the dataflash even though i had programmed a

for(i=0;i<50;i++) dfwrite(1,i,i);

I did try to slow down SPI and enter lots of strange delays at strange places ... still no luck.

Then i had a look at the statusbyte read routine (cause that was working) . and then i discovered it :oops: :oops:

In the butterfly routines there is a function in the read statusbyte routine that extracts the number of pagebits and the pagesize , and initialises a pair of global variables , from a pair of flashtables.

Guess who did not call the read statusbyte , before jumping to his testroutine , that he also snipped from the butterfly port.

So number if pagebits was zero & pagesize was zero , that was why the dataflash never wrote anytning.

So a thing to remember when using the butterfly dataflash code , is to call
the read statusbyte , just after the SPI init call.

/Bingo

Ohh Btw : Thanx for the port MJT , it worked fine

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ohh am i pushing the SPI to hard ??

Im running SPIX2 speed and CLK/4

Thats basically a spi speed of CLK/2

SPSR = (1<<SPI2X);                                      //SPI double speed settings
SPCR = (1<<SPE) | (1<<MSTR) | (1<<CPHA) | (1<<CPOL);   //Enable SPI in Master mode, mode 3, Fosc/4

Did i see someone mention that SPI needed 4 samples , and should be run at CLK/4

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have prototyped these small pitch devices too, really difficult :( I usually lay the chip on its back, and then bend every other pin to the inside, this gives a bit more room for the soldering iron. But it remains a fiddle ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah, i generally do the up/down pin thing as well when i do the wire wrap wire soldering... and give each wire a careful but firm pull around to make sure it's connected well.

this is one of those cases though where it's often easier to do home circuit boards (although it took me a bit to work out my setup so that tssop pitches would come out right).