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..., "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

--- 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

>
> 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

--- In l..., Wojciech Kromer
wrote:
>
> IHHO NXP should also give us flash specification so anyone can write
own
> flash programming code.

There are some good, and some not so good reasons, that the FLASH
programming interface is not exposed. I don't think that you can
expect that to change anytime soon.

> In some time-critical applications disabling interrupts for 2ms is not
> acceptable.
>

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.

--Dave

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.

Yep ! Disabling interrupts right before any IAP funtion fixed that
problem right up. Great ! I am surprised I had not tried that
earlier. I knew that disabling the USB interrupt made it work again
but I think I've had this fear of spurious interrupts brainwashed me.
(S.ints are actually handled just fine in my code so far as I know)
NOW, I need to figure out how to keep all of the USB code in the
bootloader and still share the RAM with the application that resides
above it without them crashing each other.

Any ideas or caveats on this combination without having to waste flash
re-programming all of the USB code into the uploaded app ?

boB

--- In l..., "jcooklis" wrote:
>
> --- In l..., "bobtransformer" wrote:
> >
> > --- In l..., shamsudheen op wrote:
> > >
> > > Hai all;
> > >
> > > I am doing an automotive project in LPC2368.Here I am
> using
> > 512k FLASH of LPC2368 for storing som critical (real time) data .I
> > reffered C:\Keil\ARM\Flash\LPC_IAP2_512 for flash programming.
> > > sir,Is it neccessary to disable Interrupts before going to
> > IAP programming(reading or writing to FLASH).
> > > Since target receiving the critical data using some
> > interrupts,Will IAP programming affect occurance of other
> interrupts
> > at same time.
> > >
> > > Sincerely
> > > shamsudheen OP
> > >
> >
> >
> > I am now wondering the same thing, Shamsudheen !
> > I didn't have much problem making IAP work until I
> > added USB functionality to the program. USB and RS232
> > would talk to each other just fine but soon as I tried
> > to IAP with USB interrupt enabled (no USB coming from PC though)
> > it gets stuck in very strange resets and stuff like that.
> >
> > Thank you for even suggesting this possible problem.
> > I am going to try disabling interrupts tonight when
> > I get home from my day job and will let you know if
> > disabling interrupts while IAP is doing its thing, helps.
> > boB
> >
> >
> >
> > >
> > > ---------------------------------
> > > 5, 50, 500, 5000 - Store N number of mails in your inbox. Click
> here.
> > >
> > >
> > >
> > I ran into the same problem with the LPC2364. You definitely have
> to disable interrupts when using the IAP routines. Here's how I did
> it:
> void some_function(void)
> {
> unsigned long ints;
>
> ints = VICIntEnable;
> VICIntEnClr = 0xffffffff;
>
> (call IAP functions here)
>
> VICIntEnable = ints;
> }
> I have a timer interrupt enabled in my code. Before I had the above
> interrupt code, the processor would go off the deep end when the
> function was called. Now it works without any problems.
>

--- In l..., "jcwren" wrote:
>
> I release you're using a LPC2368 part, but per the LPC2148 manual:
>
> Interrupts during IAP
> The on-chip flash memory is not accessible during erase/write
> operations. When the user
> application code starts executing the interrupt vectors from the user
> flash area are active.
> The user should either disable interrupts, or ensure that user
> interrupt vectors are active in
> RAM and that the interrupt handlers reside in RAM, before making a
> flash erase/write IAP
> call. The IAP code does not use or disable interrupts.
>
> --jc
I remember reading this quite a while ago. Sounds like a real
good idea to disable interrupts while IAP'ing !

Thanks again, JC.
BTW, IAR EWARM does and has alwayss outputted elf and dwarf
files, but I'm not sure if 5.10 is better or what.
Gonna try objdump very soon.

boB

>
> --- In l..., "bobtransformer" wrote:
> >
> > --- In l..., shamsudheen op wrote:
> > >
> > > Hai all;
> > >
> > > I am doing an automotive project in LPC2368.Here I am using
> > 512k FLASH of LPC2368 for storing som critical (real time) data .I
> > reffered C:\Keil\ARM\Flash\LPC_IAP2_512 for flash programming.
> > > sir,Is it neccessary to disable Interrupts before going to
> > IAP programming(reading or writing to FLASH).
> > > Since target receiving the critical data using some
> > interrupts,Will IAP programming affect occurance of other interrupts
> > at same time.
> > >
> > > Sincerely
> > > shamsudheen OP
> > >
> >
> >
> > I am now wondering the same thing, Shamsudheen !
> > I didn't have much problem making IAP work until I
> > added USB functionality to the program. USB and RS232
> > would talk to each other just fine but soon as I tried
> > to IAP with USB interrupt enabled (no USB coming from PC though)
> > it gets stuck in very strange resets and stuff like that.
> >
> > Thank you for even suggesting this possible problem.
> > I am going to try disabling interrupts tonight when
> > I get home from my day job and will let you know if
> > disabling interrupts while IAP is doing its thing, helps.
> > boB
> >
> >
> >
> > >
> > > ---------------------------------
> > > 5, 50, 500, 5000 - Store N number of mails in your inbox. Click
here.
> > >
> > >
> > >
>

I release you're using a LPC2368 part, but per the LPC2148 manual:

Interrupts during IAP
The on-chip flash memory is not accessible during erase/write
operations. When the user
application code starts executing the interrupt vectors from the user
flash area are active.
The user should either disable interrupts, or ensure that user
interrupt vectors are active in
RAM and that the interrupt handlers reside in RAM, before making a
flash erase/write IAP
call. The IAP code does not use or disable interrupts.

--jc

--- In l..., "bobtransformer" wrote:
>
> --- In l..., shamsudheen op wrote:
> >
> > Hai all;
> >
> > I am doing an automotive project in LPC2368.Here I am using
> 512k FLASH of LPC2368 for storing som critical (real time) data .I
> reffered C:\Keil\ARM\Flash\LPC_IAP2_512 for flash programming.
> > sir,Is it neccessary to disable Interrupts before going to
> IAP programming(reading or writing to FLASH).
> > Since target receiving the critical data using some
> interrupts,Will IAP programming affect occurance of other interrupts
> at same time.
> >
> > Sincerely
> > shamsudheen OP
> >
> I am now wondering the same thing, Shamsudheen !
> I didn't have much problem making IAP work until I
> added USB functionality to the program. USB and RS232
> would talk to each other just fine but soon as I tried
> to IAP with USB interrupt enabled (no USB coming from PC though)
> it gets stuck in very strange resets and stuff like that.
>
> Thank you for even suggesting this possible problem.
> I am going to try disabling interrupts tonight when
> I get home from my day job and will let you know if
> disabling interrupts while IAP is doing its thing, helps.
> boB
>
> >
> > ---------------------------------
> > 5, 50, 500, 5000 - Store N number of mails in your inbox. Click here.
> >
> >
>

An Engineer's Guide to the LPC2100 Series