Harry Lemmens wrote:
Chris, I take back what I said in my last post! The TI document SLAS272C states
essentially what you have said, (see page 15) although slau049b implies that the
infomem flash is outside of the "main" flash modules.(It seems that TI document
writers may be somewhat schizophrenic! Although, SLAS272C is specific to the
MSP430F149, so other family members may operate differently!?)
It took me a while to realise that the document was talking about the flash
array, and not the "segments" within that array. (512 bytes, or 256 bytes for
INFOMEM flash)
So, it would seem that the flash busy bit is superfluous, unless you are running
your routines from within SRAM.
slau049c.pdf section 5.3 (page 134) says:
Reading or writing to flash memory while it is being programmed or erased is
prohibited. If CPU execution is required during the write or erase, the
code to
be executed must be in RAM. Any flash update can be initiated from within
flash memory or RAM.
This is far from clear. However, what really happens if the code is
running from flash is the CPU stalls. It will stall for about 75us on a
write, and 16ms on an erase. As you noted, running a program within RAM
would allow CPU operation to continue, but this is a somewhat academic
issue, except for mass flash programming operations - how often would
you be able to run a useful program in the limited RAM while the flash
erases or programs?
All the MSP430 flash parts use the same architecture. What works for one
will work for them all. By the way, the infomem is in 128 byte pages.
Not 256 as you said above. One thing that does not seem to be documented
is what happens to the flash between 1100 and 11FF on the 60K parts. It
actually works as a 256 byte page, from my tests.
-----Original Message-----
From: mspgcc-users-ad...@lists.sourceforge.net
[mailto:mspgcc-users-ad...@lists.sourceforge.net]on Behalf Of Chris Liechti
Sent: Sunday, December 07, 2003 2:27 PM
To: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Re: 2x 128Bytes self read/write
Steve Underwood wrote:
Daniel Néri wrote:
Steve Underwood <ste...@coppice.org> writes:
You can't write bytes. You have to write whole 16 bit words.
Sorry, but this is simply not true. MSP430 flash memory is bit-, byte-
and word-programmable.
Then tell us how. The rest of us only know how to program whole 16 bit
words, including the chip's designers. Everyone else gets the effect of
programming a bit or byte in the way I described. You write a whole
word, where the bit you don't want to change are set to 1.
sorry, but the data book is not on your side ;-)
it states that one can write a byte, word or series of them.
see slau049c.pdf section 5.3 (page 134) and following.
from what i understand, you can actualy use any instruction to write to
flash, including bic.b bic.w, mov., mov.w, etc. (except "bis", it wont
help much ;-)
the restrictions are, that you can only clear bits, that a write to the
flash is slower and that you must not access flash while writing is in
progress (can only happen if your program runs from RAM).
Well you certainly cannot program bit by bit, as the Daniel Neri said.
None of the memory in the MSP430 is bit addressable. Things like bic.w
are read-modify-write operations. The doc does seem to support what you
said about byte writing. However, I seem to remember from trying it on
real chips what only word writing is possible. Whatever, it is easy to
achieve the desired effect by a word write with the bit to be left
unprogrammed set to 1.
Regards,
Steve
