Dataflash reset problems

Basil · 2007-10-04 09:50

Hi All,

Im having a few issues with the 16Mbit SPI dataflash im using.

I can get it to write and read now problems using both buffers, however if a prop reset occurs, or the power cycles, during a read/write routine, it corrupts all the data and I have some major issues using the DF for a bit.

I then erase the entire chip (using 512 block erase's) and attempt to write again. For some time afterwards, the writes only write 1's...well at least thats what I see when i play it back.

After leaving it for a while things just fix themselves, or at least they seem to!

Here is a snippet of code I use. When the prop first boots, DF_SCK is set to 1 and all pins are outputs.
To do anything, first I combine the opcode with the address etc and call DF_Send(data, 32), then DF_send any data required, the DF_END

PRI DF_Send(data,bits)
  dira[noparse][[/noparse]DF_DATA]~~
  dira[noparse][[/noparse]DF_SCK]~~
  dira[noparse][[/noparse]DF_CS]~~
 
  outa[noparse][[/noparse]DF_CS]~
  repeat 1
  outa[noparse][[/noparse]DF_SCK]~
 
  data <<= (32-bits)
  repeat bits
    outa[noparse][[/noparse]DF_DATA] := (data <-=1) & 1
    repeat 1
    outa[noparse][[/noparse]DF_SCK]~~
    repeat 1
    outa[noparse][[/noparse]DF_SCK]~
 
PRI DF_Recieve(bytes) : temp
 
  dira[noparse][[/noparse]DF_DATA]~
 
  if byte > 4
    bytes := 4
 
  repeat (8*bytes)
    temp <<= 1
    temp := temp | ina[noparse][[/noparse]DF_DATA]
    outa[noparse][[/noparse]DF_SCK]~~
    repeat 1
    outa[noparse][[/noparse]DF_SCK]~
    repeat 1
 
  Return temp
 
 
PRI DF_End
 
  dira[noparse][[/noparse]DF_DATA]~~
  outa[noparse][[/noparse]DF_CS]~~
  outa[noparse][[/noparse]DF_SCK]~~

Any help/experience appreciated!

Alec

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Ale · 2007-10-04 16:46

After writing, are you waiting enough time to let the chip do the actual write to flash ?. Regarding the RESET, may be you should use the WP pin, if any is available, and tie it to RESET or *RESET accordingly. That could help.

Fred Hawkins · 2007-10-04 18:42

There is a recent thread that suggested using a large (gold?) capacitor to keep the system voltage high enough to prevent a reset while the prop finished writing (to a sd card?).

Found it, was Mike Green:

"If that (a brownout) is important, use a large enough electrolytic capacitor across the regulator output to keep the Propeller functioning for a substantial part of a second and use an I/O pin to measure the unregulated input to the 3.3V regulator. Best is to use a voltage divider. If the input to the 3.3V regulator is from a 5V regulator, divide the 5V down so you get about 1.5V when the input to the 3.3V regulator is about 4.5V. Tie that to a Propeller I/O pin. It will normally be high. As the input to the 3.3V regulator drops below 5V, the I/O pin will go from high to low indicating that power loss is emminent and your backup cog can write what it has and everything else can come to an orderly halt waiting for the expected power off to occur.

You'll have to figure out how to recover when the power comes up again."

in this thread: http://forums.parallax.com/showthread.php?p=677938

Post Edited (Fred Hawkins) : 10/4/2007 7:44:59 PM GMT

Basil · 2007-10-04 19:53

Thanks for the feedback guys [noparse]:)[/noparse]

Unfortunatly this is not an issue regarding brownouts as that is already solved.

This latest problem occurs when I perform a reset by pulling the reset pin low (via the prop tool and PropTerminal).

It corrupts all my data and make the DF useable Im just now trying to figure out how to make it useable again)

Re. the write times.

I am alternating between buffers so when 1 is writing I can fill the other one etc etc etc.

Each buffer takes 1.35 seconds to fill which give it plenty of time to do its thing [noparse]:)[/noparse]

Thanks for the suggestion though.

Any thoughts?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Fred Hawkins · 2007-10-04 22:01

I don't understand why you would force a reset when you are writing to the dataflash. Maybe you need to put an interlock on that line or at least a LED to indicate writing is still going on. And reading too, I suppose.

Basil · 2007-10-04 22:09

Hi Fred,

Its not so much of a problem when the device is in operation, but while testing there are some cases where I need to re-program the device while it is performing its function (ie logging data).
The prop tool resets the device first, which is what is causing the problems. [noparse]:([/noparse]

If I reset between writes/reads there is no problem, but im logging at 128Hz so its gets tricky trying to reset within 7.8ms :P

Also, lets say the user of the device is playing back the data while they connect the usb cable to upload the data to a PC, this will force a reset and corrupt the data [noparse]:([/noparse]

There is nothing in my code which reset's the prop, its external programs which I wish to interface with that are making my hair fall out [noparse]:)[/noparse]

Alec

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Basil · 2007-10-04 22:11

BTW, I have a feeling its something to do with the CS and SCK lines being in a state of flux after a reset, but when I add code at the beginning of my program which set's these lines to 'default' (ie CS low then high, and SCK high), all the data I write with that simple mod in place becomes 0's [noparse]:([/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Basil · 2007-10-04 22:51

I should also point out this situation arose when I had programmed the prop withcode which put in an infinte 'read' loop so I had no choice but to interupt it [noparse]:([/noparse]

Im trying to code it so that it this occurs again I won't have any problems [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Fred Hawkins · 2007-10-04 22:54

Basil said...
Hi Fred,

Its not so much of a problem when the device is in operation, but while testing there are some cases where I need to re-program the device while it is performing its function (ie logging data).
The prop tool resets the device first, which is what is causing the problems. [noparse]:([/noparse]

If I reset between writes/reads there is no problem, but im logging at 128Hz so its gets tricky trying to reset within 7.8ms :P

Also, lets say the user of the device is playing back the data while they connect the usb cable to upload the data to a PC, this will force a reset and corrupt the data [noparse]:([/noparse]

There is nothing in my code which reset's the prop, its external programs which I wish to interface with that are making my hair fall out [noparse]:)[/noparse]

Alec

Two suggestions: a switch to your software that stops things when you want an software update.·Then remember to push it. And·use an i/o pin·to sends a high to the reset pin whenever you're reading or writing.·(If the reset·from the usb is masked by the high, it never happened, right?)·But brighter minds than mine may have better suggestions, ie ones that work.

Basil · 2007-10-04 22:57

Interesting suggestions [noparse]:)[/noparse] id prefer a software prevention thing but those sounds good if there isn't one [noparse]:D[/noparse]

It was suggested to me that the fact I am operation in mode 3 (read + write on separate datalines) could cause some trouble seeing as I have mine combined on 1 line!

I am testing mode 0 and will let you know how I get on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-Alec

My our page

Dataflash reset problems

Comments