Do you absolutely need to erase a page before writing it? (spm)

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

If i **KNOW** that a page is erased do i still need to perform the page erase operation in order to initialize the internal flash write temp buffer?

 

I ask this question because the documentation states that you can only modify the bytes within said temp buffer one time and that if you want to modify them again you must perform an erase.

 

For example if i have a buffer in ram containing the data I want to write out to flash and i know the page is erased i write each byte of my ram buffer out to the temp flash write buffer using repeated spm instructions. I then do a flash page write spm and the data is now written to flash.  No erase operation occurred.

 

I now compile a new block of data in my ram buffer, attempt to write this out to the flash temp buffer and... am i now breaking the rules because no erase operation has occurred? Does the hardware consider my actions to be a modification of already modified flash temp buffer bytes because no erase has occurred?

This topic has a solution.

If something can be read without effort then great effort has gone into its writing

Last Edited: Thu. May 2, 2019 - 10:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you copy / paste that text including chapter and what device is about here ?

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

atmega32u4 page 339 filling the temporary buffer (page loading)

 

"Note that it is not possible to write more than one time to each address without erasing the temporary buffer"

 

If something can be read without effort then great effort has gone into its writing

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

I think you've misinterpreted the text. Sure you fill, the page buffer then issue the write and it "eats" the buffer contents so you can only use that once without refilling (so you couldn't  easily write the same data to multiple pages). But there's no real issue with writing ghd same page multiple times but it's NAND flash so you can only ever make 1 to 0 bit transitions. As soon as even one but in one byte needs to make a 0 to 1 transition you have no alternative but to erase the entire page (all bits returned to 1).

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

Seems to me like there is an inherent mismatch at play here. Fourth, which this seems to be aimed at, needs to execute out of data memory, if I recall correctly. If that memory is not RAM of some sort, then you run into a wall writing new data to it. Harvard architectures, which includes AVRs and PICs and many others, simply do not allow you to execute as you would like.

 

Kind of like hitting your head against the wall and expecting, some day, the wall will be softer.

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

I have written forths for numerous harvard architecture devices

If something can be read without effort then great effort has gone into its writing

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

You missed the point

 

1: fill buffer with data to be written out to flash

2: write data to pre-erased page xxx

3:  fill buffer with more data

4: write data to pre-erased page xxx+1

 

there was no erase operation and im filling the temp buffer a second time.  Im not trying to write data to the same page, if i need to do that ill read the data out to ram, modify it and then erase and write the page back.

If something can be read without effort then great effort has gone into its writing

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

AMFORTH writes new forth words to flash, using code in the bootloader section (of course.)
I haven't looked in detail at how it works, but I might - in theory the latest Optiboot (Arduino) bootloader provides application access to SPM, so AMFORT or similar could become loadable as an Arduino sketch.  (ok, it may be a bit unlikely that most Arduino users would be interested in running Forth.  But I bet a lot more would be willing to try it if it was a bootloader-loadable sketch, rather than something that required ISP re-programming of the chip.)

 

Usually Forth words are "threaded" code - think of them as a series of (Forth) function addresses that a very minimal "engine" fetches and "calls."  Only the very primitive functions are actually CPU-specific code that is actually "run" on the CPU, so it's relatively immune to Harvard-ness of an architecture.

 

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

threading can be direct, indirect, token or subroutine.  The easiest to code is direct threading but "usually" on harvard arch indirect threading is used.  I have done forths with every threading except token - this one is direct threading because it is significantly more space efficient than subroutine threading on avr and not significantly slower

 

If something can be read without effort then great effort has gone into its writing

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


mark4th wrote:

You missed the point

 

1: fill buffer with data to be written out to flash

2: write data to pre-erased page xxx

3:  fill buffer with more data

4: write data to pre-erased page xxx+1

 

there was no erase operation and im filling the temp buffer a second time.  Im not trying to write data to the same page, if i need to do that ill read the data out to ram, modify it and then erase and write the page back.

 

It says that the buffer is erased after you write it to the flash page

By the way, I would erase the buffer manually once, before writing to it for the first time - your 1: fill buffer with data to be written out to flash