Abysmal Microchip experience - Page 1
Forum section: electronics / general

author: RossS
author_rank: Contributor
timestamp: July 01, 2015, 10:13:24 am
content: I've been designing a device centered around a PIC24F microcontroller (PIC24FJ128GA202) and seem to keep hitting undocumented bugs. My last two tickets with Microchip support caused them to update the errata, and I'm now on my third one.It's frustrating to hit undocumented bugs, and some of them really make me question their product testing methodology. (Really? I'm the *first* to discover that the channel 9 ADC input wasn't actually hooked up internally to the ADC input mux? How could this not have been caught in testing??) That aside, what frustrates me the most is how much of a fight it is to try and sort out these issues with Microchip support. Each support ticket takes about a month of back and forth. They take days to weeks on each ticket update. I have to prove this isn't just user error and re-state the problem until they're finally convinced enough to escalate internally. Even after escalation, the responses I hear back sometimes continue to show a lack of understanding for their products, and I have to keep pushing.Does anyone have a contact at Microchip or know how I might be able to get higher quality support? My latest ticket (ticket number 292648 and attached for anyone who's interested) has made me want to give up on them. They're really hurting themselves by making it this hard for a customer to report a bug.

author: Psi
author_rank: Super Contributor
timestamp: July 01, 2015, 10:21:58 am
content: Quote

author: mikerj
author_rank: Super Contributor
timestamp: July 01, 2015, 11:48:08 am
content: Microchips silicon bugs are the stuff of legend, both in quantity and in seriousness. I stumbled upon numerous issues when we used PICs in various products, just one of the reasons we stopped using them. It does appear as though they do very little in the way of testing.That said I recently had to purchase a Microchip compiler to support a legacy product, and the support seemed vastly better than I remembered it. I always got a response within a day and often within a hour or so, and they spent a long time trying to help work out which version of an obsolete compiler had been used to compile some code. Possibly the tools support people are a different department entirely?

author: Ian.M
author_rank: Super Contributor
timestamp: July 01, 2015, 12:39:39 pm
content: The main problem is they don't have a publicly viewable bug tracker so you have no idea when choosing a part that "Here be Dragons!". All support tickets that were not resolved to the satisfaction of the ticket holder should be automatically added to the bug tracker (with an option to withhold code/schematics if they are under a NDA).Meanwhile your best bet is to gripe loudly about the specific issue you are having on Microchip's forum, with all your ducks in a row (see catb.org's "How to ask questions the smart way"), in parallel with the ticket process, updating the topic with ticket responses, as if enough users vote your post up, and it makes it into the "top rated posts" or "most active topics" list, senior management tend to get upset if its unresolved, and its amazing the number and quality of staff that will suddenly take an interest in your problem!

author: con-f-use
author_rank: Unknown
timestamp: July 01, 2015, 12:56:14 pm
content: Quote from: RossS on July 01, 2015, 10:13:24 amHell yes, you have to prove it isn't a user error... the first time. The vast vast vast majority of tickets actually are user errors. But if you had two successful tickets already, they really should know you have a clue.

author: AndyC_772
author_rank: Super Contributor
timestamp: July 01, 2015, 12:59:21 pm
content: I'm not surprised to hear your experience. I found a bug in the data sheet for a PIC24 last year (clock source mux settings for a timer were wrong).Even though it's just a documentation error, it's still not fixed. Nor is thewrong pinoutin the same data sheet, which they acknowledge in the errata but still haven't bothered to update in the main data sheet itself.

author: amyk
author_rank: Super Contributor
timestamp: July 01, 2015, 01:18:17 pm
content: Quote from: Psi on July 01, 2015, 10:21:58 amI second thatand think that these new MCUs are probably not being used by many. On the other hand the comment about them having a lot of support tickets suggests that others could be trying and encountering the same bugs.

author: c4757p
author_rank: Super Contributor
timestamp: July 01, 2015, 01:37:23 pm
content: Quote from: AndyC_772 on July 01, 2015, 12:59:21 pmIt seems quite common not to bother updating the main datasheet. It's infuriating. I used an Atmel part a year or so ago that claimed to have two I2C modules in the datasheet, and only mentioned in the errata that one of them was totally nonfunctional...Should be considered false advertising IMO... if you only have one working I2C don't go putting two in the damned datasheet...

author: Brutte
author_rank: Frequent Contributor
timestamp: July 01, 2015, 02:06:05 pm
content: You are financing their business with your free time. I suppose that is why they do not treat you seriously.Microchip is an organization for profit, you know. That is their ultimate aim. Tell them that you have discovered a discrepancy in between documentation x and hardware y and you would like to offer them that data. But IMHO you should not make donations to corporations.Well in theory you can, it is your paypal account, so do what you want with it but why to gripe then?

author: Deathwish
author_rank: Unknown
timestamp: July 01, 2015, 02:15:46 pm
content: commercial companies just love consumer debugging, it saves them massive amounts on real R&D and development costs each year. Ignore the problem till X% of consumers say it is so and then maybe fix it.

author: jnz
author_rank: Frequent Contributor
timestamp: July 01, 2015, 03:22:35 pm
content: I used Microchip for about 12 years. In that time, I never found a serious set of tools I liked. They dropped compilers and IDEs in favor of terrible replacements. Support often never got back to me within a month, and when they did it was usually non-answers. I paid $5+ for the parts we were using, for 8bit micros!I CANNOT BELIEVE it took me so long to switch to ARM.Someone tried to convince me Microchip's strength is in their peripherals, but that's nonsense. They are terrible. Their CAN chip is fundamentally broken and not approved by any OE vehicle mfgs. I should have been more willing to switch to ARM, and sooner. I can not wait for a little down time to get all the remaining products in production away from Microchip.My advice is don't start with them now! Certainly not if you can help it. Honestly, I'd go to Atmel way before Microchip if I wanted a 8bit again for some reason. Apparently Microchip does have some ultra-tiny chips that no one else has but how often does that come up as a requirement?

author: Bassman59
author_rank: Super Contributor
timestamp: July 01, 2015, 06:46:32 pm
content: Quote from: c4757p on July 01, 2015, 01:37:23 pmOr with their SAM3 parts, some of them have three timer modules (each with three timers); the SAM3U has one timer module (with three timers), but the SAM3U docs say that it has three modules and nine timers!And the fucking rotary encoder interface doesn't work, and even if it did on SAM3U, you're all out of timers.

author: mazurov
author_rank: Frequent Contributor
timestamp: July 01, 2015, 07:23:17 pm
content: In my experience, MC support works much faster if you spend time explaining the issue. I'm getting it naturally since when I see unexpected behaviour from the peripheral I drop everything and immediately write the small program demonstrating it. Such piece of code, submitted along with the ticket, moves it past the frontline as soon as they see it (about a day). Whoever then answers it (in another day) usually offers a workaround.

author: jaromir
author_rank: Unknown
timestamp: July 01, 2015, 08:31:10 pm
content: Microchip errata lists are sometimes quite long and it may take a months or years until they are stable. Not selecting the newest parts for critical design helps a lot to prevent surprising silicon errata. You can find manufacturers with shorter errata lists - sometimes not because their products are better, they just don't bother to run as throughout tests or write down official documentation.And their customer support - I like the fact there isat least somebodyto talk about. They are not always helpful as I would wish, though - but helped me a few times.Both points are not that bad compared to some other silicon manufacturers whodon't give a shitabout a customer unless he is buying truckload of MCUs. I got bitten once and will never ever use any Freescale MCU in a commercial product, to name one.

author: tszaboo
author_rank: Super Contributor
timestamp: July 01, 2015, 09:47:55 pm
content: Quote from: RossS on July 01, 2015, 10:13:24 amQuite possible. There are many PIC24 and dsPIC33 and all the other chips which I guess never used by anyone. There are some well documented parts, like the 16F and the 32MX bigger, but if you step down from that road, it is like no mans land.

author: senso
author_rank: Frequent Contributor
timestamp: July 01, 2015, 10:15:45 pm
content: Oh...I wrangled with some PIC24F for more than a week, blinky, no problem, UART working, nah, not this week, opened tickets, posted in the forum supposed working code for the 128Kb flash version never worked in my 64Kb flash model, tried lots of things, crystal, no crystal, libraries, direct register banging, using the microchip blabla.blablaBITS = something, the micro as soon as I put a char in the uart register just froze, no more breakpoints, it was also wiggling a pin, the pin would always stop wiggling, nobody could find the problem, the solution was to use another micro, I had 3 samples directly from microchip, where they faulty?I don't know but I have a nice 55€ PicKit3 paper weight that as also gave me hours of head banging, I have some older version that only works when it feels like its in the mood, the stupid standalone program to use it keeps crashing and barfing java errors.Atmel is feeding me up, they are ultra expensive for reduced peripherals, ST and Cypress Psocs are just a world apart all that crap.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 01, 2015, 10:54:34 pm
content: Quote from: NANDBlog on July 01, 2015, 09:47:55 pmIt's not that the chips aren't used, but that most users only use a small proportion of the functionality.I've never had any issues with undocumented silicon bugs on PICs, but tend to stick to a fairly small subset of chips in each range. More common are errors in header files etc. which can appear like silicon bugs until you figure out what's going on.Another issue I had recently is changing the part type in a project and the tool chain picking up a local linker include file it shouldn't have. It's all very well it using a default linker script but it can get very hard to figure out what it's actually using sometimes.Something I really miss from IAR is it would automatically pull every included file into the project build tree, so you had immediate access to all the device-specific headers etc. to look up register names etc.

author: ralphd
author_rank: Frequent Contributor
timestamp: July 02, 2015, 02:11:57 am
content: I've been pleased with Atmel support. Pitchumani in particular has been very responsive when it comes to fixing reported errors in the AVR header files.I've run into some stupid datasheet errors due to cut/paste from another datasheet without making the appropriate changes, but the errors were obvious.

author: ralphd
author_rank: Frequent Contributor
timestamp: July 02, 2015, 02:22:38 am
content: Example from ATtiny13a datasheet section on interrupts:The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles.All <=8KB parts use rjmp instead of jmp, which is 2, not 3 cycles. An obvious cut/paste error that has been in the datasheet for a decade now...

author: Rasz
author_rank: Super Contributor
timestamp: July 02, 2015, 08:08:58 am
content: Quote from: RossS on July 01, 2015, 10:13:24 amahahaha, try st.comyour experience with microchip is pretty much standard

author: jnz
author_rank: Frequent Contributor
timestamp: July 02, 2015, 05:06:52 pm
content: Quote from: Rasz on July 02, 2015, 08:08:58 amI'll reiterate that I can't believe it took me so long to go from Microchip to ST/ARM.Senso's post above gave me eye twitches just reading it.Agreed, it's not even that far down the road until you hit no man's land. Basically, the moment you walk into a peripheral for a "real" project, the amount of support and code examples drop off, the ones that might apply to you even more so. Contrast that where I've been able to walk into ARM and have my choice of many different library examples, middlewares, better documentation, overall just anything you want to know a google or two away. And the worst/best part is.... I'm going to be paying LESS per part for 32bit ST than I was for 8bit Microchip due to ARM's inherent competition of licensing the IP/core to multiple vendors.Not even getting into the points about how I'm doing RTOS and context switches now in a way that just would never ever have been possible with Microchip 16/18/24/33, no idea on their 32bit, and I don't want to find out!

author: Bassman59
author_rank: Super Contributor
timestamp: July 02, 2015, 05:32:33 pm
content: Quote from: jaromir on July 01, 2015, 08:31:10 pmFreescale reps came to the office one day and gave a nice presentation about their parts, and talked about their tools and debug support and all of that, and it was all wonderful until they asked about production volumes, at which point they packed up everything and scurried out the door.

author: poorchava
author_rank: Super Contributor
timestamp: July 02, 2015, 05:38:55 pm
content: That's precisely why I gave up on Microchip (aside from inefficient architecture and questionable practices when it comes to compiler licensing). With their products the errata is something you read before the datasheet in order to check if the functionality you desire from the chip even works.I think I recall a chip (I think it was a PIC24H) which was marketed as 'USB OTG enabled' and the first paragraph in the errata was 'USB doesn't work'. And those were not engineering samples, to but chips qualified for series production.Sent from my HTC One M8s using Tapatalk

author: jnz
author_rank: Frequent Contributor
timestamp: July 02, 2015, 09:22:57 pm
content: Quote from: poorchava on July 02, 2015, 05:38:55 pmYea. That's entirely believable. I ran into one where CAN in FIFO just would not work correctly, let them know, got a reply with basically "Well, don't use that mode".All the above applies to my experiences but one thing I'm so glad I'll never have to deal with again..... THE 6-wire RJ-11 CONNECTOR on their debuggers! I can't understand how anyone thought that was a good idea!

author: RossS
author_rank: Contributor
timestamp: July 03, 2015, 12:28:50 am
content: Quote from: jnz on July 02, 2015, 05:06:52 pmThis is a really great point. I think I keep using Microchip just because that's what I learned with. I've been getting increasingly frustrated as I get more advanced, but for whatever reason I haven't seriously considered looking elsewhere. Thanks for the kick! I'm absolutely going to check out ST for my next project.

author: Howardlong
author_rank: Super Contributor
timestamp: July 03, 2015, 07:33:51 am
content: Possibly a reasonable way to approach this would be to ensure that your particular functionality requirement is covered in a device on a demo board and implemented in the MLA.Not having an ADC channel connected to the Mux though is pretty unlucky.If you want to see a real clusterfandango, PIC32MZ is the place.We are however all at risk when assuming the grass is always greener, so I'd be quite wary of your next steps, there may be a massive learning curve ahead of you. Certainly I had that moving to NXP's LPC43xx series when I dumped the PIC32MZ a year or so ago.I have two open tickets with Microchip at present. They are both for requests for example code referenced in application notes and demo boards that are not available online. I have had a response after about ten days to one of them, but nothing for two weeks. The other has been open for twelve days and no response.

author: tszaboo
author_rank: Super Contributor
timestamp: July 03, 2015, 10:23:32 am
content: Quote from: mikeselectricstuff on July 01, 2015, 10:54:34 pmI had problems with PIC32MX (not MZ). Like UART libraries only existed for uart 1-4 if you tried using 5/6 thent you are on your own. It was a copy paste and some register modification to make it work.Other time, I worked with a dsPIC33. I've choose one which had a better ADC than others, well because the application needed one. No library. And in the end, the same part, I found out that one of the port pins did absolutely nothing. After days of frustration I've connected 6V to it on one of the boards, and there was absolutely no current going into it because the pin wasn't even connected to the die.I'm not saying they are the worst, I've seen Infineon MCUs. It is just a little bit too much that every project I did with a PIC, I ended up having Errata/Library/Silicon bugs.The PIC32MX is a nice chip, and the ecosystem was nice some 5 years ago. But if they are not changing the picture that they are presenting to everyone, they are going to loose markets left and right.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 03, 2015, 07:29:10 pm
content: It's just a pity that other manufacturers haven't copied some of the things Microchip have got so right, like good availability, very low-cost factory device programming, multiple package options, same programmers & debuggers across a wide range of parts, similar peripherals between parts, ultra-flexible pin mapping (PIC24 in particular).The pin-mapping is probably the only reason to use PIC24 these days (as opposed to PIC32MX).

author: jnz
author_rank: Frequent Contributor
timestamp: July 03, 2015, 07:37:57 pm
content: Quote from: Howardlong on July 03, 2015, 07:33:51 amGood point.It sounds like most of us that have left Microchip are on the same page. It's a lot of work to switch, no doubt. There is an aspect of grass is greener if you think that you'll "get" X more than you "get" Y. None of us are born with this knowledge, and it all takes learning. But man, I seriously hate that I know the PIC 18F so well considering just how poor performing and expensive it is compared to the ARM chips. It's a lot of wasted info in my brain now.The time I wasted with CAN on the 33F... Oh I'll never be getting that back! My company went an entirely different direction on a couple projects because we couldn't get reliable chips for "Plan A".They have done basically nothing to stay competitive against ARM, while also destroying their tools, and getting sloppy-er than they already were with silicon. .... F That and their RJ-11 connectors!

author: Howardlong
author_rank: Super Contributor
timestamp: July 03, 2015, 11:19:23 pm
content: Regarding the modular connectors for programming and debug thingy, about ten or fifteen years ago it seemed reasonable.For some years though I've only used 0.1 or 0.05" pitch SIL on boards, with adapters as necessary. That way it's not a particularly big deal really.

author: timofonic
author_rank: Frequent Contributor
timestamp: July 03, 2015, 11:25:42 pm
content: Any volunteer to do a ?C comparison? It can make others to avoid mistakes.Best 8bit ?C? Best 16bit ?C? Best 32bit ?C? Peripherals? Power consumption? Packages? Reliability? Advantages and disadvantages?

author: Howardlong
author_rank: Super Contributor
timestamp: July 03, 2015, 11:47:25 pm
content: The problem with this making comparisons like this is that you will never get a reasonably representative analysis.Either you're reasonably adept at a few architectures or a Jack of all trades and master of none.But from a processor core perspective Andersm is probably a good bet.....

author: retrolefty
author_rank: Super Contributor
timestamp: July 04, 2015, 12:02:51 am
content: Quote from: Circuiteromalaguito on July 03, 2015, 11:25:42 pmWith so many manufactures offering so many offerings how could there possibly be a best of any in your categories? And who could have worked with all of them to opine that one is 'best'?Perhaps asking for users favorite from direct experience?

author: hans
author_rank: Super Contributor
timestamp: July 04, 2015, 06:57:27 am
content: There is no 1 size that fits all. If you develop your own projects, chances are you pick 1 slightly overkill MCU and stick with it. That way you can reuse code. If you are even more restricted on time; get a platform that is supported by the community. Like Arduino, Mbed, etc.I avoid 8-bit PICs for a long time. Their core is too old. They bolt on some funky peripherals these days, but meh. Their compiler does on support C99; end of story.16-bit PICs are quite fun to use with PPS, as it makes 2-layer board designs so much nicer to do. I haven't ran into any silicon issues on them.32-bit PICs feel like they are a bit outdated compared to ST or NXP ARM offerings. The ADC is only 10-bit. No DAC's.Nevertheless setting up a driver for the built-in ethernet mac was not a big deal. Only took a few hours to write from scratch.Probably the most hilarious errata for me was of ENC424J600 100Mbit SPI/par chipset.Boasts at third bullet point: hardware security acceleration engines.Errata: 5. Module: AES: At room temperature, the AES module may compute valid results. However, across voltage, temperature, and ordinary part-to-part device variation, the AES engine will compute incorrect results or fail to finish computations.Solution: use software AES.It always seems Microchip really wants to push untested peripherals to market. The PIC32MZ is filled with bugs because so many peripherals were renewed. Like ADC, USB, SQI, SPI at 50Mbit/s, I2C (unless you want to software poll), etc.This has been seen with SPI FIFO's on PIC24Fs, and now again.Makes me wonder if it really would hurt if they put a team of firmware engineers for 2 weeks on a new part writing peripheral code to test the hardware functions.

author: timofonic
author_rank: Frequent Contributor
timestamp: July 04, 2015, 09:38:05 am
content: That's what I would like to be part on a MCU comparison article...What are the less buggy MCUs?What about documentation quality?How are they easy to program?Flexibility?Are there a strong community behind them?Power consumption?Available peripherals?https://www.eecs.berkeley.edu/~boser/courses/40/labs/docs/microcontroller%2520benchmarks.pdfhttps://en.m.wikipedia.org/wiki/List_of_common_microcontrollershttp://www.electricstuff.co.uk/picvsavr.htmlhttp://www.quora.com/Which-is-a-better-microcontroller-Arduino-or-Launchpadhttp://www.eg3.com/blog/20100101-timsp430-atmel-avr-microchip-pic.htmhttp://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/http://hackaday.com/2013/03/10/another-salvo-in-the-pic-vs-avr-holy-war/https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FWhy%20I%27m%20switching%20from%20STM32%20to%20PIC32&currentviews=6416http://www.makershed.com/pages/microcontroller-comparisonhttp://m.instructables.com/id/How-to-choose-a-MicroController/?ALLSTEPShttp://www.ladyada.net/library/picvsavr.htmlhttp://www.engineersgarage.com/tutorials/how-to-select-right-mcuhttp://www.edn.com/Home/PrintView?contentItemId=4411480http://www.eetimes.com/document.asp?doc_id=1279383http://researchcommons.waikato.ac.nz/handle/10289/5938

author: poorchava
author_rank: Super Contributor
timestamp: July 04, 2015, 11:30:14 am
content: Quote from: mikeselectricstuff on July 03, 2015, 07:29:10 pmAgreed, to the PPS feature is really awesome. I guess they've got to have some patent on this, as this is the only explanation why nobody else has this.Never had much experience with PIC32, didn't get around to trying to them before I gave up on Microchip in general.Sent from my HTC One M8s using Tapatalk

author: Rasz
author_rank: Super Contributor
timestamp: July 04, 2015, 11:55:21 am
content: Quote from: RossS on July 01, 2015, 10:13:24 aminteresting comment from HaD:Quote

author: Howardlong
author_rank: Super Contributor
timestamp: July 04, 2015, 12:37:13 pm
content: Not sure where Chris C is reading his informationQuoteI tried to find this but couldn't, maybe I'm searching on the wrong terms.But there is this from the datasheet:10.5.3 I/O PINS DURING VBAT MODESAll I/O pins switch to Input mode during VBAT mode.The only exceptions are the SOSCI and SOSCO pins,which maintain their states if the Secondary Oscillatoris being used as the RTCC clock source. It is the user’sresponsibility to restore the I/O pins to their properstates, using the TRISx and LATx bits, once VDD hasbeen restored.Also, regarding Digital (SCLKI) mode:Ensure that the SCLKI pin is made a digital input while using this configuration (see Table 11-1).To me this suggests that the pins switch to input mode, which would be the existing state anyway, and seems consistent with the SCLKI requirement for the RTCC.I can't find any reference to "digital input buffers are shut down" during vbat.Of course, as I mentioned, I may have been unlucky on my search terms from what Chris C was stating, so I am happy to be corrected.However, I will just say that on this exact chip I have been caught by output remap on RP6 not working. Son of a bitch, that was two hours out of my life I'll never get back. It is in the current errata, #19 at the end.

author: Howardlong
author_rank: Super Contributor
timestamp: July 04, 2015, 01:39:51 pm
content: I can also confirm the OP's ADC AN9 bug, but the other nine external analog inputs do work.

author: SuzyC
author_rank: Frequent Contributor
timestamp: July 04, 2015, 02:37:36 pm
content: What is really needed is a forum area or website blog strictly related to reporting quirks and problems with Microchip MCU's where users can choose any listed chips as a topic and report unexpected problems or behavior, stuff contrary to the specsheet promises, and especially report on problems not reported on Errata sheets and warn about datasheets not corrected even after errata has been published.In this way, designer might could save a lot of sweat and tears and just look and see if there is any really crippling problems with a chip before choosing it for use in their design.This chip forum area really belongs on the Microchip website, but if Microchip would fail to want publicly make people aware of really problematic chip faults, this forum topic could be a major forum topic on EEVBLOG.

author: nctnico
author_rank: Super Contributor
timestamp: July 04, 2015, 03:41:21 pm
content: Quote from: SuzyC on July 04, 2015, 02:37:36 pmThe problem I see with such a blog is that a lot of problems will fall into the category 'user error'.

author: retrolefty
author_rank: Super Contributor
timestamp: July 04, 2015, 03:45:19 pm
content: Quote from: nctnico on July 04, 2015, 03:41:21 pmThe majority most likely.

author: SuzyC
author_rank: Frequent Contributor
timestamp: July 04, 2015, 05:29:57 pm
content: Of course, the majority might be user error, but one or more replies saying" No, that actually works with my code." would clear this up. If a forum like this was created on the Microchip website, Microchip should and would be most welcome to tag any posting with "user error" in bright red to clear the reputation of a chip.A microchip forum area really belongs on the Microchip website, but if Microchip would fail to want publicly make people aware of really problematic chip faults, this forum topic could be a major forum topic on EEVBLOG.

author: nctnico
author_rank: Super Contributor
timestamp: July 04, 2015, 06:14:55 pm
content: So keep posting your problems here

author: RossS
author_rank: Contributor
timestamp: July 04, 2015, 06:39:27 pm
content: Quote from: Howardlong on July 04, 2015, 12:37:13 pmI really appreciate his response, though I couldn't find this information either. I went through the datasheet and reference manuals carefully before opening the ticket with Microchip. I could be missing something, but what I found (which you quoted) seemed consistent with the idea that the RTCC should run in VBAT clocked with the SOSC in digital mode. I just looked through the docs for an 8-bit device that has a VBAT mode (PIC18F97J94) thinking maybe this is more clear for a different product family, but again I didn't see anything.I'd say it's a bug if the docs claim the RTCC will run in VBAT mode with the secondary oscillator, but in reality it will only work when the secondary oscillator is in a specific mode. There should either be hardware support to handle this input differently and allow the use of all modes, or documentation stating that only certain modes are supported. Mentioning that all digital inputs buffers are shut down would have been ok and I could have made the connection, but again, everything I read implied that this should work. It really just seems this is something no one at Microchip thought to test.QuoteI had an identical experience.

author: poorchava
author_rank: Super Contributor
timestamp: July 04, 2015, 06:58:46 pm
content: Another thing I recall: PIC18F4553, it has 12-bit ADC which is the only difference between it and the popular 4550. And this thing has like +/- 12LSB of DNL+INL. How the fu*k is that even remotely close to 12-bits if bottom 4.5 bits are garbage even after you calibrate for gain and offset errors?Sent from my HTC One M8s using Tapatalk

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: July 04, 2015, 10:08:53 pm
content: Quote from: RossS on July 04, 2015, 06:39:27 pmWhen feeding an external clock into SCLKI the secondary oscillator isnotbeing used and is disabled (so the phrase "if Secondary Oscillator is being used as the RTCC clock source" does not apply). SCLKI is adigitalinput. The datasheet plainly states that alldigitalinputsmustbe pulled low in Vbat mode.You are trying to use a mode which was never intended to work. Perhaps the datasheet should have spelled out more clearly that the feature you want is not available, but I don't think it is a bug. I would call it an undocumented mode that doesn't work (quell surprise).If you desperately need to use an external RTCC clock while in Vbat mode you might be able to do it by enabling the secondary oscillator and feeding the external clock into SOSCI. Of course this prevents both SOSC pins from being used for anything else, so there's little advantage over just using a crystal.

author: Howardlong
author_rank: Super Contributor
timestamp: July 04, 2015, 10:28:42 pm
content: Quote from: Bruce Abbott on July 04, 2015, 10:08:53 pmWhile I understand what you're saying, can you please reference the document(s) and page number(s) or section(s) as I did?There is something stated in FRM section 57 (57.4.3 DS30622A p57-16, last rev 2011) which seems to be at odds with what is in the datasheet (10.5.3 DS30010038C p161, last rev 2015). The FRM date is a couple of years before the device DS. Of course you may be looking at one of the 30 odd other documents that I haven't referenced.Either way, it is not "absolutely clear" by Chris C's statement, far from it in fact.

author: kalhana
author_rank: Contributor
timestamp: July 05, 2015, 12:20:43 am
content: I haven't even looked at Microchip since switching to ARM in 2009.I never use Microchip's other parts (like memories etc.) for any of my designs, it just gives me a bad vibe lol

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2015, 01:10:09 am
content: Quote from: kalhana on July 05, 2015, 12:20:43 amIt doesn't give me a bad vibe. I know Microchip components are crap compared to their competitors. I only use Microchip products if a circuit needs to be cheaper than reliable.

author: RossS
author_rank: Contributor
timestamp: July 05, 2015, 03:24:31 am
content: Quote from: Bruce Abbott on July 04, 2015, 10:08:53 pmI think "secondary oscillator" (SOSC) is ambiguous. Does it refer to the crystal driving circuit which generates a clock, or does it refer to the entire section that precedes the various SOSC inputs on the device? I think you're saying it's the first, and maybe if I was more experienced that would have been obvious to me. It's just confusing when I read things like:(6.7.2.3.2 DS39700C):QuoteThat makes me think the SOSC is a unit which can run in one of two modes, so then I read:(10.5 DS30010038C):Quote... and I think, "Great! I'll put SOSC in digital mode, use it as the source for the RTCC, and I'm all set." Again, with more experience, maybe it's obvious that "SOSC in digital mode" really means "keep using the SOSC input on your peripherals, but ignore anything else that talks about SOSC because now all you're really doing is feeding an external clock source through."Quote from: Bruce Abbott on July 04, 2015, 10:08:53 pmRight, that was the workaround Microchip recently suggested to me. It makes me uncomfortable to do that, as I don't know enough to convince myself that, if this works, it will work reliably over the long term.I'm not desperate to use an external clock. FWIW, I wanted to do that because 1) I ran out of pins and 2) I wanted to use a DCXO. I'm just going to redesign this to free up a pin and run with a low ppm crystal.

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: July 05, 2015, 07:11:24 am
content: Quote from: RossS on July 05, 2015, 03:24:31 amYes, it is confusing. SOSC refers to the secondary oscillator, but also the MUX selection of secondary oscillator outputorexternal clock input. When external clocking is enabled the oscillator is disabled, and the digital clock signal takes the place of the output from the secondary oscillator.QuoteYes, but when SCLKI is selected the oscillator is disabled and the pin is in digital mode, which is not compatible with Vbat. So the MUX selects SOSC, but when SCLKI is also selected that path comes from a digital input.QuoteProbably the best option, since that appears to be how Microchip intended it to work.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 05, 2015, 09:00:04 am
content: Quote from: nctnico on July 05, 2015, 01:10:09 amEvidence..?

author: nctnico
author_rank: Super Contributor
timestamp: July 05, 2015, 09:05:35 am
content: Quote from: mikeselectricstuff on July 05, 2015, 09:00:04 amCompare specs of their analog chips to TI and Analog devices. I also had some issues with their SPI temperature sensors in a noisy environment and those temperature sensors also had a high early failure rate.

author: Howardlong
author_rank: Super Contributor
timestamp: July 05, 2015, 09:22:34 am
content: Quote from: Bruce Abbott on July 05, 2015, 07:11:24 amBut where is this stated?From the data sheet:10.5.3 I/O PINS DURING VBAT MODESAll I/O pins switch to Input mode during VBAT mode.The only exceptions are the SOSCI and SOSCO pins,which maintain their states if the Secondary Oscillatoris being used as the RTCC clock source. It is the user’sresponsibility to restore the I/O pins to their properstates, using the TRISx and LATx bits, once VDD hasbeen restored.Also, regarding Digital (SCLKI) mode:Ensure that the SCLKI pin is made a digital input while using this configuration (see Table 11-1).So, would we be violating inputs beyond Vdd? Well, SCLKI is a 5V tolerant pin, so the usual clamping diode limit does not apply, and you could put up to 4.0V on the pin for Vdd=0V.The only thing I can find is this in DS30622A (Section 57. Power-Saving Features with VBAT), but that FRM section is not referred to in the data sheet or in the product web page, they refer to other FRM sections:57.4.3 I/O Pins During VBAT ModeAll I/O pins should be maintained at VSS level; no I/O pins should be given VDD (refer to the“Absolute Maximum Ratings” in the “Electrical Characteristics” section of thedevice-specific data sheet) during VBAT mode. The only exceptions are the SOSCI and SOSCOpins, which maintain their states if the secondary oscillator is being used as the RTCC clocksource. It is the user’s responsibility to restore the I/O pins to their proper states, using the TRISand LAT bits once VDD has been restored.While I agree that the effective end result is that the OP will need to use the device in SOSC mode, what I don't agree with is that it's clear. Regrettably it's quite common on t'internet for people to state that it's clear as day, but it turns out that actually, it ain't.

author: kalhana
author_rank: Contributor
timestamp: July 05, 2015, 03:03:57 pm
content: Quote from: nctnico on July 05, 2015, 09:05:35 amYeah I use Linear Tech/ADI/TI for analog stuff like 90% of the time.

author: mikerj
author_rank: Super Contributor
timestamp: July 06, 2015, 10:59:58 am
content: Quote from: mojo-chan on July 06, 2015, 10:33:40 amAnd it's pretty inexpensive for the level of performance. I've not have any issues with their analog stuff to be honest, there's just too many stupid bugs in the PICs.

author: Whales
author_rank: Super Contributor
timestamp: July 06, 2015, 12:21:53 pm
content: Quote from: AcHmed99 on July 04, 2015, 07:23:16 pmI guess a good ADC has infinite input impedance...I've never done anything close to silicon fab before, but surely the testing that must be done to even get a product to a reasonable level of running stability must be massive. Perhaps adding the 6th ADC input was or was affected by a last minute decision that happened only after a lot of testing that they didn't want to repeat.

author: Chris C
author_rank: Frequent Contributor
timestamp: July 06, 2015, 09:51:39 pm
content: Hi. I'm the [Chris C] that  copied my Hackaday post from.Let me start out by providing a little context. This thread was used in the Hackaday thread as a specific example of how poor tech support can be. And yes, it's disappointing, not just for Microchip but for most vendors. But sometimes they get an unnecessarily bad rap, considering what they have to contend with. There's been four times I was absolutely certain I found fault in Microchip's product, proceeded to give tech support holy hell about it, and only one time I was right. My post was written generally and with playing devil's advocate in mind, and it was only once I was done that I realized  should really see it. So I asked  to pass it along, which he kindly did, since I wasn't a member here.But after realizing it could be read out of context, I went ahead and signed up. , no slight was meant or directed at you. And after seeing how various people analyzed what I said, I agree with  that what I said should be clear, may have been clear to me, but not to others.So let me demonstrate how I determined this. From the main datasheet:10.5 VBAT ModeThe power supplied on VBAT only runs two systems: the RTCC and the Deep Sleep Semaphore registers (DSGPR0 and DSGPR1). To maintain these systems during a sudden loss of VDD, it is essential to connect a power source, other than VDD or AVDD, to the VBAT pin.When the RTCC is enabled, it continues to operate with the same clock source (SOSC or LPRC) that was selected prior to entering VBAT mode. There is no provision to switch to a lower power clock source after the mode switch.Everything is shut down, except for the listed exceptions, and those that immediately follow:10.5.3 I/O PINS DURING VBAT MODESAll I/O pins switch to Input mode during VBAT mode. The only exceptions are the SOSCI and SOSCO pins, which maintain their states if the Secondary Oscillator is being used as the RTCC clock source.Here is the first place where one might misinterpret the terminology. "Input mode" in the context of Microchip's MCUs means tristated, and high-impedance. It doesnotimply that any MCU peripheral actually be attached to the pin, and capable of receiving input, including the digital input buffers. Since the digital input buffers were not in any listed exception, one must conclude they are shut down.But the SOSCI and SOSCO pinswerelisted, you say? Second possible misinterpretation. To run the RTCC from an external clock:"Ensure that the SCLKI pin is made a digital input while using this configuration (see Table 11-1)."Notice how this is worded - SCLKIpin. And by pin, it means afunctionalpin, not aphysicalpin. Multiple functional pins share a fewer number of physical pins. Even though SOSCO and SCLKI share a physical pin, saying that SOSCO remains functional, does not mean that SCLKI does!There is one further possibility that would allow 's desired mode of operation. Perhaps SCKLI doesn't use the generic digital input buffers, but instead has a separate and dedicated digital input buffer; which is a part of SOSC, and would therefore remain functional in Vbat mode. But none of quoted documentation supports this possibility, so any assumption that it works like this is unwarranted. If any question remains, one might refer to Figure 9-1, the functional diagram for the clock. I personally prefer referring to functional diagrams over text, as they describe functionality far more succinctly than any text possibly can. The functional blocks for SOSC are shown and outlined. SCLKI is not represented, nor any circuitry that could support it. That should conclude the issue beyond any doubt. SCKLI is separate from SOSC, depends on the generic digital input buffers to function, and will not work in Vbat mode., if you really want to drive the RTCC from an external clock source while in Vbat, I'm fairly certain you can. Don't use SCLKI, turn on SOSC and use it as the clock. Your external clock source will need to be low enough impedance to override the signal from the inverter shown in the functional diagram. The output from that inverter is almost certainly limited at a low current, and tolerates "short circuiting" with a different signal without issue. If you want to be absolutely sure no damage results, initially attach the external clock through a high value resistor. Lower it until it starts to work. Then lower it a little more to allow for resistor/MCU/other tolerances, I'd go with 25%.Hope this has been helpful.

author: Howardlong
author_rank: Super Contributor
timestamp: July 06, 2015, 10:16:56 pm
content: Chris CVery good post, and welcome to the forum.I think that we find we are in agreement, and I look forward to seeing you here in future.