Problems using RPB14 as input to Timer5 on chipKit DP32

[lasersam]

Hi:

I have been using a chipKit DP32 board under MPIDE for several months now using RPB9 for Timer5 input for an external clock.  It works great. but RPB9 conflicts with pins needed for an I2C interface to some sensors.  I have attempted to move Timer5 to RPB14 by changing

    T5CKR = 0b0100;

to
   

    T5CKR = 0b0001;

 

And no matter what I do, something inside the DP32 insists on driving that pin as an output to low.

I've removed just about all the code except for those setup instructions with no change in behavior.

RPB14 goes open or high when the RESET button is pressed, but both when the uploader is running and when code starts, reverts to low.  This has both been verified with a logic probe and originally because it was pulling down the input signal.

I have confirmed that other combinations work.  For example, selecting RPB0 (which is also LED4) appears to have the expected result (though that hasn't entirely been confirmed).   But I'd rather not sacrifice the use of LED4, and would like to understand what's going on, or report a bug here if that's what it is. :).

FWIW, I have been told that the identical code works properly under UECIDE, but UECIDE doesn't like me and attempting to get it to work under Win 7 and compile the same code without errors has so far been elusive.

Any info appreciated.

Thanks,

--- sam

 

[Larry Standage]

A couple things come to mind.

Is anything else using that pin for something? Check the RPB14R register to make sure it's set to 0000. Otherwise a peripheral might be driving it.

The other question is whether you have the CVREF module turned on. If so, that function takes higher priority than the PPS functions (which is why it is first on the list of pins).

[lasersam]

Thanks for replying so quickly.

Unless there is something else on the chipKIT board that I don't know about, nothing should be using it.  On one board that I'm using for testing, there is no additional hardware.

I have have added RPB14R = 0b0000; before and after the T5CKR=0b0001; without any change in behavior.

I have no knowledge of the CVREF function and it doesn't appear in my code anywhere, my apologies if that should be intuitively obvious.

There is no problem moving Timer5 to RBP0, but that would sacrifice the programmed use of LED4.

--- sam

 

[JayWeeks]

I've been fiddling with the DP32 for a while now, and I'm working on answering your question.

When I read your problem I was a little shocked actually. I didn't think you could change which pin TCK5 used as an input. I'm learning something new here. Would you mind providing your code so I can see what you're doing?

What I've found so far is that pin7 (RB14) is also shared by CVref. CVref is the Comparator Reference Voltage, you can read about it in section 23 of the PIC32MX1xx/2xx reference manual from the Microchip website. That will give you it's control registers, including the one to turn it off and the one to set its voltage, which may let you solve this problem yourself.

What I can't figure out is what would be activating CVref. Can you think of anything your code might be using comparators for? Again, it would be helpful to see your actual code so I can see what it is you're using this for.

Anyway, I'm going to keep reading reference manuals to see if I can't figure out what's going on! If I can't figure it out, I'll escalate this to someone who can!

[lasersam]

I can guarantee I'm more of a newbie at this than you!

Here is a link to a version of the code that has this problem: https://sites.google.com/site/janbeck/interferometer.pde

That should compile and have the problem even though it's not using RPB14 at all.

As you can see, there isn't much to it  And the only internal peripheral hardware it uses are the Timers.

I use an LED to 3.3V with a 1.5K resistor as a logic probe on (silkscreen) pin 7  Always on (low) except when RESET is pressed and for about 0.5 second after releasing it.

I have tried stuff like

   pinmode(7,input);

   RPB14R = 0b0000;

with no change.

Also tried disabling interrupts on the off chance something buried in the bowels of ISR dispatch was screwing with it.  As well as commenting out just about all code except for the setup.

Not sure how to set the control register for CVREF, the compiler doesn't like any of the names I've tried in the manual.

And as I noted, it apparently does NOT have this problem when compiled using UECIDE.  But I have not been able to confirm because UECIDE hates me even more than MPIDE! I can't anything to compile with that.

Thanks,

--- sam

 

[JayWeeks]

Wow! You're using this for an interferometer? Neat! What are you doing?

I think this problem may be simpler than we realize. Try using:

  pinMode(7, INPUT_PULLUP);

instead of

  pinMode(7, INPUT);

Let me know if that solves your problem.

Normally, inputs are pulled down, which is what I saw when I ran the code with the edits you suggested. It actually took me by surprise, because I had been working this problem assuming that your DP32 had been pulling your TCK5 pin up and that was the problem. I had to re-read your original post to realize that your problem was that your DP32 was pulling the pin down and not up.

Now, I haven't gone through this code to fully understand it yet. This was just the first thing I tried and I'm seeing pin 7 is being pulled high. Please let me know if this solves your problem or not, and then I'll dive back in and see what else I can find.

PS. For clarity, here's my edited setup() with the two lines of code I added/edited, marked with outlandishly large arrows. These are the only lines of code I changed.

void setup() {
    delay(1000);              // wait for USB enumeration; this is really only important for the DP32 board; others probably would not need it
    Serial.begin(115200);
    pinMode(PIN_LED1, OUTPUT); // enable use of LED1
    pinMode(PIN_LED2, OUTPUT); // enable use of LED2
    pinMode(7, INPUT_PULLUP);  // <-----------------This line of code
    // set up text buffer and offset calculations
    offset1 = 2*numbersize;
    offset2 = 3*numbersize;
    offset3 = 4*numbersize;
    offset4 = 5*numbersize;
    offset5 = 6*numbersize;
    offset6 = 7*numbersize;
    offset7 = 8*numbersize;
    // set up pps pin for external counters
    T3CKR = 0b0001;
    T5CKR = 0b0001; // <-----------------This line of code
    // Set up counters
    OpenTimer1( T1_ON | T1_SOURCE_INT | T1_PS_1_1, 0xFFFF);	// internal clock based counter                (1)
    OpenTimer3( T3_ON | T3_SOURCE_EXT | T3_PS_1_1, 0xFFFF);	// timer for MEAS  on RPB5 using T3CK PPS pin  (2)
    OpenTimer5( T5_ON | T5_SOURCE_EXT | T5_PS_1_1, 0xFFFF);     // timer for on RPB9 using T5CK PPS pin        (3)
    // set up interrupt for internal timer
    setIntVector(_TIMER_1_VECTOR,handlerForTimer1Ints);          // Configure interrupt for (1)
    ConfigIntTimer1( T1_INT_ON | T1_INT_PRIOR_1);                // enable interrupt for (1)
    INTEnableSystemMultiVectoredInt();	                         // turn on all interrupts
}

 

[lasersam]

To clarify, did you actually confirm the problem I saw?  That 7 is being pulled low/down/0/whatever?

And that you added/changed those lines of code and now 7 (pin 25 of the IC) is is not being pullded down?

I was getting used to your orignial idea about CVREF.  And there aer some very strange comments in the manual on the CVREF page about when and if it's actually possible to configure outputs.

I just tried it on the same version of the code and it made no difference.

Testing with a red LED anode to 3.3 V with 1.5K ohm resistor.

As for the interferometer,  check out: http://repairfaq.cis.upenn.edu/Misc/uMD1/uMD1.htm

You can test drive the a version of the Windows GUI by saving http://repairfaq.cis.upenn.edu/Misc/uMD1/uMD1.exe

IT will NOT be compatible with the version of the firmware you have but you don't have the interferometer hardware anyhow.   However, it has a "Test Mode" where it simulates the effects of the displacmeent measuring interferometer in action.  The real thing can now detect changes in position in the 1 nm range.  I can sit here two floors up using Remote Desktop and know when the laptop attached to it turns on its cooling fan due to thermal effects on length and vibration.  Or, tap on my desk and see vibrations register in the plot.

--- sam

 

 

 

[JayWeeks]

Sorry for the long delay, I was taking some time to investigate a little more closely. I think the problem may lie with your logic probe actually. Have you been using a voltmeter to measure things at all? I found some kind of weird behavior when I did.

I built a logic probe similar to the one you described, an LED with a resistor and anode to 3.3 V. When I load code to the board where I only change TCK5 from pin 3 (RPB9) to pin 7 (RPB14), I see what you saw, my LED was dark. However, when I measured the voltage with my voltmeter, it read as 0.0 V. This was very puzzling, but I finally figured out what is happening.

When I applied my LED probe to the two pins (anode to 3.3V, cathode to pin 7) the anode reads 3.3 V, and the cathode reads 2.0 V. This means that, when the pin is acting as an input, it assumes whatever voltage is applied to it, and returns to 0 when the voltage is removed. That means that an LED logic probe won't light up, so it looks like the pin is being pulled low when it really isn't. This makes sense, because you don't want your inputs to allow much current to flow, as that would change the circuit.

Now, if you need pin 7 to be pulled high for your hardware to work, you can use the code above which sets pin 7 as INPUT_PULLUP. That will make the board pull the pin up to 2.2 V. (I don't know why it only pulls up to 2.2 volts. Every other pin I've used INPUT_PULLUP on pulls up to 3.3 V.) You might also consider running a pullup resistor from 3V3 to pin 7 with a fairly high resistance. Otherwise, if your hardware is capable of pulling pin 7 high on its own for the clock signal, it should be working just fine.

If it's not then I am officially stumped and I'll escalate this to someone who knows more about these boards than I do.

[lasersam]

Hi:

I was wondering where you went.

It's not the logic probe.  The problem first showed up when I switched from RPB9 to RPB14 due to RPB9 conflicting with something to do with the I2C bus, which I need for some sensors. RPB14 was loading the output of the line receiver driving that pin and it would never go high.  So, RPB14 is pulling down hard.

But what I'd like to know is if using any of your proposed fixes whether a logic probe using an LED+1.5K with anode to 3.3 V and cathode to RPB14 is not lit?  It's always lit for me except during reset.

For now I have gotten around it by using RPB0.  This works fine and behaves exactly as expected.  The only downside is that RPB0 is also LED4 so it's no longer avilabable to stare at. RPB1 also works (but is also LED3.)  For that reason, I'm still interested in a long term solution.

Thanks for your continuing support and curiosity about something that will probably never affect you directly in a thousand years!

--- sam

 

[JayWeeks]

Well I'm glad you've got a working solution. I wish I could have helped you find a more long term solution. I think I can definitively say that my expertise has been totally tapped out, so I have no idea why your LED lights up when mine doesn't! Ha ha!

Good luck with your project!

[lasersam]

Thanks.

At least we both learned something in the process.

I'd welcome a suggestion of how to contact someone who might know.  They have obviously been ignoring our exchange.

Cheers!

--- sam