Propeller programming parallel flash chip

Comments

• Heater. Posts: 21,230

  2017-09-01 19:48

  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 Green Posts: 23,101

  2017-09-01 20:53 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 hydra Posts: 212

  2017-09-05 17:52

  Thank you...for the replies. That makes total sense:) Off to purchase some chips
• wmosscrop Posts: 406

  2017-09-05 19:57

  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 hydra Posts: 212

  2018-02-26 17:45 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?
• jmg Posts: 15,144

  2018-02-26 18:55

  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 hydra Posts: 212

  2018-02-26 20:00

  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
  
• jmg Posts: 15,144

  2018-02-26 20:13

  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" ?