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
32-bit MCU-family inquiry
Started by ●January 30, 2012
Reply by ●February 22, 20122012-02-22
Reply by ●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 ●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 ●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 ●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 ●March 1, 20122012-03-01
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
