dsPic33F pin mapping issue - with bonus questions!

[@rt]

Hi Guys
I have a dsPic33FJ128GP802 on protoboard with LCD display to see output, and trying to map SPI pins to RP6-RP9 (RB6-RB9).
This is to get an SD card library working, but I’m pretty sure I’m stuck on SPI not working, as I don’t see activity with LEDs
temporarily connected to the pins instead of the SD card.

This “should” be pretty easy with PPS.h, and I should be able to do this:

Code: [Select]

PPSUnLock;
PPSInput(PPS_SDI1, PPS_RP6); //Sets RP6 (pin 15) to be Input, and maps to SPI IN
PPSOutput(PPS_SS1, PPS_RP9);//Sets RP9 (pin 18) to be Output, and maps to SPI CS
PPSOutput(PPS_SCK1, PPS_RP8);//Sets RP8 (pin 17) to be Output, and maps to SPI CLK
PPSOutput(PPS_SDO1, PPS_RP7);//Sets RP7 (pin 16) to be Output, and maps to SPI OUT
PPSLock;
}

but my PPS.h file has register definitions that I think apply to another device, and doesn’t even compile as-is.
It has an include line for another mpu, the file for which doesn’t exist: #include "p33EP512MU810.h”.

So I have tried to do the same thing a number of ways, this being one of them:

Code: [Select]

    // PPS needs to first unlock the pins before re-assignment
    __builtin_write_OSCCONL(0x46); // unlock sequence - step 1
    __builtin_write_OSCCONH(0x57); // unlock sequence - step 2
    _IOLOCK = 0;

    // Pins can now change - though, these don't change in the SFR debugger window... why?
    RPINR20bits.SDI1R = 6;  // configure SDI for input
    RPOR4bits.RP8R = 8;              // configure sck1 as output
    RPOR3bits.RP7R = 7;              // configure sdo1 as output
    RPOR4bits.RP9R = 9;     // configure ss1 as output

    __builtin_write_OSCCONL(0x46); // unlock sequence - step 1
    __builtin_write_OSCCONH(0x57); // unlock sequence - step 2
    _IOLOCK = 1; // re-lock the ports

Funny enough, just the OSCCON lines change the behaviour of some display test code in my program
that should have nothing to do with.
If it’s worth anything, the write protect switch and card socket switches both work through the library functions to test them.
... another reason to think SPI isn’t mapped to the SD card pins.

Another question is why the unlocking procedure is done here, and in the data sheet,
yet I have another project I remapped the UART in for the 64 version of the same chip, before I even knew about this pin unlocking procedure!
Furthermore, in a Pic24F MP3 player project, it’s also done on a pic24F, but I haven’t checked the data sheet for that to see if the procedure exists.

Any thoughts appreciated. Maybe I’m missing something obvious.
Cheers, Brek.

[ovnr]

Not sure why the PPS.h version doesn't work. But your DIY version is wrong - you seemingly need to write 0x46 and then 0x57 to OSCCONL, not OSCCONL + OSCCONH. See page 164 in the datasheet.

Writing to OSCCONH may have done stuff to your oscillator config and thus changed your results. And also not actually unlocked it.

[@rt]

Ok thanks. I’m pretty sure I’ve actually tried that, but will give it another go to be sure.

Here’s an example from the PPS.h file that disagrees with my device data sheet about the values for each peripheral:

Code: [Select]

#define OUT_FN_PPS_SDO1 0x0005 /* RPn tied to SPI1 Data Output */ should be 7,8,9.
#define OUT_FN_PPS_SCK1 0x0006 /* RPn tied to SPI1 Clock Output */
#define OUT_FN_PPS_SS1 0x0007 /* RPn tied to SPI1 Slave Select Output */


[@rt]

No luck there But I did realise I can print register values to the LCD display
It appears when I’m done with OSCCON, it’s: 00110011 01100000.
It looks like the lock bit 6 has been set. I haven’t looked what the rest are.

So as long as the input and remappable pin registers are readable I should be able to find to if the values are as expected,
and I might as well come back when I know better that is the problem.

[22swg]

Just setup the PPS from the data sheet ? This is for PC24EP

Code: [Select]

void Config_PPS() {
   
    RPOR4 = 0x0031; //  REFERENCE CLOCK OUTPUT RP42 RB10 PIC-PIN-8
    // UART 2  HC-12 TRX
    // TX PIN RP43(9) PPS CONFIG OUTPUT
    // RX PIN RPI44(10) PPS CONFIG INPUT
    RPOR4 = 0x0300; // U2TX
    RPINR19 = 0x002C; // U2RX
    RPINR0 =  0X2E00; // INT1 ON PIN 14 RB14
    // UART 1  FTDI FILE TEST
    // TX PIN RP38(PIN 42) 
    // RX PIN RP37(PIN 41)
    RPOR2 = 0x0001; // U1TX
    RPINR18 = 0x0025; // U1RX
     
}


[JPortici]

PPS for SPI clock MUST be defined both as input and output, otherwise the clock won't work.

+1 for just using the registers. if you are not confortable with using hex for readibility nobody stops you from using defines like

#define PPS_U2TX_HIGH_BYTE 0x0300

and

RPOR4 = PPS_U2TX_HIGH_BYTE

[@rt]

Hi Guys Thanks for the replies thus far!
It appears the unlock sequence mentioned earlier is only needed if you locked the lock bit already.
Since the device starts unlocked I guess is why it works fine to remap the pins without worrying about the sequence.

Code: [Select]

    RPINR20bits.SDI1R = 6;  // configure SDI for input
    RPOR3bits.RP7R = 7;       // configure sdo1 as output
    RPOR4bits.RP8R = 8;       // configure sck1 as output
    RPOR4bits.RP9R = 9;       // configure ss1 as output

In fact, by verifying with the LCD display, mapping the pins with the unlock/lock sequence has still not worked.
After unlock/lock sequence:

Code: [Select]

RPINR20 = 001111 001111
RPOR4 =   0
RPOR3 =   0

Reading back register values after setting the registers without the unlock/lock sequence:

Code: [Select]

RPINR20 = 00011111 00000110 // 6
RPOR4 =    00001001 00001000 // 9,8
RPOR3 =    00000111 00000000 // 7
...
yay!

This so far hasn’t helped my SD card init routine to return true.
@JPortici: Thanks, I’ll try mapping the clock for input as well, but if it’s required, that makes me wonder how the SD card sample works.
As far as I can tell, the micro drives the clock, even for the card’s replies.

[JPortici]

I don't know if the PPS in the 24f is different (it probably is, or it was for older parts) but in dsPICs PPS for SCK has to be defined both ways, as an input and an output.
There is another "obvious" thing. you are using four analog pins. you have to tell the MCU that they are digital by clearing the corresponding bits in AD1PCFGL. this can and will affect operation even if they are outputs

[@rt]

I think you mean set, as they would normally start clear and in analogue mode.

Code: [Select]

AD1PCFGL = 0xFFFF; //Set all ADC ports to digital I/O mode

Anyhow, I can see a clock signal on the clock line, but not anything on the data in or out lines.

I think that does mean SPI at least has to be enabled by the library because I’m not doing it.
I suppose there should be data aligned with an edge of these 8 bit packets.

The card init routine is run continuously until I get a true result which hasn’t yet happened, but that explains the regular clock pulses.

[@rt]

I have the input to the card (pin 2 of the SD card) connected to SDI (input to the dsPic),
and vice versa with the output pins. 

[22swg]

I'd be interested why you are building the circuit using the copper side of the board ?  doesn't look double sided ...

[@rt]

I started with that about a decade ago to stop the bottom side of the board scratching a desk and stuck with it.
Plus it’s easier to see what’s going on, like if your SD card input & output are swapped.