According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
Disabling interrupts while writing to flash?
Started by ●February 22, 2008
Reply by ●February 22, 20082008-02-22
m... napisa(a):
According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
Disable interrupts before library calls?
Albert
According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
Disable interrupts before library calls?
Albert
Reply by ●February 22, 20082008-02-22
Oh, are you using proper BOR for reset processing ? Very important with flash
writes.
Best Regards,
Kris
-----Original Message-----
From: m... [mailto:m...] On Behalf Of merapcb
Sent: Saturday, 23 February 2008 12:15 AM
To: m...
Subject: [msp430] Disabling interrupts while writing to flash?
According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
Best Regards,
Kris
-----Original Message-----
From: m... [mailto:m...] On Behalf Of merapcb
Sent: Saturday, 23 February 2008 12:15 AM
To: m...
Subject: [msp430] Disabling interrupts while writing to flash?
According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
Reply by ●February 22, 20082008-02-22
The details of writing to flash, especially on the MSP430, are quite
application-specific. That is, how much time can you you afford to do
the writes, what else is going on while you write it, what are your
clocks doing, what is your supply voltage, do you need to erase before
the write, etc...
But, the good news is that the actual writing to flash is not
particularly difficult. There are tons of examples on TI's web site,
etc. So, why not just write your own application-specific library?
You can get a lot more control over things, and probably end up with a
closer-to-optimal solution.
Stuart
--- In m..., "merapcb" wrote:
> According to TI guidelines, it is important to disable interrupts
> while writing to flash. I am working with a third party library that
> provides a read/write API to the flash, and they have confirmed to me
> that they do NOT disable the interrupts while writing to flash
> (because, stupidly, they assume that doing so will only happen once
> during initialization). My question is, how critical is it to follow
> this guideline? We are facing some code corruption issues (that have
> been traced to power cycling) and I suspect it is related, but I can't
> prove it because I don't have the sources. Any ideas? Thanks.
>
application-specific. That is, how much time can you you afford to do
the writes, what else is going on while you write it, what are your
clocks doing, what is your supply voltage, do you need to erase before
the write, etc...
But, the good news is that the actual writing to flash is not
particularly difficult. There are tons of examples on TI's web site,
etc. So, why not just write your own application-specific library?
You can get a lot more control over things, and probably end up with a
closer-to-optimal solution.
Stuart
--- In m..., "merapcb" wrote:
> According to TI guidelines, it is important to disable interrupts
> while writing to flash. I am working with a third party library that
> provides a read/write API to the flash, and they have confirmed to me
> that they do NOT disable the interrupts while writing to flash
> (because, stupidly, they assume that doing so will only happen once
> during initialization). My question is, how critical is it to follow
> this guideline? We are facing some code corruption issues (that have
> been traced to power cycling) and I suspect it is related, but I can't
> prove it because I don't have the sources. Any ideas? Thanks.
>
Reply by ●February 22, 20082008-02-22
It is not possible to write our own library for this.
And as for why not just to disable the global interrupts before
calling the function, one of the two UARTs is controlled by this
library and we do not know what effect that would have...
--- In m..., "Stuart_Rubin" wrote:
>
> The details of writing to flash, especially on the MSP430, are quite
> application-specific. That is, how much time can you you afford to do
> the writes, what else is going on while you write it, what are your
> clocks doing, what is your supply voltage, do you need to erase before
> the write, etc...
>
> But, the good news is that the actual writing to flash is not
> particularly difficult. There are tons of examples on TI's web site,
> etc. So, why not just write your own application-specific library?
> You can get a lot more control over things, and probably end up with a
> closer-to-optimal solution.
>
> Stuart
>
> --- In m..., "merapcb" wrote:
> >
> >
> > According to TI guidelines, it is important to disable interrupts
> > while writing to flash. I am working with a third party library that
> > provides a read/write API to the flash, and they have confirmed to me
> > that they do NOT disable the interrupts while writing to flash
> > (because, stupidly, they assume that doing so will only happen once
> > during initialization). My question is, how critical is it to follow
> > this guideline? We are facing some code corruption issues (that have
> > been traced to power cycling) and I suspect it is related, but I can't
> > prove it because I don't have the sources. Any ideas? Thanks.
>
And as for why not just to disable the global interrupts before
calling the function, one of the two UARTs is controlled by this
library and we do not know what effect that would have...
--- In m..., "Stuart_Rubin" wrote:
>
> The details of writing to flash, especially on the MSP430, are quite
> application-specific. That is, how much time can you you afford to do
> the writes, what else is going on while you write it, what are your
> clocks doing, what is your supply voltage, do you need to erase before
> the write, etc...
>
> But, the good news is that the actual writing to flash is not
> particularly difficult. There are tons of examples on TI's web site,
> etc. So, why not just write your own application-specific library?
> You can get a lot more control over things, and probably end up with a
> closer-to-optimal solution.
>
> Stuart
>
> --- In m..., "merapcb" wrote:
> >
> >
> > According to TI guidelines, it is important to disable interrupts
> > while writing to flash. I am working with a third party library that
> > provides a read/write API to the flash, and they have confirmed to me
> > that they do NOT disable the interrupts while writing to flash
> > (because, stupidly, they assume that doing so will only happen once
> > during initialization). My question is, how critical is it to follow
> > this guideline? We are facing some code corruption issues (that have
> > been traced to power cycling) and I suspect it is related, but I can't
> > prove it because I don't have the sources. Any ideas? Thanks.
>
Reply by ●February 22, 20082008-02-22
> It is not possible to write our own library for
this.
*** I don't understand. Are you saying you can't write a function to
access the FLASH properly and call that function instead of the one on
the library?
> And as for why not just to disable the global interrupts before
> calling the function, one of the two UARTs is controlled by this
> library and we do not know what effect that would have...
*** But you DO know the effect of NOT disabling GIE!!! You cannot
write flash and not disable interrupts. Period. You got a replay
explaining very clearly why. Simply put, if an interrupt occurs during
flashing, you'll never get back to the main loop.
> they have confirmed to me that they do NOT disable the
> interrupts while writing to flash
*** Then they've wroten bad code. That is a bug in the code and both
you and they know it.
> (because, stupidly, they assume that doing so will only happen
> once during initialization).
*** Why are you still working with them if you know they're stupid?
Any write to FLASH has to be preceded by a disabling of GIE, and
should be followed by restoring the GIE state. Either you get them to
correct that bug and follow specifications, or you get someone else
that is not that stupid.
Michael K.
--- In m..., "merapcb" wrote:
> It is not possible to write our own library for this.
> And as for why not just to disable the global interrupts before
> calling the function, one of the two UARTs is controlled by this
> library and we do not know what effect that would have...
> --- In m..., "Stuart_Rubin" wrote:
> >
> > The details of writing to flash, especially on the MSP430, are quite
> > application-specific. That is, how much time can you you afford to do
> > the writes, what else is going on while you write it, what are your
> > clocks doing, what is your supply voltage, do you need to erase before
> > the write, etc...
> >
> > But, the good news is that the actual writing to flash is not
> > particularly difficult. There are tons of examples on TI's web site,
> > etc. So, why not just write your own application-specific library?
> > You can get a lot more control over things, and probably end up with a
> > closer-to-optimal solution.
> >
> > Stuart
> >
> > --- In m..., "merapcb" wrote:
> > >
> > >
> > > According to TI guidelines, it is important to disable interrupts
> > > while writing to flash. I am working with a third party library that
> > > provides a read/write API to the flash, and they have confirmed
to me
> > > that they do NOT disable the interrupts while writing to flash
> > > (because, stupidly, they assume that doing so will only happen once
> > > during initialization). My question is, how critical is it to follow
> > > this guideline? We are facing some code corruption issues (that have
> > > been traced to power cycling) and I suspect it is related, but I
can't
> > > prove it because I don't have the sources. Any ideas? Thanks.
> > >
>
*** I don't understand. Are you saying you can't write a function to
access the FLASH properly and call that function instead of the one on
the library?
> And as for why not just to disable the global interrupts before
> calling the function, one of the two UARTs is controlled by this
> library and we do not know what effect that would have...
*** But you DO know the effect of NOT disabling GIE!!! You cannot
write flash and not disable interrupts. Period. You got a replay
explaining very clearly why. Simply put, if an interrupt occurs during
flashing, you'll never get back to the main loop.
> they have confirmed to me that they do NOT disable the
> interrupts while writing to flash
*** Then they've wroten bad code. That is a bug in the code and both
you and they know it.
> (because, stupidly, they assume that doing so will only happen
> once during initialization).
*** Why are you still working with them if you know they're stupid?
Any write to FLASH has to be preceded by a disabling of GIE, and
should be followed by restoring the GIE state. Either you get them to
correct that bug and follow specifications, or you get someone else
that is not that stupid.
Michael K.
--- In m..., "merapcb" wrote:
> It is not possible to write our own library for this.
> And as for why not just to disable the global interrupts before
> calling the function, one of the two UARTs is controlled by this
> library and we do not know what effect that would have...
> --- In m..., "Stuart_Rubin" wrote:
> >
> > The details of writing to flash, especially on the MSP430, are quite
> > application-specific. That is, how much time can you you afford to do
> > the writes, what else is going on while you write it, what are your
> > clocks doing, what is your supply voltage, do you need to erase before
> > the write, etc...
> >
> > But, the good news is that the actual writing to flash is not
> > particularly difficult. There are tons of examples on TI's web site,
> > etc. So, why not just write your own application-specific library?
> > You can get a lot more control over things, and probably end up with a
> > closer-to-optimal solution.
> >
> > Stuart
> >
> > --- In m..., "merapcb" wrote:
> > >
> > >
> > > According to TI guidelines, it is important to disable interrupts
> > > while writing to flash. I am working with a third party library that
> > > provides a read/write API to the flash, and they have confirmed
to me
> > > that they do NOT disable the interrupts while writing to flash
> > > (because, stupidly, they assume that doing so will only happen once
> > > during initialization). My question is, how critical is it to follow
> > > this guideline? We are facing some code corruption issues (that have
> > > been traced to power cycling) and I suspect it is related, but I
can't
> > > prove it because I don't have the sources. Any ideas? Thanks.
> > >
>
Reply by ●February 22, 20082008-02-22
Why can't you write your own routines? they're small, simple and will
be
bug free. If you are writing application code then a small part of this
can easily be a minimal flash re-write routine.
Al
merapcb wrote:
>It is not possible to write our own library for this.
>And as for why not just to disable the global interrupts before
>calling the function, one of the two UARTs is controlled by this
>library and we do not know what effect that would have...
>--- In m..., "Stuart_Rubin" wrote:
>
>
>>The details of writing to flash, especially on the MSP430, are quite
>>application-specific. That is, how much time can you you afford to do
>>the writes, what else is going on while you write it, what are your
>>clocks doing, what is your supply voltage, do you need to erase before
>>the write, etc...
>>
>>But, the good news is that the actual writing to flash is not
>>particularly difficult. There are tons of examples on TI's web site,
>>etc. So, why not just write your own application-specific library?
>>You can get a lot more control over things, and probably end up with a
>>closer-to-optimal solution.
>>
>>Stuart
>>
>>--- In m..., "merapcb" wrote:
>>
>>
>>>According to TI guidelines, it is important to disable interrupts
>>>while writing to flash. I am working with a third party library that
>>>provides a read/write API to the flash, and they have confirmed to me
>>>that they do NOT disable the interrupts while writing to flash
>>>(because, stupidly, they assume that doing so will only happen once
>>>during initialization). My question is, how critical is it to follow
>>>this guideline? We are facing some code corruption issues (that have
>>>been traced to power cycling) and I suspect it is related, but I can't
>>>prove it because I don't have the sources. Any ideas? Thanks.
>>>
>>>
>>>
bug free. If you are writing application code then a small part of this
can easily be a minimal flash re-write routine.
Al
merapcb wrote:
>It is not possible to write our own library for this.
>And as for why not just to disable the global interrupts before
>calling the function, one of the two UARTs is controlled by this
>library and we do not know what effect that would have...
>--- In m..., "Stuart_Rubin" wrote:
>
>
>>The details of writing to flash, especially on the MSP430, are quite
>>application-specific. That is, how much time can you you afford to do
>>the writes, what else is going on while you write it, what are your
>>clocks doing, what is your supply voltage, do you need to erase before
>>the write, etc...
>>
>>But, the good news is that the actual writing to flash is not
>>particularly difficult. There are tons of examples on TI's web site,
>>etc. So, why not just write your own application-specific library?
>>You can get a lot more control over things, and probably end up with a
>>closer-to-optimal solution.
>>
>>Stuart
>>
>>--- In m..., "merapcb" wrote:
>>
>>
>>>According to TI guidelines, it is important to disable interrupts
>>>while writing to flash. I am working with a third party library that
>>>provides a read/write API to the flash, and they have confirmed to me
>>>that they do NOT disable the interrupts while writing to flash
>>>(because, stupidly, they assume that doing so will only happen once
>>>during initialization). My question is, how critical is it to follow
>>>this guideline? We are facing some code corruption issues (that have
>>>been traced to power cycling) and I suspect it is related, but I can't
>>>prove it because I don't have the sources. Any ideas? Thanks.
>>>
>>>
>>>
Reply by ●February 23, 20082008-02-23
Unless the MSP430 in question has multiple banks of Flash, it is very important
to disable INTs
while writing...
The CPU executes a JMP $ loop while the Flash is "off line" (while it's writing), but when an
interrupt is vectored the CPU will try to fetch that vector from flash, and the Flash is not
there... So the CPU jumps to lala land ....
You could disable INTs when you call the API of the 3rd party lib, but that's most likely
inefficient, since you can't guarantee how much time the CPU spends in the API calls.
I suggest that 3rd party fixes their code problem presto ....
Should the MSP430 have a remap facility (so the vectors are solely in RAM) then it wouldn't
matter, but that ain't so.
Best Regards,
Kris
-----Original Message-----
From: m... [mailto:m...] On Behalf Of merapcb
Sent: Saturday, 23 February 2008 12:15 AM
To: m...
Subject: [msp430] Disabling interrupts while writing to flash?
According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
while writing...
The CPU executes a JMP $ loop while the Flash is "off line" (while it's writing), but when an
interrupt is vectored the CPU will try to fetch that vector from flash, and the Flash is not
there... So the CPU jumps to lala land ....
You could disable INTs when you call the API of the 3rd party lib, but that's most likely
inefficient, since you can't guarantee how much time the CPU spends in the API calls.
I suggest that 3rd party fixes their code problem presto ....
Should the MSP430 have a remap facility (so the vectors are solely in RAM) then it wouldn't
matter, but that ain't so.
Best Regards,
Kris
-----Original Message-----
From: m... [mailto:m...] On Behalf Of merapcb
Sent: Saturday, 23 February 2008 12:15 AM
To: m...
Subject: [msp430] Disabling interrupts while writing to flash?
According to TI guidelines, it is important to disable interrupts
while writing to flash. I am working with a third party library that
provides a read/write API to the flash, and they have confirmed to me
that they do NOT disable the interrupts while writing to flash
(because, stupidly, they assume that doing so will only happen once
during initialization). My question is, how critical is it to follow
this guideline? We are facing some code corruption issues (that have
been traced to power cycling) and I suspect it is related, but I can't
prove it because I don't have the sources. Any ideas? Thanks.
