PIC24EP512 - Read on D0 w/5.1K pull-up reads low

[benoitstjean]

Compiled: 5.026
Device: PIC24EP512GP806

Hi again,

Quick question:

I have a 5.1K pull-up tied to 3.5V to pin D0 (46). Given that my FW is meant to run on two circuit revisions, on the new revision, this pin acts as an input to detect the presence of an SD card. When the FW runs on the second revision (old revision), pin D0 is not tied to anything other than a 5.1K pull-up.

When device A boots, it detects immediately at boot time if the SD card is there or not. If it doesn't see a card, it means PIN D0 is high due to the 5.1K pull-up. If it sees an SD card, then it means that PIN D0 is grounded via the SD socket's /CP switch (card presence).

When device B boots which does not even have an SD socket but only the pull-up, for the life of me, somehow it reads PIN D0 as 'low' as if there was an SD card but there's only a 5.1K pull-up to 3.5V!

I tried disabling internal pull-up and pull-down using set_pulldown( FALSE, PIN_D0 ) and set_pullup( FALSE, PIN_D0 ) and still no change, the pin on the PIC side of the resistor is always low although the 5.1K pull-up is there and on the other side of the resistor, it's 3.5V.

So how can this pin still be showing as low if its internal pull-up/down resistors are disabled and there's a 5.1K resistor tied to 3.5V??

Thanks,

Ben

[newguy]

Have you ensured that you have pin D0 set as an input? Have you ensured that PPS isn't defaulting to some weird configuration that is overriding what you think the settings are? Try setting the PPS for that pin to be explicitly nothing (I/O only) - the device header file will have the proper constant/define.

I only had a very brief look at the data sheet but it appears as though there aren't any peripherals which default to that pin - BUT - it can be remapped. It could be that the PPS is defaulting to connect D0 to something.

[benoitstjean]

I've always thought that the fact that you read an input, it automatically adjusts the pin as an input?

In the specs DS70616G-page 25 Table 1-1, it shows 'NO' for PPS on RD0-RD15. And in my code, I had a note next to #INT_EXT0 saying '// NOTE: INT0 (PIN_D0) is a non-remappable interrupt'.

[Ttelmah]

It is RP64 and can be mapped as such.
The table is saying that the signal D0, cannot be assigned by PPS.
The _pin_ can.

It should not be mapped to anything by default though. More likely the
problem is because it says 'ST' in the same table. This means it has
Schmitt inputs, which need the signal to go up to to Vcc*0.8 to read
as high. What else is connected to the pin?.

[gaugeguy]

What is the actual voltage at the pin? What is the rise time on that pin during power up?

[benoitstjean]

Initially, on rev B PCB without the SD card socket, the pin was just blank sitting on a pad, that's it. Just this morning, I soldered an 0402 resistor to the pin (46) and tied the other end of it to 3.5V.

It takes roughly 1 second for the initialization to start-up and get to the point where it reads that pin.

When the device boots, I read the TRIS value of port D and it returns 0x0FDB (0000 1111 1101 1011) clearly showing D0 is an input.

Immediately after, I do a full read on port D and I get value 0x007A (0000 0000 0111 1010) clearly showing it reads a '0'....

Using my DMM, the voltage on the 'Vrail' side of the resistor is 3.5338V and on the PIC side of the resistor, it's 0.0690V.

I don't get it.

[PrinceNai]

Since you mentioned that you modified just one board... Most likely this was the first thing you checked. Is resistor OK?

[benoitstjean]

Yes, tried a 2.4K and a 5.1K....

[benoitstjean]

I'm actually starting to think if it's not THAT particular pin that has a busted input.... I have 5 of these 'older' PCB revs without the SD card and they all work as expected except for that one instance... will continue to investigate...

[benoitstjean]

Alrighty.... so that pin definitely has a mind of its own.... I just got two instances where it went as expected then two others where it thought an SD card was connected. And the pin was desoldered and lifted-up in the air.... which is the equivalent of having the pin soldered to a pad... so this would be on-par with the other problem encountered where a pull-up to 3.5V was tied to the pin and the pin still reporting as low. I guess I will simply ignore that message since I'm the one using the device and since there aren't really any SD cards, then it'll try to initialize it and mark it as 'failed' and ignore it from that point-on....

[PrinceNai]

I found this in the datasheet, page 218. Maybe it is related:

[PrinceNai]

My bad, forgot you said that the actual level on that pin is low.

[benoitstjean]

I have a total of 5 of these circuits running the same FW (I programmed them all one after the other) and 4 run as expected, that 5th one has the flaky D0 pin.... and this same FW runs fine on the new PCB rev with the SD card which has the only difference having the 5.1K pull-up when there's no SD card in the socket, that's it... and tying a 5.1K pull-up on the flaky D0 pin still did not pull-up the pin because on the side tied to 3.5V, well, I had 3.5V... and on the PIC side, the pin was pull-low internally by something I guess.... like a short of some sort....

[Ttelmah]

Just a silly 'lateral' thought, but post your fuses.
I notice that CCS are not enforcing BROWNOUT to be enabled. If you
are disabling this, it might be causing problems.
Erratum 9 on the chip. it doesn't say what this makes go wrong.

Also, though it shouldn't apply to your chip (not the USB version), there
is an interesting erratum, where the USB persistently drives the bus.
Since in one configuration of the USB configuration, this pin is the one
that would be driven low in this situation, possibly the fault is actually
with this pin, and not the USB....

[benoitstjean]

Fuses:

#fuses HS, PR, NOWDT, WINDIS, WPOSTS16, NOJTAG, NODEBUG, NOIESO