Author Topic: Abysmal Microchip experience  (Read 24744 times)

0 Members and 1 Guest are viewing this topic.

Offline RossSTopic starter

  • Contributor
  • Posts: 25
Abysmal Microchip experience
« on: July 01, 2015, 10:13:24 am »
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.  |O

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.
« Last Edit: July 01, 2015, 10:19:12 am by RossS »
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9946
  • Country: nz
Re: Abysmal Microchip experience
« Reply #1 on: July 01, 2015, 10:21:58 am »
Quote
Really? I'm the *first* to discover that the channel 9 ADC input wasn't actually hooked up internally to the ADC input mux?

 :palm: :palm: :palm:
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3240
  • Country: gb
Re: Abysmal Microchip experience
« Reply #2 on: July 01, 2015, 11:48:08 am »
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?
 

Offline Ian.M

  • Super Contributor
  • ***
  • Posts: 12860
Re: Abysmal Microchip experience
« Reply #3 on: July 01, 2015, 12:39:39 pm »
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!  ;)
 

Offline con-f-use

  • Supporter
  • ****
  • Posts: 807
  • Country: at
Re: Abysmal Microchip experience
« Reply #4 on: July 01, 2015, 12:56:14 pm »
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.
 

Offline AndyC_772

  • Super Contributor
  • ***
  • Posts: 4228
  • Country: gb
  • Professional design engineer
    • Cawte Engineering | Reliable Electronics
Re: Abysmal Microchip experience
« Reply #5 on: July 01, 2015, 12:59:21 pm »
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.

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8275
Re: Abysmal Microchip experience
« Reply #6 on: July 01, 2015, 01:18:17 pm »
Quote
Really? I'm the *first* to discover that the channel 9 ADC input wasn't actually hooked up internally to the ADC input mux?

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

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: Abysmal Microchip experience
« Reply #7 on: July 01, 2015, 01:37:23 pm »
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... |O

Should be considered false advertising IMO... if you only have one working I2C don't go putting two in the damned datasheet...
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: Abysmal Microchip experience
« Reply #8 on: July 01, 2015, 02:06:05 pm »
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?
 

Offline Deathwish

  • Supporter
  • ****
  • Posts: 1424
  • Country: wales
Re: Abysmal Microchip experience
« Reply #9 on: July 01, 2015, 02:15:46 pm »
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.
Electrons are typically male, always looking for any hole to get into.
trying to strangle someone who talks out of their rectal cavity will fail, they can still breath.
God hates North Wales, he has put my home address on the blacklist of all couriers with instructions to divert all parcels.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Abysmal Microchip experience
« Reply #10 on: July 01, 2015, 03:22:35 pm »
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?
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Abysmal Microchip experience
« Reply #11 on: July 01, 2015, 06:46:32 pm »
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... |O

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.
 

Offline mazurov

  • Frequent Contributor
  • **
  • Posts: 524
  • Country: us
Re: Abysmal Microchip experience
« Reply #12 on: July 01, 2015, 07:23:17 pm »
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.
With sufficient thrust, pigs fly just fine - RFC1925
 

Online jaromir

  • Supporter
  • ****
  • Posts: 338
  • Country: sk
Re: Abysmal Microchip experience
« Reply #13 on: July 01, 2015, 08:31:10 pm »
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.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7379
  • Country: nl
  • Current job: ATEX product design
Re: Abysmal Microchip experience
« Reply #14 on: July 01, 2015, 09:47:55 pm »
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.
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 951
  • Country: pt
    • My AVR tutorials
Re: Abysmal Microchip experience
« Reply #15 on: July 01, 2015, 10:15:45 pm »
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.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13747
  • Country: gb
    • Mike's Electric Stuff
Re: Abysmal Microchip experience
« Reply #16 on: July 01, 2015, 10:54:34 pm »
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.

 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline ralphd

  • Frequent Contributor
  • **
  • Posts: 445
  • Country: ca
    • Nerd Ralph
Re: Abysmal Microchip experience
« Reply #17 on: July 02, 2015, 02:11:57 am »
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.
Unthinking respect for authority is the greatest enemy of truth. Einstein
 

Offline ralphd

  • Frequent Contributor
  • **
  • Posts: 445
  • Country: ca
    • Nerd Ralph
Re: Abysmal Microchip experience
« Reply #18 on: July 02, 2015, 02:22:38 am »
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...
Unthinking respect for authority is the greatest enemy of truth. Einstein
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Abysmal Microchip experience
« Reply #19 on: July 02, 2015, 08:08:58 am »
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
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Abysmal Microchip experience
« Reply #20 on: July 02, 2015, 05:06:52 pm »
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!
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Abysmal Microchip experience
« Reply #21 on: July 02, 2015, 05:32:33 pm »
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.
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: Abysmal Microchip experience
« Reply #22 on: July 02, 2015, 05:38:55 pm »
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

I love the smell of FR4 in the morning!
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Abysmal Microchip experience
« Reply #23 on: July 02, 2015, 09:22:57 pm »
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!
« Last Edit: July 02, 2015, 09:24:43 pm by jnz »
 

Offline RossSTopic starter

  • Contributor
  • Posts: 25
Re: Abysmal Microchip experience
« Reply #24 on: July 03, 2015, 12:28:50 am »
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.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #25 on: July 03, 2015, 07:33:51 am »
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.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7379
  • Country: nl
  • Current job: ATEX product design
Re: Abysmal Microchip experience
« Reply #26 on: July 03, 2015, 10:23:32 am »
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.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13747
  • Country: gb
    • Mike's Electric Stuff
Re: Abysmal Microchip experience
« Reply #27 on: July 03, 2015, 07:29:10 pm »
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). 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline jnz

  • Frequent Contributor
  • **
  • Posts: 593
Re: Abysmal Microchip experience
« Reply #28 on: July 03, 2015, 07:37:57 pm »
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!
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #29 on: July 03, 2015, 11:19:23 pm »
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.
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
Re: Abysmal Microchip experience
« Reply #30 on: July 03, 2015, 11:25:42 pm »
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?
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #31 on: July 03, 2015, 11:47:25 pm »
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.....  :-/O
 

Offline retrolefty

  • Super Contributor
  • ***
  • Posts: 1648
  • Country: us
  • measurement changes behavior
Re: Abysmal Microchip experience
« Reply #32 on: July 04, 2015, 12:02:51 am »
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?
 

Online hans

  • Super Contributor
  • ***
  • Posts: 1639
  • Country: nl
Re: Abysmal Microchip experience
« Reply #33 on: July 04, 2015, 06:57:27 am »
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.
 :palm:

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.
« Last Edit: July 04, 2015, 07:00:25 am by hans »
 

Offline timofonic

  • Frequent Contributor
  • **
  • Posts: 904
  • Country: es
  • Eternal Wannabe Geek
« Last Edit: July 04, 2015, 06:01:23 pm by Circuiteromalaguito »
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: Abysmal Microchip experience
« Reply #35 on: July 04, 2015, 11:30:14 am »
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

I love the smell of FR4 in the morning!
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Abysmal Microchip experience
« Reply #36 on: July 04, 2015, 11:55:21 am »
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:

Quote
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.
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #37 on: July 04, 2015, 12:37:13 pm »
Not sure where Chris C is reading his information

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

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #38 on: July 04, 2015, 01:39:51 pm »
I can also confirm the OP's ADC AN9 bug, but the other nine external analog inputs do work.
 

Offline SuzyC

  • Frequent Contributor
  • **
  • Posts: 792
Re: Abysmal Microchip experience
« Reply #39 on: July 04, 2015, 02:37:36 pm »
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.

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Abysmal Microchip experience
« Reply #40 on: July 04, 2015, 03:41:21 pm »
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'.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline retrolefty

  • Super Contributor
  • ***
  • Posts: 1648
  • Country: us
  • measurement changes behavior
Re: Abysmal Microchip experience
« Reply #41 on: July 04, 2015, 03:45:19 pm »
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.  ;)
 

Offline SuzyC

  • Frequent Contributor
  • **
  • Posts: 792
Re: Abysmal Microchip experience
« Reply #42 on: July 04, 2015, 05:29:57 pm »
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.
« Last Edit: July 05, 2015, 01:25:06 am by SuzyC »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Abysmal Microchip experience
« Reply #43 on: July 04, 2015, 06:14:55 pm »
So keep posting your problems here   ;D
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline RossSTopic starter

  • Contributor
  • Posts: 25
Re: Abysmal Microchip experience
« Reply #44 on: July 04, 2015, 06:39:27 pm »
Not sure where Chris C is reading his information

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

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

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: Abysmal Microchip experience
« Reply #45 on: July 04, 2015, 06:58:46 pm »
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

I love the smell of FR4 in the morning!
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Abysmal Microchip experience
« Reply #46 on: July 04, 2015, 10:08:53 pm »
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.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #47 on: July 04, 2015, 10:28:42 pm »
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.
 

Offline kalhana

  • Contributor
  • Posts: 19
Re: Abysmal Microchip experience
« Reply #48 on: July 05, 2015, 12:20:43 am »
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
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Abysmal Microchip experience
« Reply #49 on: July 05, 2015, 01:10:09 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline RossSTopic starter

  • Contributor
  • Posts: 25
Re: Abysmal Microchip experience
« Reply #50 on: July 05, 2015, 03:24:31 am »
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).

I 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):
Quote
In some PIC24F device, the SOSC can also be configured to operate in Digital mode. The selection is also done through the Secondary Oscillator Mode Configuration bits...

That makes me think the SOSC is a unit which can run in one of two modes, so then I read:

(10.5 DS30010038C):
Quote
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.

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

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.

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

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: Abysmal Microchip experience
« Reply #51 on: July 05, 2015, 07:11:24 am »
I 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):
Quote
In some PIC24F device, the SOSC can also be configured to operate in Digital mode. The selection is also done through the Secondary Oscillator Mode Configuration bits...
Yes, it is confusing. SOSC refers to the secondary oscillator, but also the MUX selection of secondary oscillator output  or external 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.   

Quote
so then I read:

(10.5 DS30010038C):
Quote
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.
Yes, 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.   

Quote
I'm just going to redesign this to free up a pin and run with a low ppm crystal.
Probably the best option, since that appears to be how Microchip intended it to work.

 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13747
  • Country: gb
    • Mike's Electric Stuff
Re: Abysmal Microchip experience
« Reply #52 on: July 05, 2015, 09:00:04 am »
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.

Evidence..?
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Abysmal Microchip experience
« Reply #53 on: July 05, 2015, 09:05:35 am »
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.

Evidence..?
Compare 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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #54 on: July 05, 2015, 09:22:34 am »
Yes, but when SCLKI is selected the oscillator is disabled and the pin is in digital mode, which is not compatible with Vbat.

But where is this stated?

From the data sheet:

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

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 Mode
All 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 the
device-specific data sheet) 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 TRIS
and 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.

 

Offline kalhana

  • Contributor
  • Posts: 19
Re: Abysmal Microchip experience
« Reply #55 on: July 05, 2015, 03:03:57 pm »
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.

Evidence..?
Compare 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.

Yeah I use Linear Tech/ADI/TI for analog stuff like 90% of the time.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3240
  • Country: gb
Re: Abysmal Microchip experience
« Reply #56 on: July 06, 2015, 10:59:58 am »
Different applications. Microchip analogue stuff tends to have poor specs, but it's robust.

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

Offline Whales

  • Super Contributor
  • ***
  • Posts: 1899
  • Country: au
    • Halestrom
Re: Abysmal Microchip experience
« Reply #57 on: July 06, 2015, 12:21:53 pm »
Really an ADC input not even connected. Was an intern in charge of that project?

I guess a good ADC has infinite input impedance... :o

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.
« Last Edit: July 06, 2015, 12:23:29 pm by Whales »
 

Offline Chris C

  • Frequent Contributor
  • **
  • Posts: 259
  • Country: us
Re: Abysmal Microchip experience
« Reply #58 on: July 06, 2015, 09:51:39 pm »
Hi.  I'm the [Chris C] that [Rasz] 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 [RossS] should really see it.  So I asked [Rasz] 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.  [RossS], no slight was meant or directed at you.  And after seeing how various people analyzed what I said, I agree with [Howardlong] 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 Mode
The 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 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.


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 does not imply 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 pins were listed, 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 - SCLKI pin.  And by pin, it means a functional pin, not a physical pin.  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 [RossS]'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.

[RossS], 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.
« Last Edit: July 06, 2015, 10:10:02 pm by Chris C »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5319
  • Country: gb
Re: Abysmal Microchip experience
« Reply #59 on: July 06, 2015, 10:16:56 pm »
Chris C

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf