--- In l..., Wojciech Kromer
wrote:
>
> IHHO NXP should also give us flash specification so anyone can write
own
> flash programming code.
> In some time-critical applications disabling interrupts for 2ms is not
> acceptable.
I have to second that. UART/CAN hardware buffers will overflow at
high bit rates and data lost. This forces some developers to
implement flow-control when they would otherwise not have to. I am
resigned now to having to message the CAN/UART handler to shut down
the comms and send a confirmation reply before blowing a sector, then
I have to turn them on again :(
In my apps, I can do that - it's just a pain. In some apps, I'm
sure
that 2ms is more than a PITA - it's just not acceptable at all.
Is it really necessary, (and I freely admit I don't know enough about
flash physics/architecture to know), for all of the flash to be
unavailable when blowing only one sector? Moving interrupt handlers
to scarce RAM is also a pain, especially if they make RTOS calls. It
would be really nice if there was a 'flash peripheral' that would
transparently blow a sector and then raise an interrupt when done, but
I guess I'm just dreaming...
Rgds,
Martin
Disable interrupts in IAP programming
Started by ●September 20, 2007
Reply by ●September 21, 20072007-09-21
Reply by ●September 21, 20072007-09-21
--- In l..., "mjames_doveridge" wrote:
>
> >
> > Disabling interrupts is only necessary if your interrupt vectors and
> > interrupt handlers are in FLASH. Since it is not terribly difficult
> > to locate them in RAM, you can do that and leave the interrupts
enabled.
> > That's all very well unless your handlers need to signal a semaphore
> and exit via the OS interrupt entry point to make a thread ready, then
> you're stuft :(
>
> Rgds,
> Martin
>
Yeah, that would be a bit of a problem wouldn't it? I guess that I
should not have implied that the RAM handler solution could be a
universal solution, but it does work well for a lot of cases.
--Dave
>
> >
> > Disabling interrupts is only necessary if your interrupt vectors and
> > interrupt handlers are in FLASH. Since it is not terribly difficult
> > to locate them in RAM, you can do that and leave the interrupts
enabled.
> > That's all very well unless your handlers need to signal a semaphore
> and exit via the OS interrupt entry point to make a thread ready, then
> you're stuft :(
>
> Rgds,
> Martin
>
Yeah, that would be a bit of a problem wouldn't it? I guess that I
should not have implied that the RAM handler solution could be a
universal solution, but it does work well for a lot of cases.
--Dave
Reply by ●September 21, 20072007-09-21
mjames_doveridge Wrote
>--- In l..., Wojciech Kromer
>wrote:
>>
>>
>>
>> IHHO NXP should also give us flash specification so anyone can write own
>> flash programming code.
>> In some time-critical applications disabling interrupts for 2ms is not
>> acceptable.
>
>I have to second that. UART/CAN hardware buffers will overflow at
>high bit rates and data lost. This forces some developers to
>implement flow-control when they would otherwise not have to. I am
>resigned now to having to message the CAN/UART handler to shut down
>the comms and send a confirmation reply before blowing a sector, then
>I have to turn them on again :(
>
>In my apps, I can do that - it's just a pain. In some apps, I'm sure
>that 2ms is more than a PITA - it's just not acceptable at all.
>Is it really necessary, (and I freely admit I don't know enough about
>flash physics/architecture to know), for all of the flash to be
>unavailable when blowing only one sector?
Generally(1) yes. The flash programming logic locks out the whole device
(this is true of discrete flash as well), particularly internal power
supplies are raised.
Keep in mind that the flash is kept in a programming state during this
process and cannot/should not be interrupted. Discrete flash with
intelligent programming algorithms will go away for similar lengths of time
while being programmed.
IMO if you need to store anything other than perhaps calibration and serial
type data the internal flash is probably your worst choice of storage. For
low latency or frequent changes use an FRAM or a battery backed ram, for
high capacity some form of external serial flash.
You only save costs on internal flash at high product run rates (probably
at > 10K per month).
I've yet to be convinced that any of the complaints I've heard about IAP
are anything other than being penny wise and pound foolish.
Robert
(1) There are a few flash chips that have separate programmable banks.
Often advertised as read while program although it's only part of the
device you can read while the other is being programmed.
--------------------------------
mail2web LIVE Free email based on Microsoft Exchange technology -
http://link.mail2web.com/LIVE
>--- In l..., Wojciech Kromer
>wrote:
>>
>>
>>
>> IHHO NXP should also give us flash specification so anyone can write own
>> flash programming code.
>> In some time-critical applications disabling interrupts for 2ms is not
>> acceptable.
>
>I have to second that. UART/CAN hardware buffers will overflow at
>high bit rates and data lost. This forces some developers to
>implement flow-control when they would otherwise not have to. I am
>resigned now to having to message the CAN/UART handler to shut down
>the comms and send a confirmation reply before blowing a sector, then
>I have to turn them on again :(
>
>In my apps, I can do that - it's just a pain. In some apps, I'm sure
>that 2ms is more than a PITA - it's just not acceptable at all.
>Is it really necessary, (and I freely admit I don't know enough about
>flash physics/architecture to know), for all of the flash to be
>unavailable when blowing only one sector?
Generally(1) yes. The flash programming logic locks out the whole device
(this is true of discrete flash as well), particularly internal power
supplies are raised.
Keep in mind that the flash is kept in a programming state during this
process and cannot/should not be interrupted. Discrete flash with
intelligent programming algorithms will go away for similar lengths of time
while being programmed.
IMO if you need to store anything other than perhaps calibration and serial
type data the internal flash is probably your worst choice of storage. For
low latency or frequent changes use an FRAM or a battery backed ram, for
high capacity some form of external serial flash.
You only save costs on internal flash at high product run rates (probably
at > 10K per month).
I've yet to be convinced that any of the complaints I've heard about IAP
are anything other than being penny wise and pound foolish.
Robert
(1) There are a few flash chips that have separate programmable banks.
Often advertised as read while program although it's only part of the
device you can read while the other is being programmed.
--------------------------------
mail2web LIVE Free email based on Microsoft Exchange technology -
http://link.mail2web.com/LIVE
Reply by ●September 22, 20072007-09-22
techie info
Thanks!
>
> I've yet to be convinced that any of the complaints I've heard about IAP
> are anything other than being penny wise and pound foolish.
>
Well, I have two banks of app. code and I would like to be able to
blow one from the other. The running bank would be getting the code
for the other bank over the CAN or via a UART.
I guess I'll have to do this with a stop/start comms protocol to allow
for the unavailability of interrupts.
Rgds,
Martin
Thanks!
>
> I've yet to be convinced that any of the complaints I've heard about IAP
> are anything other than being penny wise and pound foolish.
>
Well, I have two banks of app. code and I would like to be able to
blow one from the other. The running bank would be getting the code
for the other bank over the CAN or via a UART.
I guess I'll have to do this with a stop/start comms protocol to allow
for the unavailability of interrupts.
Rgds,
Martin
