Abysmal Microchip experience

[RossS]

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.

[Psi]

Really? I'm the *first* to discover that the channel 9 ADC input wasn't actually hooked up internally to the ADC input mux?

 

[mikerj]

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?

[Ian.M]

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! 

[con-f-use]

I have to prove this isn't just user error and re-state the problem until they're finally convinced enough to escalate internally.

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

[AndyC_772]

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 the wrong pinout in the same data sheet, which they acknowledge in the errata but still haven't bothered to update in the main data sheet itself.

[amyk]

Really? I'm the *first* to discover that the channel 9 ADC input wasn't actually hooked up internally to the ADC input mux?

 

I second that and 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.

[c4757p]

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 the wrong pinout in the same data sheet, which they acknowledge in the errata but still haven't bothered to update in the main data sheet itself.

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

[Brutte]

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?

[Deathwish]

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.

[jnz]

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?

[Bassman59]

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 the wrong pinout in the same data sheet, which they acknowledge in the errata but still haven't bothered to update in the main data sheet itself.

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

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

[mazurov]

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.

[jaromir]

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 is at least somebody to 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 who don't give a shit about 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.

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

[senso]

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.

[mikeselectricstuff]

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

 

[ralphd]

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.

[ralphd]

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

[Rasz]

Does anyone have a contact at Microchip or know how I might be able to get higher quality support?

ahahaha, try st.com
your experience with microchip is pretty much standard

[jnz]

Does anyone have a contact at Microchip or know how I might be able to get higher quality support?

ahahaha, try st.com
your experience with microchip is pretty much standard

I'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!

[Bassman59]

Both points are not that bad compared to some other silicon manufacturers who don't give a shit about 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.

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

[poorchava]

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

[jnz]

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.

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

[RossS]

Does anyone have a contact at Microchip or know how I might be able to get higher quality support?

ahahaha, try st.com
your experience with microchip is pretty much standard

I'll reiterate that I can't believe it took me so long to go from Microchip to ST/ARM.

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