In article <jii6kd$pdq$1@speranza.aioe.org>, ulf@notvalid.atmel.com
says...
>
<<SNIP>>
> >>
> > While the peripherals are nice, Freescale is apparently late to
> > the party with Cortex M4 chips. Apparently, you can only
> > get M4 with functional FPU in a few places and in small quantities.
> > The last I heard, the K60 tower dev kits were shipping with chips
> > that did not have a working FPU.
>
> Yes, but long term it is an advantage to have a consistent family
> instead of a mix of M3s and M4s.
> If you go with the early M3s, where is the FPU?
I'm not sure what you mean by this. One of the problems that I see
with the Kinetis chips is that they are shipping some nominal M4s
without the FPU and later ones with the FPU.
Are there any Cortex M3 chips with an FPU?
Mark Borgerson
Reply by Vladimir Ivanov●February 29, 20122012-02-29
On Tue, 28 Feb 2012, Arlet Ottens wrote:
> On 02/28/2012 10:29 AM, Ulf Samuelsson wrote:
>
>>>> No, was not the "spurious interrupt" issue. I did have a handler for
>>>> that. By handling this interrupt and playing with re-writing some
>>>> interrupt related registers I could get 2 interrrupts running
>>>> simultaneously, but with a very high number of spurious interrupts.
>>>> It was very clear that the interaction between the ARM Core's
>>>> interrupt handler, and the peripherals had not been sorted out or
>>>> properly tested by NXP.
>>>
>>> There's a known restriction in the ARM7 core that disallows removing an
>>> interrupt source before it has been handled. Doing so anyway could
>>> result in spurious interrupts. When you do it with FIQs, I've seen the
>>> ARM7 jump to the IRQ handler, even when IRQs are disabled, corrupting
>>> the IRQ registers.
>>>
>>> The problem occurs when you disable an interrupt in a peripheral
>>> register while it is pending. Without modifying the ARM7 core, it is not
>>> so easy for NXP (or other vendors) to solve this issue. I also believe
>>> that ARM does not allow licensees to modify the core, leaving them
>>> without a proper way to solve this issue.
>>>
>>> The solution is to avoid deasserting interrupt sources by writing
>>> peripheral registers. To briefly disable interrupts, write to the CPSR
>>> register instead. If you have to deassert peripheral interrupts, first
>>> write to the CPSR register to disable global interrupts, then disable
>>> the peripheral interrupt, wait for pipeline delays, and then re-enable
>>> global interrupts.
>>>
>>
>> Or implement a spurious interrupt handler in the interrupt controller.
>> The AT91 AIC has been doing this for like 7-8 years..
>>
>> The Interrupt handler will perform an indirect jump to a vector read
>> from the AIC. If the CPU reads a vector, when no interrupt is present,
>> the SPurious Interrupt Vector is returned instead.
>
> The problem is that short glitches on the interrupt inputs violate the ARM7
> specification. Unless the SoC manufacturer guarantees this workaround works
> in all cases, I wouldn't recommend it.
I believe Atmel's AIC handles this and provides stable IRQ/FIQ signals to
the ARM7 core. Any other external interrupt controller should be doing
this as well.
The vectored jump through AIC register that Ulf mentioned is really a neat
solution overcoming ARM7's limitation.
> On the revision of the ARM7 core I was using, a glitch on the FIQ input would
> even cause a spurious IRQ when the CPU was already inside another IRQ handler
> (with IRQs disabled). This would mess up the IRQ LR, even if the spurious
> interrupt itself was handled correctly. Maybe other revisions react
> differently.
This is nasty, even if cause/effect is easy to grasp.
Back when I was using ARM7 this wasn't even documented. Or I missed it
somehow.
Thanks for the interesting tidbit.
Reply by Arlet Ottens●February 28, 20122012-02-28
On 02/28/2012 10:29 AM, Ulf Samuelsson wrote:
>>> No, was not the "spurious interrupt" issue. I did have a handler for
>>> that. By handling this interrupt and playing with re-writing some
>>> interrupt related registers I could get 2 interrrupts running
>>> simultaneously, but with a very high number of spurious interrupts.
>>> It was very clear that the interaction between the ARM Core's
>>> interrupt handler, and the peripherals had not been sorted out or
>>> properly tested by NXP.
>>
>> There's a known restriction in the ARM7 core that disallows removing an
>> interrupt source before it has been handled. Doing so anyway could
>> result in spurious interrupts. When you do it with FIQs, I've seen the
>> ARM7 jump to the IRQ handler, even when IRQs are disabled, corrupting
>> the IRQ registers.
>>
>> The problem occurs when you disable an interrupt in a peripheral
>> register while it is pending. Without modifying the ARM7 core, it is not
>> so easy for NXP (or other vendors) to solve this issue. I also believe
>> that ARM does not allow licensees to modify the core, leaving them
>> without a proper way to solve this issue.
>>
>> The solution is to avoid deasserting interrupt sources by writing
>> peripheral registers. To briefly disable interrupts, write to the CPSR
>> register instead. If you have to deassert peripheral interrupts, first
>> write to the CPSR register to disable global interrupts, then disable
>> the peripheral interrupt, wait for pipeline delays, and then re-enable
>> global interrupts.
>>
>
> Or implement a spurious interrupt handler in the interrupt controller.
> The AT91 AIC has been doing this for like 7-8 years..
>
> The Interrupt handler will perform an indirect jump to a vector read
> from the AIC. If the CPU reads a vector, when no interrupt is present,
> the SPurious Interrupt Vector is returned instead.
The problem is that short glitches on the interrupt inputs violate the
ARM7 specification. Unless the SoC manufacturer guarantees this
workaround works in all cases, I wouldn't recommend it.
On the revision of the ARM7 core I was using, a glitch on the FIQ input
would even cause a spurious IRQ when the CPU was already inside another
IRQ handler (with IRQs disabled). This would mess up the IRQ LR, even if
the spurious interrupt itself was handled correctly. Maybe other
revisions react differently.
Reply by Ulf Samuelsson●February 28, 20122012-02-28
On 2012-02-21 21:13, Arlet Ottens wrote:
> On 02/17/2012 06:56 PM, Anton Erasmus wrote:
>
>> No, was not the "spurious interrupt" issue. I did have a handler for
>> that. By handling this interrupt and playing with re-writing some
>> interrupt related registers I could get 2 interrrupts running
>> simultaneously, but with a very high number of spurious interrupts.
>> It was very clear that the interaction between the ARM Core's
>> interrupt handler, and the peripherals had not been sorted out or
>> properly tested by NXP.
>
> There's a known restriction in the ARM7 core that disallows removing an
> interrupt source before it has been handled. Doing so anyway could
> result in spurious interrupts. When you do it with FIQs, I've seen the
> ARM7 jump to the IRQ handler, even when IRQs are disabled, corrupting
> the IRQ registers.
>
> The problem occurs when you disable an interrupt in a peripheral
> register while it is pending. Without modifying the ARM7 core, it is not
> so easy for NXP (or other vendors) to solve this issue. I also believe
> that ARM does not allow licensees to modify the core, leaving them
> without a proper way to solve this issue.
>
> The solution is to avoid deasserting interrupt sources by writing
> peripheral registers. To briefly disable interrupts, write to the CPSR
> register instead. If you have to deassert peripheral interrupts, first
> write to the CPSR register to disable global interrupts, then disable
> the peripheral interrupt, wait for pipeline delays, and then re-enable
> global interrupts.
>
Or implement a spurious interrupt handler in the interrupt controller.
The AT91 AIC has been doing this for like 7-8 years..
The Interrupt handler will perform an indirect jump to a vector read
from the AIC. If the CPU reads a vector, when no interrupt is present,
the SPurious Interrupt Vector is returned instead.
>
BR
Ulf Samuelsson
Reply by Ulf Samuelsson●February 28, 20122012-02-28
On 2012-02-22 17:36, Mark Borgerson wrote:
> In article<2op7k79mb3ila70n6iq9pcebp6invls3at@4ax.com>,
> nobody@spam.prevent.net says...
>>
>> On Sat, 18 Feb 2012 09:16:20 +0000 (UTC), Jukka Marin
>> <jmarin@pyy.embedtronics.fi> wrote:
>>
>>> On 2012-02-17, Anton Erasmus<nobody@spam.prevent.net> wrote:
>>>> No, was not the "spurious interrupt" issue. I did have a handler for
>>>> that. By handling this interrupt and playing with re-writing some
>>>> interrupt related registers I could get 2 interrrupts running
>>>> simultaneously, but with a very high number of spurious interrupts.
>>>> It was very clear that the interaction between the ARM Core's
>>>> interrupt handler, and the peripherals had not been sorted out or
>>>> properly tested by NXP.
>>>
>>> We have been using several NXP ARM chips for years and there have been
>>> interrupt related bugs, yes (some first discovered by us), but we are
>>> using multiple interrupts successfully. (Multiple = serial port, SPI,
>>> timers, PWM's etc.) In some projects, total interrupt frequency is
>>> over 100 kHz and everything's working just fine.
>>>
>>> I'm not saying that NXP ARM chips are the best, but they _do_ work.
>>>
>>
>> They have improved their chips, and with sligtly later model units
>> (when they started getting fractional baud generators), they were
>> better, but their peripherals haven't improved much. Once one gets
>> used to the expceptional number of possibilities the peripherals from
>> Freescale have, then it simply makes no sense using NXP devices unless
>> one's volumes are such that one can amortize the MUCH larger
>> development costs of using the inferior NXP devices.
>> For instance if one has to communicate with multiple SPI devices on
>> one port, and one wish to do so from different interrupt routines, the
>> QSPI peripheral from Freescale controls the Chip Select line for each
>> SPI peripheral directly in hardware, hence one need not wait fro an
>> SPI transfer to complete so that one can deselect the CS line for one
>> peripheral before starting a transfer to another peripheral. The QSPI
>> handles a number of SPI transfers to different SPI devices totally in
>> hardware. This allows a MUCH slower Freescale device to handle the
>> same load as a MUCH faster similar device from NXP or ST.
>
> Another thing I like about the QSPI is that you can set it up
> to do transfers that are not multiples of 8 bits. This really
> helps if you are using an 18-bit ADC or one of the Analog Devices
> ADCs that requires 17 clocks for a 16-bit result.
>>
>> Another example which does not directly reflect the NXP MCU's
>> capability is the following. If one has a half duplex serial channel
>> and one need to switch to listen mode after one has transmitted a
>> message. Then if the MCU supports a status bit that indicates when the
>> last bit has been transmitted on to the wire as it were, not just that
>> the transmit FIFO is empty, then it simplifies the code tremedously
>> compared to an MCU that only has a status bit that indicates when
>> the transmit FIFO is empty.
>
> The STM32 UARTs have at Transmit Complete flag and interrupt. This
> is very useful if you are doing RS485 comms and need to disable
> the driver when the data transmission is done.
>
> NXP LPC4350 UARTs have an RS485 mode that actually controls a direction
> output pin. You can set a programmable delay to switch the pin after
> the last character is transmitted. This is even better than a flag
> or interrupt at the end of transmission (which the LPC 4350 also
> has.)
Yes, they finally got to copy some functions of the AT91 USART ;-)
>>
>> One can get around these sorts of things in software, but it adds
>> complexity, which adds development time and a much greater
>> chance for bugs.
>>
> While the peripherals are nice, Freescale is apparently late to
> the party with Cortex M4 chips. Apparently, you can only
> get M4 with functional FPU in a few places and in small quantities.
> The last I heard, the K60 tower dev kits were shipping with chips
> that did not have a working FPU.
Yes, but long term it is an advantage to have a consistent family
instead of a mix of M3s and M4s.
If you go with the early M3s, where is the FPU?
>
> Mark Borgerson
>
Reply by Mark Borgerson●February 22, 20122012-02-22
In article <2op7k79mb3ila70n6iq9pcebp6invls3at@4ax.com>,
nobody@spam.prevent.net says...
>
> On Sat, 18 Feb 2012 09:16:20 +0000 (UTC), Jukka Marin
> <jmarin@pyy.embedtronics.fi> wrote:
>
> >On 2012-02-17, Anton Erasmus <nobody@spam.prevent.net> wrote:
> >> No, was not the "spurious interrupt" issue. I did have a handler for
> >> that. By handling this interrupt and playing with re-writing some
> >> interrupt related registers I could get 2 interrrupts running
> >> simultaneously, but with a very high number of spurious interrupts.
> >> It was very clear that the interaction between the ARM Core's
> >> interrupt handler, and the peripherals had not been sorted out or
> >> properly tested by NXP.
> >
> >We have been using several NXP ARM chips for years and there have been
> >interrupt related bugs, yes (some first discovered by us), but we are
> >using multiple interrupts successfully. (Multiple = serial port, SPI,
> >timers, PWM's etc.) In some projects, total interrupt frequency is
> >over 100 kHz and everything's working just fine.
> >
> >I'm not saying that NXP ARM chips are the best, but they _do_ work.
> >
>
> They have improved their chips, and with sligtly later model units
> (when they started getting fractional baud generators), they were
> better, but their peripherals haven't improved much. Once one gets
> used to the expceptional number of possibilities the peripherals from
> Freescale have, then it simply makes no sense using NXP devices unless
> one's volumes are such that one can amortize the MUCH larger
> development costs of using the inferior NXP devices.
> For instance if one has to communicate with multiple SPI devices on
> one port, and one wish to do so from different interrupt routines, the
> QSPI peripheral from Freescale controls the Chip Select line for each
> SPI peripheral directly in hardware, hence one need not wait fro an
> SPI transfer to complete so that one can deselect the CS line for one
> peripheral before starting a transfer to another peripheral. The QSPI
> handles a number of SPI transfers to different SPI devices totally in
> hardware. This allows a MUCH slower Freescale device to handle the
> same load as a MUCH faster similar device from NXP or ST.
Another thing I like about the QSPI is that you can set it up
to do transfers that are not multiples of 8 bits. This really
helps if you are using an 18-bit ADC or one of the Analog Devices
ADCs that requires 17 clocks for a 16-bit result.
>
> Another example which does not directly reflect the NXP MCU's
> capability is the following. If one has a half duplex serial channel
> and one need to switch to listen mode after one has transmitted a
> message. Then if the MCU supports a status bit that indicates when the
> last bit has been transmitted on to the wire as it were, not just that
> the transmit FIFO is empty, then it simplifies the code tremedously
> compared to an MCU that only has a status bit that indicates when
> the transmit FIFO is empty.
The STM32 UARTs have at Transmit Complete flag and interrupt. This
is very useful if you are doing RS485 comms and need to disable
the driver when the data transmission is done.
NXP LPC4350 UARTs have an RS485 mode that actually controls a direction
output pin. You can set a programmable delay to switch the pin after
the last character is transmitted. This is even better than a flag
or interrupt at the end of transmission (which the LPC 4350 also
has.)
>
> One can get around these sorts of things in software, but it adds
> complexity, which adds development time and a much greater
> chance for bugs.
>
While the peripherals are nice, Freescale is apparently late to
the party with Cortex M4 chips. Apparently, you can only
get M4 with functional FPU in a few places and in small quantities.
The last I heard, the K60 tower dev kits were shipping with chips
that did not have a working FPU.
Mark Borgerson
Reply by ●February 21, 20122012-02-21
On Tue, 21 Feb 2012 21:13:53 +0100, Arlet Ottens <usenet+5@c-scape.nl>
wrote:
>On 02/17/2012 06:56 PM, Anton Erasmus wrote:
>
>> No, was not the "spurious interrupt" issue. I did have a handler for
>> that. By handling this interrupt and playing with re-writing some
>> interrupt related registers I could get 2 interrrupts running
>> simultaneously, but with a very high number of spurious interrupts.
>> It was very clear that the interaction between the ARM Core's
>> interrupt handler, and the peripherals had not been sorted out or
>> properly tested by NXP.
>
>There's a known restriction in the ARM7 core that disallows removing an
>interrupt source before it has been handled. Doing so anyway could
>result in spurious interrupts. When you do it with FIQs, I've seen the
>ARM7 jump to the IRQ handler, even when IRQs are disabled, corrupting
>the IRQ registers.
>
>The problem occurs when you disable an interrupt in a peripheral
>register while it is pending. Without modifying the ARM7 core, it is not
>so easy for NXP (or other vendors) to solve this issue. I also believe
>that ARM does not allow licensees to modify the core, leaving them
>without a proper way to solve this issue.
>
>The solution is to avoid deasserting interrupt sources by writing
>peripheral registers. To briefly disable interrupts, write to the CPSR
>register instead. If you have to deassert peripheral interrupts, first
>write to the CPSR register to disable global interrupts, then disable
>the peripheral interrupt, wait for pipeline delays, and then re-enable
>global interrupts.
>
That spurious interrupt problem is only in the older NXP parts now.
NXP is the only ARM7 part I have used though, but at least the
LPC23xx parts and above won't have those problems anymore.
Even when it was a problem, it was easy to take care of with a
generic IRQ trap and return routine.
AFAIK, I never experienced a real problem with LPC2103 or LPC2144
parts when I was using them but it is nice just not to have to even
worry about it any more.
boB
K7IQ
Reply by Arlet Ottens●February 21, 20122012-02-21
On 02/17/2012 06:56 PM, Anton Erasmus wrote:
> No, was not the "spurious interrupt" issue. I did have a handler for
> that. By handling this interrupt and playing with re-writing some
> interrupt related registers I could get 2 interrrupts running
> simultaneously, but with a very high number of spurious interrupts.
> It was very clear that the interaction between the ARM Core's
> interrupt handler, and the peripherals had not been sorted out or
> properly tested by NXP.
There's a known restriction in the ARM7 core that disallows removing an
interrupt source before it has been handled. Doing so anyway could
result in spurious interrupts. When you do it with FIQs, I've seen the
ARM7 jump to the IRQ handler, even when IRQs are disabled, corrupting
the IRQ registers.
The problem occurs when you disable an interrupt in a peripheral
register while it is pending. Without modifying the ARM7 core, it is not
so easy for NXP (or other vendors) to solve this issue. I also believe
that ARM does not allow licensees to modify the core, leaving them
without a proper way to solve this issue.
The solution is to avoid deasserting interrupt sources by writing
peripheral registers. To briefly disable interrupts, write to the CPSR
register instead. If you have to deassert peripheral interrupts, first
write to the CPSR register to disable global interrupts, then disable
the peripheral interrupt, wait for pipeline delays, and then re-enable
global interrupts.
Reply by Anton Erasmus●February 21, 20122012-02-21
On Sat, 18 Feb 2012 09:16:20 +0000 (UTC), Jukka Marin
<jmarin@pyy.embedtronics.fi> wrote:
>On 2012-02-17, Anton Erasmus <nobody@spam.prevent.net> wrote:
>> No, was not the "spurious interrupt" issue. I did have a handler for
>> that. By handling this interrupt and playing with re-writing some
>> interrupt related registers I could get 2 interrrupts running
>> simultaneously, but with a very high number of spurious interrupts.
>> It was very clear that the interaction between the ARM Core's
>> interrupt handler, and the peripherals had not been sorted out or
>> properly tested by NXP.
>
>We have been using several NXP ARM chips for years and there have been
>interrupt related bugs, yes (some first discovered by us), but we are
>using multiple interrupts successfully. (Multiple = serial port, SPI,
>timers, PWM's etc.) In some projects, total interrupt frequency is
>over 100 kHz and everything's working just fine.
>
>I'm not saying that NXP ARM chips are the best, but they _do_ work.
>
They have improved their chips, and with sligtly later model units
(when they started getting fractional baud generators), they were
better, but their peripherals haven't improved much. Once one gets
used to the expceptional number of possibilities the peripherals from
Freescale have, then it simply makes no sense using NXP devices unless
one's volumes are such that one can amortize the MUCH larger
development costs of using the inferior NXP devices.
For instance if one has to communicate with multiple SPI devices on
one port, and one wish to do so from different interrupt routines, the
QSPI peripheral from Freescale controls the Chip Select line for each
SPI peripheral directly in hardware, hence one need not wait fro an
SPI transfer to complete so that one can deselect the CS line for one
peripheral before starting a transfer to another peripheral. The QSPI
handles a number of SPI transfers to different SPI devices totally in
hardware. This allows a MUCH slower Freescale device to handle the
same load as a MUCH faster similar device from NXP or ST.
Another example which does not directly reflect the NXP MCU's
capability is the following. If one has a half duplex serial channel
and one need to switch to listen mode after one has transmitted a
message. Then if the MCU supports a status bit that indicates when the
last bit has been transmitted on to the wire as it were, not just that
the transmit FIFO is empty, then it simplifies the code tremedously
compared to an MCU that only has a status bit that indicates when
the transmit FIFO is empty.
One can get around these sorts of things in software, but it adds
complexity, which adds development time and a much greater
chance for bugs.
Regards
Anton Erasmus
Reply by Jukka Marin●February 18, 20122012-02-18
On 2012-02-17, Anton Erasmus <nobody@spam.prevent.net> wrote:
> No, was not the "spurious interrupt" issue. I did have a handler for
> that. By handling this interrupt and playing with re-writing some
> interrupt related registers I could get 2 interrrupts running
> simultaneously, but with a very high number of spurious interrupts.
> It was very clear that the interaction between the ARM Core's
> interrupt handler, and the peripherals had not been sorted out or
> properly tested by NXP.
We have been using several NXP ARM chips for years and there have been
interrupt related bugs, yes (some first discovered by us), but we are
using multiple interrupts successfully. (Multiple = serial port, SPI,
timers, PWM's etc.) In some projects, total interrupt frequency is
over 100 kHz and everything's working just fine.
I'm not saying that NXP ARM chips are the best, but they _do_ work.
-jm