DP32 peripheral conflict?

Created Wed, 16 Jul 2014 15:26:22 +0000 by LukeT

LukeT

Wed, 16 Jul 2014 15:26:22 +0000

I've currently got a DP32 with which I'm trying to utilize spi (for reading/writing to an sd card). The current implementation is kind of hacky, so I'm pursuing what I believe is the most likely culprit. Basically what's happening is that if I use the default DSPI0 pins to connect to the card, everything is fine. As soon as I remap the MISO and MOSI pins, the sd card stops responding.

The pins I'm trying to use are socket pin 3 for MOSI, and socket pin 22 for MISO. As far as I know, there shouldn't be an issue with remapping to those pins.

Here's a list of things I know/have tried, in no particular order:

1. SPI communication does appear to function on the pins, confirmed by remapping the PPS and shorting MISO to MOSI and echoing serial input.
2. I sniffed the SPI bus and the MOSI line seems to be pushing the right commands.
3. The sd card responses do appear to be correct, it seems that the board just doesn't see the MISO line. Weird, because I confirmed that I can echo stuff as in point one.
4. The data bytes sent/received via SPI change when I modify the spiSend/spiRec functions to print out the data sent/received over Serial0. For example, when sending the 0x40 command to set the sd card to idle, if I print the data to Serial0 I sniff 0x40. However, if I don't print the data I sniff 0xA0. This is reproducible and always produces the same incorrect values, so it does not appear to be random corruption of the data.
5. Due to point 4, I believe this may be a result of some form of collision between the SPI and Serial buses. Or the changing values could be an issue with my sniffer and unrelated to why the remapping doesn't work.
6. The sd card responds properly when I use the default DSPI0 pins, and fails to initialize/be recognized by the board when I remap the pins.

I feel like I've tried everything, though my issue probably stems from something dumb like reinitializing a pin or something.

This post is all over the place, so please don't hesitate to ask any clarifying questions or for more specific info.

//Main program
//Uses majenko's modified DSPI from UECIDE
#include <plib.h>
#include <SPI.h>
#include <SD.h>
#include <DSPI.h>

DSPI0 SDCARD;

Sd2Card card(&SDCARD,8);

const int chipSelect_SD_default = 9;
const int chipSelect_SD = 8;

void setup() {

	Serial0.begin(9600);
	
	delay(1000);

	Serial0.println("TEST");

	pinMode(chipSelect_SD_default, OUTPUT);
	digitalWrite(chipSelect_SD_default, HIGH);

	pinMode(chipSelect_SD, OUTPUT);
	digitalWrite(chipSelect_SD, HIGH);
	
	SDCARD.begin(8);
	pinMode(8, OUTPUT);
	SDCARD.setMode(DSPI_MODE0);
	
	mapPps(5,PPS_IN_SDI1); //MISO
        mapPps(10,PPS_OUT_SDO1); //MOSI
	
	
	if(!card.init(SPI_HALF_SPEED, chipSelect_SD)) {
		Serial0.println("initialization failed. Things to check:");
		Serial0.println("* is a card is inserted?");
		Serial0.println("* Is your wiring correct?");
		Serial0.println("* did you change the chipSelect pin to match your shield or module?");
		Serial0.println(card.errorCode(),HEX);
		Serial0.println(card.errorData(),HEX);
		return;
	}
	else{
		Serial0.println("Wiring is correct and a card is present."); 
	}
	
	
	
}

void loop() {

}

majenko

Tue, 22 Jul 2014 19:19:47 +0000

Lemme just dig out a DP32 and rig this up.

Pin 8 is CS, 5 is SDI and 10 is SDO, yes?

majenko

Tue, 22 Jul 2014 19:39:18 +0000

Right, even before I finish wiring it up I think I can see the problem (or certainly A problem...).

Pin 5 (which is RB11) is shared with the USB port D-. I don't think you can use RB11 whilst using the USB port, or even having the USB port enabled / configured. Even just plugged into the computer would most likely muller the signal.

LukeT

Tue, 22 Jul 2014 22:19:50 +0000

Thanks for the response! I'm programming via ftdi hooked up to RB13(RX) and RB3(TX) and have usb disabled. So unless I incorrectly disabled the usb connection (which is totally possible) I don't think the usb module is an issue.

Whatever the problem is, it's somewhat systematic seeing that I can reproduce it consistently, and that it doesn't seem like it's a result of random interference. I'd say the two most likely culprits right now are either another peripheral being active on the pin or something in my DSPI implementation being incorrect.

Hopefully this adds at least a little bit of info to the mix. I might also jump over to the microchip forums and see if anyone there has encountered any funkiness with this particular PPS configuration.

majenko

Wed, 23 Jul 2014 01:26:05 +0000

Ok, I'm not set up for serial right now - I'll have to dig out one of my FT232 boards in the morning and have an experiment.

majenko

Wed, 23 Jul 2014 10:41:46 +0000

Ok, the good news is it's not just you. The bad news is that I am now as confused as you are.

Loopbak test: works perfectly. SD card: fails.

Now to work out why...

Ok, so it's not a conflicting peripheral - it's purely to do with the pin remapping not working with the SD library. If I modify the Board_Defs.h file to use pins 5/10 for the DSPI0 the SD card works fine. If I re-map in the sketch it won't have none of it.

majenko

Wed, 23 Jul 2014 11:05:40 +0000

Ok, so I think I have it working. I have resorted to adding something that I think has been needed for a long long time.

Instead of using mapPps you can now specify the miso and mosi pins in the .begin() function of the DSPI class:

//Main program
//Uses majenko's modified DSPI from UECIDE
//#include <plib.h>
#include <SPI.h>
#include <SD.h>
#include <DSPI.h>

DSPI0 SDCARD;

Sd2Card card(&SDCARD,8);

const int chipSelect_SD = 8;

void setup() {
   Serial.begin(9600);
   delay(1000);
   Serial.println("TEST");

   pinMode(chipSelect_SD, OUTPUT);
   digitalWrite(chipSelect_SD, HIGH);
   
   SDCARD.begin(5, 10, 8); // MISO, MOSI and Chip Select (Must be mappable)
   pinMode(8, OUTPUT);
   SDCARD.setMode(DSPI_MODE0);
   
   if(!card.init(SPI_HALF_SPEED, chipSelect_SD)) {
      Serial.println("initialization failed. Things to check:");
      Serial.println("* is a card is inserted?");
      Serial.println("* Is your wiring correct?");
      Serial.println("* did you change the chipSelect pin to match your shield or module?");
      Serial.println(card.errorCode(),HEX);
      Serial.println(card.errorData(),HEX);
      return;
   }
   else{
      Serial.println("Wiring is correct and a card is present.");
   }
}

void loop() {
}

I have also upgraded the DP32 board definition to have the option to turn the USB on and off, so with it turned off you now use Serial instead of Serial0 for the UART serial. That means the USB code isn't even compiled in.

All these changes are now available in the latest core / board in the beta version of UECIDE only, so make sure you're using the latest beta (which won't be beta much longer). I'm going to make a pull request for the DSPI changes to get them into MPIDE too.

joelSensor

Thu, 24 Jul 2014 18:02:28 +0000

Hi,

I'm working with Thanks for working out this fix! I'm glad it's not just our problem!

Some more information about our setup. We are using PIC32MX250F128B bootloaded with your latest UDB32-MX2-DIP.hex

My understanding is that this bootloader does not implement the USB control, is that correct? Are you using the same bootloader, and does that change the fix that you made? And, just to clarify, is there an updated library that we should download to test this with our setup?

Very Much Obliged!