Need help finding MCUs that actually work to spec - Page 1
Forum section: electronics / general

author: uer166
author_rank: Super Contributor
timestamp: October 13, 2016, 04:08:48 am
content: So I've invested quite some time into learning the innards of a PIC24FJ64GA104 for a project, and shit just doesn't ever seem to work to spec.I've specifically chosen this chip for it's small(ish) errata and relative simplicity. The project requires the system to be more dependable than average consumer electronics.So far I've found:1) I2C slew rate control oscillates like crazy @100MHz and doesn't work regardless of pullup values (nothing in the errata?!).2) Sometimes can't actually turn off ADC by resetting the ON bit. The current consumption was wayy too high (+0.4mA) and the current waveform looked completely random, and took forever to figure this one out. (In the errata, so partly my bad, but still wtf).3) The internal pullups don't actually pull to a logic 1. The datasheet says "the pin pulls up to VDD – 0.7V (typical)". So already it's meaningless since they give no min/max. But even with that 0.7V figure, my MCU would pull the pin to 2.8-0.7=2.1V. The required minimum high logic level for ST buffers is 0.8Vdd, which is 2.24V for me, 0.14V higher than what the pullups do. So what's the point of the pullups then? (nothing in the errata).The scary thing to me is, most of these issues don't actually manifest themselves in any way (at least @ room temp), yet shit is still out of spec and can possibly be marginal/not working in some conditions.I've invested a lot of design effort (both HW and FW) into using this specific chip and don't want to drop it, but am worried that other issues will surface out of nowhere (and godspeed if they happen in the field at random). So, anyone knows what good, simple, low power MCUs in the same class exist, that actually work according to spec (or at least where all issues are well documented)?

author: Psi
author_rank: Super Contributor
timestamp: October 13, 2016, 05:29:38 am
content: Quote from: uer166 on September 05, 1974, 05:12:58 pmA PIC with small errata section simply means they are yet to be found.In all honesty i dont think a PIC is well suited to mission critical tasks

author: JPortici
author_rank: Super Contributor
timestamp: October 13, 2016, 05:58:09 am
content: it's an older part, with a small errata. either it does not have many bugs or nobody used it so they didn't care. being only one silicon revision i think the latter.price is higher than other pi24/dspics so again, the latter. (microchip mostly never discontinues, but discourages you from buying)just pick another chip, unless you were unlucky and chose the ony one that is not pin-to-pin compatible across the family. or go to a compatible dspic with the same analog layout and reroute the digital peripherals with PPS.and pick a chip that has maybe more errata entries but more than a silicon revision, means that it's used by people

author: uer166
author_rank: Super Contributor
timestamp: October 13, 2016, 07:03:11 am
content: Quote from: JPortici on October 13, 2016, 05:58:09 amMakes sense. I just looked at PIC24FJ32GA002 which is basically the same as the one I use minus the XLP, and the errata is big and scary (which is why I didn't use it initially), but with 4 silicon revisions, the vast majority of the issues only affect the first one, which I didn't notice initially when choosing chipsAs for not using pics for mission critical stuff I agree, but putting in a hercules or whatever won't increase the overall reliability by a measurable amount, as it's IMO mostly limited by the sensor(s), battery, and LCD.FWIW, it's for skydiving altimeter design, so reliability is a practical issue, but thankfully not a regulatory one.

author: wraper
author_rank: Unknown
timestamp: October 13, 2016, 07:39:31 am
content: Quote from: uer166 on October 13, 2016, 04:08:48 amWhat you wrote does not make sense. Why would you use internal pull-ups when pin is configured as output (if possible at all)?

author: uer166
author_rank: Super Contributor
timestamp: October 13, 2016, 07:52:58 am
content: I didn't say anything that would imply the pins being configured as output.They are configured as inputs, with internal pull-ups enabled, is all. Except the pull-ups don't actually pull it up high enough.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 13, 2016, 08:14:12 am
content: I don't think I've ever found a PIC issue that's not in the errata. You say that 2 out of 3 issues you raise are documented.Microchip are probably the best out there in documenting issues - just because other makers don't have an errata document doesn't mean there aren't any.A significant issue is where you select a part for a design, read the errata to check there's nothing that's an issue for that project, then later use the part for something else because it's familiar without re-reading the errata to check for issues for the new design.Considering how many parts Microchip produce, it is surprising how many issues they still have on new parts - you'd think they would have got their process down a bit bettter.However the obscure nature of some issues you see in the errata does give quite good confidence in their testing process.

author: wraper
author_rank: Unknown
timestamp: October 13, 2016, 08:29:30 am
content: Quote from: uer166 on October 13, 2016, 07:52:58 amI got wrong what you meant by st buffers.

author: uer166
author_rank: Super Contributor
timestamp: October 13, 2016, 08:30:25 am
content: Quote from: wraper on October 13, 2016, 08:24:37 amSorry I think I wasn't clear.I'm using the the pins as inputs. They are connected to switches which pull them to ground when the switch is pressed. When the switch is open, the pin is not externally pulled or driven in any direction. I am also using the internal pull-ups to save board space.Problem: the internal pullups, which in reality are current sources, don't pull the pins high enough for a logic 1 (when the switch is open that is).

author: uer166
author_rank: Super Contributor
timestamp: October 13, 2016, 08:32:29 am
content: Quote from: wraper on October 13, 2016, 08:29:30 amThe ST buffers are Schmitt Trigger input buffers inside the chip.The PIC has 2 kinds of inputs: ST and TTL, with different logic level requirements.

author: wraper
author_rank: Unknown
timestamp: October 13, 2016, 08:39:08 am
content: Quote from: uer166 on October 13, 2016, 08:30:25 amWould not suggest to use internal pull-ups for switches. There is not enough wetting current to ensure switch reliablity. Also if those are tact switches, they tend to form leaky path between the contacts after a few years, and if the current is very low, it will cause failures.

author: technix
author_rank: Super Contributor
timestamp: October 13, 2016, 09:47:08 am
content: For high reliable projects I would prefer either an old but still well supported part (e.g. AT89C2051) or an extremely popular one (e.g. ATmega328P.) "Given enough eyeballs, all bugs are shallow" after all, and both types of products have accumulated a great number of eyeballs and hence engineering hours from both the manufacturer and the engineers using them.

author: JPortici
author_rank: Super Contributor
timestamp: October 13, 2016, 09:51:59 am
content: Quote from: mikeselectricstuff on October 13, 2016, 08:14:12 ami found something regarding the SPI interrupt flag not getting set if you are in legacy mode -no fifo buffers-, but the buffer empty flag being set that wasn't mentioned (and still isn't) on the dspic33EP64GS504which us probably their latest dspic with a crapton of new erratas because it is a really different part.Protip on the errata: If there is no workaround it's a bug that will be never solved, because it requires a complete redesign of the module, though there are exceptions (like the crystal oscillator module workaround on PIC32MZ that was changed from "NONE" to "WORKING WITH SELECTED PARTS" in later revisions)I've seen that otherwise they are solved and very quickly only if they are critical, like ADC errors out of spec

author: dannyf
author_rank: Super Contributor
timestamp: October 13, 2016, 10:02:30 am
content: I actually use that part a lot.QuoteNo such experience.Quoteyou may consider the pmd bits. Yes, generally the power management part doesn't work.Quoteworks for me reliably.QuoteThey will always conditions under which any given part failed to work. The manufacturers don't warrant their parts to work under all conditions -> they only warrant that they at least work under a specific set of conditions. your responsibility, as a design engineer, is to make sure that the application is confined to that set of conditions, at a minimum.generally, the burden is on you to prove that you have done your part.

author: Ammar
author_rank: Regular Contributor
timestamp: October 13, 2016, 11:26:47 am
content: I asked a similar question to the one you are asking to a professional design engineer. He said that he reads the errata prior to reading the datasheet. And if there is no errata, then that's probably bullshit.

author: andersm
author_rank: Super Contributor
timestamp: October 13, 2016, 11:53:02 am
content: Quote from: JPortici on October 13, 2016, 09:51:59 amWhen it comes to Microchip, it seems that the problems most likely to be fixed are the ones for which there are no workarounds (which makes sense, since if an acceptable workaround exists, customers can use that). The effort required to fix an errata depends entirely on the problem, you can't make blanket statements.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 13, 2016, 12:08:13 pm
content: Where there is a reasonable workaround, there is a good arcgument for not fixing it. Years agoi I had an issue with an NXP ARM, which had a timer issue that meant something like that a reload or precaler register had to be offset by one. This workaround entirely fixed the problem and didn't affect any useability.Then they fixed it in a new chip rev, which broke code using the workaround.

author: Chris Jones
author_rank: Regular Contributor
timestamp: October 14, 2016, 01:13:49 pm
content: I get fairly upset about major problems that are in the errata for 5 years, persisting over several chip maskset revisions with no effort to fix the problems, and they still don't put the actual characteristics into the datasheet - e.g. an important spec like 100k EEPROM write cycles - actually it is 10k before it wears out, and they have no intention of ever fixing it, but for marketing reasons it looks better to leave a figure of 100k in the datasheet and hide the 10k number in the errata.An errata item that persists unchanged after an all-layer mask revision is actually just a lie in the datasheet, and should be referred to as such.

author: amyk
author_rank: Super Contributor
timestamp: October 14, 2016, 02:58:47 pm
content: Quote from: mikeselectricstuff on October 13, 2016, 08:14:12 amI think it might be the opposite --- they are producing so many slightly different parts that they don't really have the time to test them all thoroughly and are relying on users to essentially test them and report bugs.