03_jm_flash_explorer.spin2 - I broke it

rogersyd

Hi all. I am experiencing challenges with a bit of code, hoping someone can provide a second or third set of eyes. I'm just a hack really, so excuse the crude code please

I am using JohnnyMac's 03_jm_flash_explorer.spin2 and have this bit of code write a block of data to the onboard flash on the P2 Edge. This code works correctly (see working.jpg):

pub writedc()|addr, t,n,x

  addr := $12_0000
  t := getct()
  addr &= $FFFFFF00
  repeat x from 0 to 1                                             ' force to page boundary
    flash.wr_page(addr+(x*256), @dc[x*256])
    repeat while flash.busy()
  t := getct() - t - 40
  term.fstr1(string("Write time: %.3fms\r\r"), t/US_001)
  term.str(string("Wrote flash at ",13))
  term.hex(addr)

However, when i try to turn "writedc" into a callable method with parameters using the code below, the data is not written completely to the flash. It appears to load the first 5 items from @dc just fine, and the rest becomes corrupt. (see broken.jpg) In this example, i have rewritten writedc to accept three parameters (the starting memory location to write to, the number of pages, the location of the data). To write a new block of data, first clearsomething wipes the block (this works), then writesomthing (this is broken), then readsomething back out (works).

pub testseq()

    clearsomething(dcID)  ' works as expected 
    waitms(100)
    writesomething(dcID,dcRepeat,@dc)   ' broken 
    waitms(100)
    readsomething(dcID,dcBytes,dclen,dccount,dcAttr)  ' works as expected 

pub writesomething(towrite,torepeat,todata)|t,n,x,addr

  addr := towrite
  t := getct()
  addr &= $FFFFFF00
  repeat x from 0 to torepeat                                            ' force to page boundary
    flash.wr_page(addr+(x*256), todata[x*256])
    repeat while flash.busy()
  t := getct() - t - 40
  term.fstr1(string("Write time: %.3fms\r\r"), t/US_001)
  term.str(string("Wrote flash at ",13))
  term.hex(addr)

The entire code is attached below. (it is really a mess sorry...) I was hoping to replace all the bespoke write functions with a single method i could just pass parameters into. I managed to get this working for the erase (clear) and read (display in terminal) functions, but the write function has me pounding my head on the table. I did try this with other blocks of data, and it yields similar results (meaning that much of data is written correctly, and then becomes janky after the first several bytes.)

If you happen to run this yourself, from the main menu, use option "2" (undocumented) to run the testseq() method.

To use the working writedc() method instead, use "g" to clear the space, "u" to right the data, and "n" to read it back.

This is not a mission critical project, but I would appreciate any advice. I could continue to write a bespoke method for every block of data i need to write, but I would prefer a general purpose function, as there will be many data types ill need to eventually write to the flash. Thanks in advance to the community for your advice (and for JohnnyMac for supplying the original code - as per usual.)

rogersyd

Reading the quickbyte again: "The 16MB Flash array is organized into 65,536 programmable pages of 256 bytes each. Up to 256 bytes can be programmed at a time. Pages can be erased in blocks of 16 (4KB) or 256 (64KB). Flash blocks must be erased before they can be programmed." I should be able to wrap my head around what is happening now that I re-read that. Read the manual much?

evanh

Ah, yes, the curse of EEPROMs, Flash being the most extreme of them. SD cards have a busy life hiding all this.

rogersyd

Well found a work around i guess. Probably not the most efficient way to do this but its workable, and still enables me to use a single write method, so I will take it as a win, if anyone is keeping score. Moving the repeat loop from the write method and repeating the call multiple times for each 256 byte page works, but I am still buffered while the other way didn't work. This workaround still feels like a kludge and will require more typing but whatever, Im moving on.

pub testseq()|x

    clearsomething(outcomeID)
    waitms(100)
    repeat x from 0 to outcomePages
      writesomething(outcomeID+(x*256),@outcomes[x*256])
    waitms(100)
    readsomething(outcomeID,outcomelen,outcomecount,outcomeAttr)


pub writesomething(towrite,todata)|t,n,x,addr

  addr := towrite
  t := getct()
  addr &= $FFFFFF00
  flash.wr_page(addr,todata)
  repeat while flash.busy()

JonnyMac

You have big address gaps in you data addresses. Will all of your data fit in 4K? It it will, consider reorganizing your storage so that you can read a 4K page into a RAM buffer and operate on that. It will certainly be faster. When done, erase that 4K block and then write the RAM buffer to it.

so excuse the crude code please

White space can be your friend. I suggest you start by redefining your memory locations. Consider something like this

con { memory locations }

  TM_BASE   = $10_0000

  TM_ID     = TM_BASE + $0000
  TM_SHORT  = TM_BASE + $0010
  TM_NICK   = TM_BASE + $0020      
  TM_CITY   = TM_BASE + $0030
  TM_CON    = TM_BASE + $0040
  TM_DIV    = TM_BASE + $0050


  POS_BASE  = TM_BASE + $0100

  POS_ID    = POS_BASE + $0000
  POS_SHORT = POS_BASE + $0010 
  POS_LONG  = POS_BASE + $0020
  POS_SIDE  = POS_BASE + $0030 

With the page read into RAM, you should be able to determine the array offset by subtracting TM_BASE from your named constant.

rogersyd

Thanks for the advice Jon. The C3 version of this game I am porting over to spin2 is much cleaner and better organized - I swear. I think at this point I am good to go here - thanks again for your demo code. After I integrate these methods into the old game (and update the rest of the code to spin2) I will be right back to where I was on the P1/C3 several years ago when I abandoned this project for the next shiny one. LOL. Good times.