chipKIT® Development Platform

Inspired by Arduino™

Max32, SPI and SD cards?

Created Sun, 11 Sep 2011 21:09:29 +0000 by rasmadrak

rasmadrak

Sun, 11 Sep 2011 21:09:29 +0000

Hi there,

I'm having limited (as in no) success getting the SD card reading to function. I'm using a ET-MINI reader ([url]http://mac6.ma.psu.edu/space2008/RockSat/microController/MINISD.pdf[/url]) and I've tried the example code provided with the MPIDE but cannot get it to work. I am trying to use SPI #2, I don't know if I've connected it correctly however. According to the documentation it seems I'm using the same pins as SPI #1...

Has anyone succeeded in connecting a SD card to the Chipkit (Uno or Max), and is willing to help me? It would be much appreciated!

Andy123

Sun, 11 Sep 2011 22:41:00 +0000

I am not sure what you are trying to do, but I got SD sample files working with MAX32 and Ethernet V5 shield that has SD slot after modifications I described in another thread http://www.chipkit.org/forum/viewtopic.php?p=2010#p2010

rasmadrak

Mon, 12 Sep 2011 07:04:31 +0000

I am trying to hook up the SD card module I linked in the post above to my Chipkit Max32.

I've learned that the Chipkit has 2 (or 4?) SPI ports. The first port is already being used by a display (pin 50,51,52,53) so they cannot be used. I tried to follow the pin layout in the reference manual and connected the SD card to SDI2A etc - pins 10,11,12,14, which I have connected the various pins to the pinout on the SD card reader explained in the url above.

When I try the SD Card "ReadWrite" example I never get past the "SD.begin(14)" part. It fails and exits.

Andy123

Mon, 12 Sep 2011 12:32:32 +0000

SPI port can be shared between different devices as long as they use the same baud rate and each device has own CS (SS) pin

I think libraries are set to use first SPI port SCK, MISO, MOSI (5x pins) while you can use your own CS pin My shield uses CS pin D4, in your case it may be different

rasmadrak

Mon, 12 Sep 2011 18:28:22 +0000

Hi there,

It would seem I got the pins wrong, I tried rewiring them to SPI #1 and it worked right away.

However - I cannot use these pins (or rather not) since they will be used by a display. I cannot wrap my head around the pin layout - I'm pretty sure I can rewrite the SD libraries to use different SPI pins... If only I could understand which they are. :)

Anyone got a good clue about the SPI pins on the Max32?

GeneApperson

Mon, 12 Sep 2011 18:47:45 +0000

Have you looked at the pinout tables at the end of the board reference manual? Or the pinout table spreadsheet?

These documents are in the support section at the bottom of the product page on the Digilent web site.

Gene Apperson Digilent

rasmadrak

Mon, 12 Sep 2011 19:13:43 +0000

Yes, I have. But I found them very confusing... Having the pinout for both the pic and chipkit is confusing, at least for me. :) Since it's a reference manual for the boards, the actual PIC pins are irrelevant (again, for me - the common user). Anywho - If I've understood it correctly the J13 is the same as pins 50-53? If so - is it possible to have them both connected at the same time? I tried to connect my SD card to the jumpers on the center of the board according to the reference manual but it does not work. Is it possible that I have a broken board or something since I never get these pins to work? :S My new plan is to have the display connected to pins 50-53 + SSpin 46 and have the SD card connected to J13 + SSpin 12. I have the JP3 and JP4 set to master, and J13 connected as the manual suggests for master-mode, but still no disco.

Scratch that. My bad. The connector I used for the J13 didn't quite fit. When I held it in place it works as expected. Case closed. :)

rasmadrak

Tue, 20 Sep 2011 08:27:45 +0000

Has anyone successfully connected a SD card reader to their Chipkit? I've managed to connect it and read, but it takes 20 ms to read 6 bytes, which is really slow.

How can I improve this performance? Is there 3'rd party library that I can use instead of the native SD-library that comes with the MPIDE?

Thanks!

//---------- EDIT

It turns out I was reading to little data. With 4096 bytes read, the total time was 48 ms. So I figure there's still a couple of digitalWrite's in the library that slows the reading down. But performance wise I could work with this. :)

Sorry guys...

bassem

Wed, 06 Jun 2012 22:23:39 +0000

hi there, i m interrestested with this subject to connect my chipkit max32 to sd card with my own module board which i made it. please help me how to program it in arduino and how to connect it on spi mode because i connected it but it dosen't work only detect my car but ni send ni write on it and ni read from it please help mee

bassem

Thu, 14 Jun 2012 10:16:09 +0000

hi there, so me again, i had bought a new card which is wireless sd shield and i tried to connect it with my chipkit card max32 so if any one had succeded in connection and write and read from it please tell me how to program it thanks

nik999389

Thu, 14 Jun 2012 14:04:35 +0000

The new MPIDE that just came out has fixed the SD card library from the original Arduino IDE. You should be able to use it now, as long as you download the new one. Although, I have heard that the interrupts are a bit messed up on this release.

spencoid

Sat, 16 Jun 2012 18:08:25 +0000

please tell me the exact version of the MPIDE that supposedly works with SD cards. i have downloaded mpide-0023-windows-20120429-test and am using it but it still seems to have bugs. i also have downloaded mpide-0023-windows-20120612-test but have not tested it for the specific bugs yet.

the problem i am now having is that after about 500 byte reads, a byte is missed. of course a single missing byte can destroy the whole file. i don't know if this is a problem with compatibility with the particular card and the SPI read method or if it is a bug in the SD library.

would love to hear what others are finding and recommendations for compatible cards or whatever might make this work. i am getting very tired of testing every possibility. i will be reading all the old posts for suggestions.

i did not have a problem with interrupts in previous versions of the MPIDE and did with the new test version. i believe that the problem is that the older versions must have had an include somewhere that is missing from the new one. i fixed the problem by adding this include to my sketch #include <plib.h> if you just need simple default style interrupts and do not need to change priority etc, you can use the arduino style attach interrupt attachInterrupt(0, button_one, FALLING); instead of this ConfigINT1(EXT_INT_PRI_1 | FALLING_EDGE_INT | EXT_INT_ENABLE);

spencoid

Sat, 16 Jun 2012 19:14:17 +0000

i found the following which describes the problem i was having with byte 512 being dropped. i looked at the most recent test IDE (mpide-0023-windows-20120612-test) and the relevant file "Sd2Card.cpp" in the utilities folder under libraries/sd/ is corrected. however when compiled and uploaded to the uno 32 i still have the same problem. i have no idea which files include what and why my sketch is apparently not using the corrected Sd2Card.cpp. i am using #include <SD.h> in my sketch. is this the wrong library? it is what is listed in the examples.

is it possible that this is a problem because i am using an uno and not a max? does only the max use the Sd2Card. how do i get this to work on the uno? it is really annoying to be so close to working.

this is from issue 221 in the bug reports:

I found a bug (and the solution) in the latest SD card library when reading files >= 512 bytes large.

It might have been reported before - but is still present.

In the file "Sd2Card.cpp" , on rows 380 and 403 it says "n = count - 1;" and " while (offset_++ < 514) spiRec();" respectively.

These should be changed to read:

n = count; and while (offset_++ < 512) spiRec();

Without these changes the last byte in each 512-byte block will never be read... If only the n = count is changed, the performance will drop until 514 is changed to 512 (its' probably error checking/double loading) .

So - I thought my bitpacking routine was faulty, but it turns out to be the library. It looked like it worked when I loaded an unpacked image, but the error was always there - just masked better.

It can easily be reproduced by reading a file and checking the values around the end of each block - they will be read as 0's.

rasmadrak

Wed, 20 Jun 2012 10:05:21 +0000

Hi there,

Did you replace the Arduino file or the Chipkit file? I'm using a Mac so I can't help with the file placement on Windows, but on the Mac the two libraries reside in vastly different folders for each board.

spencoid

Wed, 20 Jun 2012 16:26:17 +0000

i finally got it to work. i had so many copies in each different version of the IDE that it was very confusing. so i renamed all the library and sketch folders except in the latest revision folder. then i checked the sd2.cpp file (or whatever it was) and made sure every instance of it was the latest. it now works but as someone else suggested, interrupts are not working. seems that an include was left out of the current version and has to be added to a sketch if you want to use anything other than default arduino type interrupts. #include <plib.h> this got it working.

nik999389

Wed, 20 Jun 2012 20:17:51 +0000

They came out with a new version today (6/20/2012) and that one seems to have an SD card fix. I don't know if the interrupts are still messed up, but you should have a better time using that one.

rasmadrak

Thu, 21 Jun 2012 09:40:17 +0000

The interrupt problem is unrelated to the SD card fix. I know, since it's my library fix they implemented. :)

Glad you got it working! The SD card has been rather troublesome since the get-go, but now we're on the right track as far as reading goes. I have not yet tested any writing extensively thou.

spencoid

Thu, 21 Jun 2012 14:12:32 +0000

i haven't looked into the details but since the interrupts work just fine if i add the following #include <plib.h> (which was not required before) this code must have been included by default previously and no longer is. i have a great diff program ("Beyond Compare")and could track down the location but since it is working i am not motivated to do so.

mamumo

Mon, 09 Jul 2012 08:33:32 +0000

Scratch that. My bad. The connector I used for the J13 didn't quite fit. When I held it in place it works as expected. Case closed. :)