Shop OBEX P1 Docs P2 Docs Learn Events
Propeller programming parallel flash chip — Parallax Forums

Propeller programming parallel flash chip

dr hydradr hydra Posts: 212
in Propeller 1
Has anyone used a microchip parallel flash chip such as SST 39VF010? I’m looking to use one as a ROM device with my propeller chip. I’m reading the data sheet for information on programming the chip, however, the example only shows programming for one byte. Ex..load data AAH @ 5555H then load data 55H @2AAAH then load data A0H @ 5555H then load my data @ my address waiting for end of program..done.

I’m looking to program a buffer of 32K of data. Do I need to repeat all the load data steps for each data write or should the program loop after the three (setup) load data items and program each of my bytes then waiting for end of program? The data sheet also state “Before programming, the sector where the byte exists must be fully erased”. So I’m thinking the data would have to be programed in a buffer type loop, instead of one byte at a time; or it would fail writing multiply bytes in a sector

Comments

  • Heater.Heater. Posts: 21,230
    I have no idea about this device but it is quite possible that when programming it one can turn a 1 into a 0 but 0's cannot be turned into 1's As such the thing needs blocks erasing to all 1's first. Or vice versa, switching 0 and 1. Such was the case with old ultra violate erasable ROMs and FLASH ROMs later.


  • Mike GreenMike Green Posts: 23,101
    edited 2017-09-01 21:00
    Usually these flash chips have "Erase Sector" and "Erase All" commands. The size of a sector depends on the device ... look at the datasheet for the device for details. You supply an address somewhere within a sector to specify which sector to erase ... again check the datasheet for details. The "Erase All" (or some similar name) erases the whole device ... usually to all 1 bits. There's a serial flash driver written in Spin that's in the Propeller Object Exchange (ObEx) url="http://obex.parallax.com/object/668"]obex.parallax.com/object/668[/url. The parallel interface devices work in a similar fashion.
  • dr hydradr hydra Posts: 212
    Thank you...for the replies. That makes total sense:) Off to purchase some chips
  • wmosscropwmosscrop Posts: 409
    If you're interested in learning about flash programming, I have some unneeded SST25VF016B chips you can have for free.

    They're 16 Mbit SPI serial flash (8 pin SOIC).
  • dr hydradr hydra Posts: 212
    edited 2018-02-26 17:51
    I'm getting back to this project and I have ran into another issue(s). First the chips are 5V...therefore, I'm going to need to put 3.3K on all the data lines...is that correct? All the Address lines should be fine as the propeller 3.3v should be able to drive the 5v memory chip.

    The second issue is related to the data# polling and toggle bit in the internal program operations of the memory chip. Byte programming is data AAH at 5555H--- data 55h at 2aaah ----data a0h at 5555h ----then data(your data) at address(your address)...seems simple...however, the next step Data# polling or toggle bit seems to reverse the data lines from receiving data to ouputting data. How does this effect the propeller pins. Will it cause damage to the propeller? Do you need to change the pins from output to inputs? Not sure how that works?
  • jmgjmg Posts: 15,173
    dr hydra wrote: »
    ....however, the next step Data# polling or toggle bit seems to reverse the data lines from receiving data to ouputting data. How does this effect the propeller pins. Will it cause damage to the propeller? Do you need to change the pins from output to inputs?
    Yes, whenever the Memory OEN & CEN pins are low, it drives the data pins, so Prop pins need to be inputs at that stage.
    Conversely, with WRN & CEN low the memory is expecting Data-IN, so prop pins need to drive valid data at the time WRN is released to HI

    It is common to place series R's of 220~470 R on general device programmers, to protect each side and that covers damaged/reversed memory parts too...
    Your code could drive pins, then read-back to confirm a match, and signal an error if ever a miss-match occurs.
    Some programmers also raise/lower Vcc when doing verify, to confirm margins, depends how complex you want this :)

    If this is just to store data, rather than to program many parallel parts, why not use a SPI part instead ?
  • dr hydradr hydra Posts: 212
    jmg

    Thank you for the response...so if I understand correctly, the problem with a propeller pin receiving input information (3.3v) when set as output ports, is that the current draw could exceed the max mA, causing damage to the pin(s). Is that correct?? Therefore the series resistor will limit the current draw on the pins...keeping both the propeller and memory chip within a safe range on the mA draw. If that is true, I can include the resistors and I should be fine. Plus, I'm or already planning on using 3.3Ks on the data lines for the 5v issue with the memory chips.

    PS...the parallal flash are need for speed...serial SPI would be too slow for the graphics on working on:) ALso, I'm stuck using 5v flash memory chips because I need DIP(s) and the only DIP flash memory chips I can find are 5v
  • jmgjmg Posts: 15,173
    dr hydra wrote: »
    PS...the parallal flash are need for speed...serial SPI would be too slow for the graphics on working on:) ALso, I'm stuck using 5v flash memory chips because I need DIP(s) and the only DIP flash memory chips I can find are 5v
    Could you maybe use SRAM and either battery, or a SPI preload on boot ?

    Or maybe PLCC package, sockets on 0.1" ?
Sign In or Register to comment.