Abysmal Microchip experience

[RossS]

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

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

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.

[Bruce Abbott]

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

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.   

so then I read:

(10.5 DS30010038C):

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.   

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.

[mikeselectricstuff]

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

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

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.

[Howardlong]

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.

[kalhana]

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.

[mikerj]

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.

[Whales]

Really an ADC input not even connected. Was an intern in charge of that project?

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

I've never done anything close to silicon fab before, but surely the testing that must be done to even get a product to a reasonable level of running stability must be massive.   Perhaps adding the 6th ADC input was or was affected by a last minute decision that happened only after a lot of testing that they didn't want to repeat.

[Chris C]

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.

[Howardlong]

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.