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

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
mark4th
mark4th's picture
Level: Wannabe
Joined: Mon. Mar 16, 2015
Posts: 77 View posts
#1
Posted by mark4th: Thu. May 2, 2019 - 03:32 PM
  • 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

Tags:

Tools, Compilers and General Programming, solved
Last Edited: Thu. May 2, 2019 - 10:33 PM
Top
angelu
angelu's picture
Level: Posting Freak
Joined: Sun. May 28, 2006
Posts: 1013 View posts
Location: Toronto, Canada
Posted by angelu: Thu. May 2, 2019 - 07:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

PIC32 based Ethernet Shield Arduino Uno hardware compatible

PIC32 based Ethernet Shield with Network Switch Arduino Uno hardware compatible

Top
mark4th
mark4th's picture
Level: Wannabe
Joined: Mon. Mar 16, 2015
Posts: 77 View posts
Posted by mark4th: Thu. May 2, 2019 - 08:11 PM
  • 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

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100736 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. May 2, 2019 - 08:18 PM
  • 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).

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21680 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Thu. May 2, 2019 - 09:04 PM
  • 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

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
mark4th
mark4th's picture
Level: Wannabe
Joined: Mon. Mar 16, 2015
Posts: 77 View posts
Posted by mark4th: Thu. May 2, 2019 - 09:18 PM (Reply to #5)
  • 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

Top
mark4th
mark4th's picture
Level: Wannabe
Joined: Mon. Mar 16, 2015
Posts: 77 View posts
Posted by mark4th: Thu. May 2, 2019 - 09:19 PM (Reply to #4)
  • 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

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4698 View posts
Location: SF Bay area
Posted by westfw: Thu. May 2, 2019 - 10:00 PM
  • 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.

 

Top
mark4th
mark4th's picture
Level: Wannabe
Joined: Mon. Mar 16, 2015
Posts: 77 View posts
Posted by mark4th: Thu. May 2, 2019 - 10:03 PM (Reply to #8)
  • 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

Top
angelu
angelu's picture
Level: Posting Freak
Joined: Sun. May 28, 2006
Posts: 1013 View posts
Location: Toronto, Canada
This reply has been marked as the solution. 
Posted by angelu: Thu. May 2, 2019 - 10:24 PM
  • 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

PIC32 based Ethernet Shield Arduino Uno hardware compatible

PIC32 based Ethernet Shield with Network Switch Arduino Uno hardware compatible

Top