Why doesn't anyone want NXP's LPCs?

[luiHS]

Months ago I already stocked up on several models of 32bit microcontrollers to be able to work during the next few months, given the shortage, which seems to continue in 2022, and it is not known if also in 2023.

Right now there is practically nothing in stock at the usual suppliers. I managed to buy, at the time, quite a few microcontrollers from NXP and ST, mainly RT1024, RT1064, RT1166, RT1171, RT1172, STM32H747 and STM32H757. I also bought quite a few CAN bus FD controllers and some I2S sound amplifiers.

I recently tried to buy the RT1062s that Teensy4 uses, but someone beat me to it and bought them all, I think a little over 1000 units, I also tried a couple of hundred RT1166s that were put up for sale, but still someone bought all the next day.

I was reviewing the suppliers' stocks, to see what is in 32 bit, and I see that there are many NXP LPCs. What happens with these microcontrollers, why does nobody want them? There are references in general that remain unsold, I suppose because they are BGA with a very fine pitch of 0.65mm or less, but there are quite a few LPC references with a pitch of 0.8mm.

I have never used LPCs, but if necessary due to the lack of other microcontrollers, I could use them. Now I have quite a lot of other microcontrollers that I already bought months ago, but we don't know how long the shortage of components will last, it is said that 2022 will continue the same, and it is not known if also 2023.

[nctnico]

Appearantly a lot of people are using NXP LPC controllers because everywhere I look they are all sold out. So I'd like to know where you have spotted some stock. Maybe you have seen the older ARM7TDMI parts but except for a large BGA package the stock levels are low to non existent.

[rstofer]

I started using ARMs with the LPC2106, moved to the LPC2148 and now the LPC1768.  These are relatively old devices, particularly the LPC21xx chips.

I use the ARM mbed.org site and their online toolchain to work with the LPC1768.  The fact that I can drag and drop an Ethernet stack into my project (along with a LOT of other library functions) makes it all work out.  I can also edit and compile from anywhere with an Internet connection.

https://os.mbed.com/platforms/mbed-LPC1768/
https://os.mbed.com/

Yes, the chip is slower than a Teensy 4.1 and it doesn't have near the features.  Maybe those aren't necessary for every project.

[mikeselectricstuff]

I used the LPC2130 and 2136 a while ago - they were good for their time, but I think the ST parts took away a lot of market due to lower cost. NXP also had an annoying habit of "fixing" bugs that were 100% work-aroundble so code with the workarounds didn't work on the newer parts. 

[coppice]

NXP also had an annoying habit of "fixing" bugs that were 100% work-aroundble so code with the workarounds didn't work on the newer parts.

That's nasty. We always worked on the basis that we couldn't break code in something fully released to market (i.e. fixing early samples was OK). If we had to fix a bug, it either became a part with a distinct suffix or the fix had to default to bad operation from reset, and require the software to enable good operation.

[Siwastaja]

ST also does this, changing parts not even to fix bugs (they never fix bugs) but just for any arbitrary reason, without changing product number or informing distributors about their deeds. Software is neither binary nor source compatible. So the only procedure is to try to buy certain IC revision directly from ST which probably is possible given enough time, money and negotiation skills; or order from distributors and get a random mix of parts; then produce two firmware images and flash the appropriate one according to the IC revision markings. Maybe the chip revision is readable from a register, then you can just do this run-time in code. The biggest problem is when a CM gets a new batch which is of different revision, and the product just fails, and the software team needs to be reassembled to investigate and fix.

Change of ADC clock divider value in H7 series is one such example. Old divider and new divider both work, they are just different.

ST also just clears the historical records of the previous chip revision ever existing, despite having different specifications. Not nice in production, either.

Still better than Bosch Sensortec who informs about discontinuation, suggests an alternative part for new designs, then discontinues the new part after six months, then suggests a new part again which isn't compatible and all, and then discontinues that in a few months, too, and finalizes the job by discontinuing half of their portfolio, clearing all history of the parts ever existing in the first place.

[Jeroen3]

I peeked into Farnells listing and most are LPC800, which is "just" an Cortex M0 at 30 Mhz, flashless parts or wireless specials. Maybe that explains it?

[nctnico]

NXP also had an annoying habit of "fixing" bugs that were 100% work-aroundble so code with the workarounds didn't work on the newer parts.

That's nasty. We always worked on the basis that we couldn't break code in something fully released to market (i.e. fixing early samples was OK). If we had to fix a bug, it either became a part with a distinct suffix or the fix had to default to bad operation from reset, and require the software to enable good operation.

Actually this is much less of a problem than it seems. NXP's LPC series have very short erratas to begin with and they usually fix the problem in the next silicon release. So all in all the chances you run into an 'incompatible' processor is very small (and I doubt many of the fixes break the workaround method). I have been using NXP's LPC series for about 15 years (with over 20 different devices) and never ran into the compatibility issues Mike describes.

[Siwastaja]

I would take fixing bugs over not fixing them and instead making random changes and introducing new bugs, any day.

This is partially psychological. Even if I need to do the same amount of extra work, if it's for the ultimate long-time good and the manufacturer have good reason for it, I'm fine.

[coppice]

I would take fixing bugs over not fixing them and instead making random changes and introducing new bugs, any day.

This is partially psychological. Even if I need to do the same amount of extra work, if it's for the ultimate long-time good and the manufacturer have good reason for it, I'm fine.

Try that idea on people who have had lines down for ages while they figure out what's wrong. Try that idea on people who have to do extensive formal qualification of every software release at massive costs. Fixing bugs is great. People not  clearly distinguishing incompatible versions deserve a life of serious constipation.

[Sal Ammoniac]

I used the LPC1768 for years before switching to STM32 parts. They're good parts if you don't need features (like an FPU) in the newer M4 and M7 parts.

I suspect that some of the people buying up parts these days are flippers looking to turn a quick profit. My current MCU of choice is the STM32F76x, and all of the normal distributers have zero stock, but there are some that I've never heard of selling what is normally a $18 part for $80 or $90. They're probably running bots that monitor Digikey/Mouser stock and buy up anything that becomes available to resell at a profit.

[coppice]

I used the LPC1768 for years before switching to STM32 parts. They're good parts if you don't need features (like an FPU) in the newer M4 and M7 parts.

I suspect that some of the people buying up parts these days are flippers looking to turn a quick profit. My current MCU of choice is the STM32F76x, and all of the normal distributers have zero stock, but there are some that I've never heard of selling what is normally a $18 part for $80 or $90. They're probably running bots that monitor Digikey/Mouser stock and buy up anything that becomes available to resell at a profit.

I expect there are flippers. However, anyone with a healthy balance sheet, and some years of experience, will have grabbed enough stock early on to see them through their own production runs.

[thm_w]

OP, which parts specifically and what quantity? I don't see any LPC1769 in stock, I think its popular.

LCSC has 60,000 STM32G0's in stock, does that mean no one uses STM32G0?
https://lcsc.com/product-detail/ST-Microelectronics_STMicroelectronics-STM32G030F6P6TR_C529330.html

edit: newark has 5,000 LPC1768 eval boards in stock: https://canada.newark.com/nxp/om11043-598/evaluation-board-embed-nxp-lpc1768/dp/33R0887?CMP=AFC-OP
WTF 

[Siwastaja]

People not  clearly distinguishing incompatible versions deserve a life of serious constipation.

I definitely agree, but it seems most manufacturers do this shit anyway. Some for better reasons than others. It's infuriating when compatibility is broken without fixing anything. It just introduces the question, why.

Yes, part number should be changed, but then they would need to reflect that reality into shortened part life guarantees, or break those promises instead.

It's risk taking. It's about breaking promises and trying to do that with least harm. Which are the options, really?
* Do not guarantee any part life to begin with. You have good parts but they can't be used in production because of uncertainty. It's lose-lose to everyone.
* Keep multiple production series active, manufacture both revisions. Reflects in the price - no one buys your products because they are so expensive.
* Break part life promises every time you need to do a change. Introduce new part, market it as incompatible, even if it's nearly compatible. Everyone's pissed.
* Make "small enough" changes to the part, without changing part number. Take the risk. Does not affect everyone. Hope it affects small enough % of customers. Some are very pissed, for good reason. Most are fine.

Of course, best would be just not to make the changes at all. I leaved this option out of the discussion because it's so obvious. I'm assuming here the manufacturer absolutely has to make the change for some reason, possibly unknown to us.

[Sal Ammoniac]

newark has 5,000 LPC1768 eval boards in stock

I've had to resort to buying Nucleo eval boards with the STM32F76x on them to remove the MCU for use in other projects. None of the usual distributers have bare chips in stock, except for the scalpers who are charging 4-5x the normal price for these chips.

[hans]

OP, which parts specifically and what quantity? I don't see any LPC1769 in stock, I think its popular.

LCSC has 60,000 STM32G0's in stock, does that mean no one uses STM32G0?
https://lcsc.com/product-detail/ST-Microelectronics_STMicroelectronics-STM32G030F6P6TR_C529330.html
WTF 

The L0/F0 series is quite similar and popular, but a lot older. That means those parts will potentially have a higher volume since it's in more designs, and are more likely sold out or bought up by scalpers. I imagine the G0 series still needs to gain most of it's momentum.

I also don't see many LPCs in stock at Mouser... well not the ones I would like to buy. The ones that remain are the bottom-of-the-barrel m0+ parts with 16KB FLASH etc. Useful if you need to save on the last cent in large volume.. but then you won't be buying that volume through Mouser.. probably.

I've used the LPC2129 and LPC1768 parts in the past, and they are quite capable MCUs with good documentation. I do think that peripheral wise, NXP has chosen to prioritize robust (industrial) peripherals rather than giving you a lot of them. E.g. the LPC2129 only had a 4-channel ADC. The LPC1768 also only has a 8-channel ADC. That is very different than competitors like ST: NXP parts tend to have more CAN interfaces or other automotive/industrial peripherals. ST is more likely to include lots of timers, SPIs/UARTs or SDIO interfaces.  That doesn't have to be a showstopper.. as long as you can map all the requirements and fit it on the PCB.

I personally wouldn't design in a NXP ARM7TDMI part (or any brand's for that matter...) into a new design anymore.. even if it's available right now due to the parts shortage. The compiler and programming tools are too much of a hassle to deal with. E.g. I don't know if arm-none-eabi-gcc has ARMv4 enabled by default on many distro's. I also had trouble with bricked LPC21xx parts due to the ROM bootloader and/or programming cables that were confused by the RTCK signal.

[SiliconWizard]

I personally wouldn't design in a NXP ARM7TDMI part into a new design anymore.. even if it's available right now due to the parts shortage.

Same here. One thing that was consistently unimpressive with those - at least by my criterions - apart from what you mentioned, was power consumption.

[coppice]

Of course their power consumption is high. They are 20 year old designs, in a coarse geometry process. It's not just the running power which looks bad. Some of them also leak like a sieve, so even their standby consumption looks bad by current standards.