Abysmal Microchip experience

[Howardlong]

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.

[tszaboo]

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??

Quite 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.

It'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.

I 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.

[mikeselectricstuff]

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). 

[jnz]

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.

Good 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!

[Howardlong]

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.

[timofonic]

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?

[Howardlong]

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..... 

[retrolefty]

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?

With 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?

[hans]

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.

[timofonic]

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.pdf
https://en.m.wikipedia.org/wiki/List_of_common_microcontrollers
http://www.electricstuff.co.uk/picvsavr.html
http://www.quora.com/Which-is-a-better-microcontroller-Arduino-or-Launchpad
http://www.eg3.com/blog/20100101-timsp430-atmel-avr-microchip-pic.htm


http://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=6416
http://www.makershed.com/pages/microcontroller-comparison
http://m.instructables.com/id/How-to-choose-a-MicroController/?ALLSTEPS
http://www.ladyada.net/library/picvsavr.html
http://www.engineersgarage.com/tutorials/how-to-select-right-mcu
http://www.edn.com/Home/PrintView?contentItemId=4411480
http://www.eetimes.com/document.asp?doc_id=1279383
http://researchcommons.waikato.ac.nz/handle/10289/5938

[poorchava]

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).

Agreed, 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

[Rasz]

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.

interesting comment from HaD:

Chris C. says:
 July 3, 2015 at 7:49 pm

I read the thread at the “Abysmal Microchip Experience” link, including the attached support ticket.

[RossS] is upset that he cannot shut the chip almost completely down to VBAT mode, where it operates from a backup battery to maintain the realtime clock calendar (RTCC); while clocking the RTCC from an externally generated 32.768Khz squarewave fed into the secondary oscillator (SOSC) pins, while those pins are configured for digital input to accept that signal.

These functions stay on in VBAT mode (if you want them to): the RTCC, the low-power RC (LPRC) oscillator, and the analog oscillator for a 32.768Khz crystal connected to the SOSC pins.

So in VBAT mode, you can run the RTCC from the LPRC, or from a 32.768Khz crystal connected to the SOSC analog oscillator. In fact, at Microchip’s request he tested these modes, and both worked.

And while not in VBAT mode, you can run the RTCC from an externally generated signal by enabling the digital input buffer on the SOSC pins, and using that signal (SCKLI) as a clock for the RTCC. He was able to do this too.

But the datasheet makes it *absolutely clear* in the documentation for the VBAT mode, *all* digital input buffers are shut down. This is as it should be. Otherwise the IC would consume extra power each time a transition occurred on any pin, which would suck.

No digital input buffers = no way to route an external digital signal to the RTCC. This is not a bug. Nor is it something [RossS] should require to be explicitly spelled out for him in the documentation regarding the oscillator/RTCC. Sure, it might be nice if they’d done that, but it’s properly covered elsewhere.

In fact, in the support ticket log I see that Microchip TOLD HIM THIS. Just not as clearly as I described. Microchip probably assumed that by telling him that “RTCC should not work for external clock…SCKLI is a digital
 external clock” that [RossS] would have sufficient understanding of the digital buffers to realize that what he’s attempting is impossible. [RossS], not knowing this, simply dismissed it as an irrelevant and unsatisfactory answer. And the folks on that forum thread, instead of trying to analyze the issue and help, just assumed it must be a bug and ranted on about how bad tech support is.

Maybe a better support technician would have taken additional time and explained it as I did, but the sheer volume of people who don’t understand what they’re doing makes that impossible, for Microchip or any other company. And the folks who do know what they’re doing often get lumped in with the rest. That’s just the way it is, and it’s not entirely Microchip’s fault.

[Howardlong]

Not sure where Chris C is reading his information

the datasheet makes it *absolutely clear* in the documentation for the VBAT mode, *all* digital input buffers are shut down.

I 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 MODES

All 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. It is the user’s
responsibility to restore the I/O pins to their proper
states, using the TRISx and LATx bits, once VDD has
been 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.

[Howardlong]

I can also confirm the OP's ADC AN9 bug, but the other nine external analog inputs do work.

[SuzyC]

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.

[nctnico]

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.

The problem I see with such a blog is that a lot of problems will fall into the category 'user error'.

[retrolefty]

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.

The problem I see with such a blog is that a lot of problems will fall into the category 'user error'.

 The majority most likely. 

[SuzyC]

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.

[nctnico]

So keep posting your problems here   

[RossS]

Not sure where Chris C is reading his information

the datasheet makes it *absolutely clear* in the documentation for the VBAT mode, *all* digital input buffers are shut down.

I tried to find this but couldn't, maybe I'm searching on the wrong terms.

I 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.

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.

I had an identical experience.

[poorchava]

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

[Bruce Abbott]

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.

When feeding an external clock into SCLKI the secondary oscillator is not being used and is disabled (so the phrase "if Secondary Oscillator is being used as the RTCC clock source" does not apply). SCLKI is a digital input. The datasheet plainly states that all digital inputs must be 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.

[Howardlong]

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.

When feeding an external clock into SCLKI the secondary oscillator is not being used and is disabled (so the phrase "if Secondary Oscillator is being used as the RTCC clock source" does not apply). SCLKI is a digital input. The datasheet plainly states that all digital inputs must be 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.

While 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.

[kalhana]

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

[nctnico]

I never use Microchip's other parts (like memories etc.) for any of my designs, it just gives me a bad vibe lol

It 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.