| View previous topic :: View next topic |
| Author |
Message |
tinley
Joined: 09 May 2006
Posts: 66
|
| mmcsd.c and fat.c on dsPIC30Fxxxx |
 Posted: Mon Sep 06, 2010 3:20 am |
 |
|
Has anyone implemented SD or MMC card on a dsPIC30 please? I am in a hurry to get this working, so I am prepared to pay for a solution if it works, although I am keen to stick with the CCS PCD compiler.
I understand that not many people have got these CCS drivers working on a PIC18Fxxxx, so I believe the problem is with the drivers more than the different chip.
I have used the code 'as is' but added the directive #TYPE classic
SD card seams to initialise, but FAT fails to initialise with a card plugged in. It doesn't report an error with no card???
I have tried andrewg's bug fix and MBR support.
Thank you for any help please?
'My' code follows:
| Code: |
#define version "1.XXb"
// V1.00b remember to add wdt
#include "C:\PICC\Products\OBO Box\OBO Box.h"
#TYPE classic
#include <stdlib.h> // for atoi32
//media library, a compatable media library is required for FAT.
#use fast_io(g)
#define MMCSD_PIN_SCL PIN_G6 //o
#define MMCSD_PIN_SDI PIN_G7 //i
#define MMCSD_PIN_SDO PIN_G8 //o
#define MMCSD_PIN_SELECT PIN_G9 //o
#include <mmcsd.c>
[remainder deleted]
|
+++++++++++++++++++++
Ex_fat.c code deleted.
Reason: Forum rule #10
10. Don't post the CCS example code or drivers, or ask for such code and drivers.
Forum rules:
http://www.ccsinfo.com/forum/viewtopic.php?t=26245
-- Forum Moderator
+++++++++++++++++++++
and the header file:
| Code: |
#include <30F6011A.h>
//#include <string.h>
//#include <STDLIB.H>
//#DEVICE ADC=16
#device PASS_STRINGS = IN_RAM //from CCS ex_fat.c
#FUSES NOWDT //Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
//#FUSES PR //Primary Oscillator
//#FUSES HS3_PLL8 // change above 2 lines to generate 64Mhz clock from 24MHz xtal
//#FUSES PR_PLL //Primary Oscillator with PLL
#FUSES NOCKSFSM //Clock Switching is disabled, fail Safe clock monitor is disabled
//WDT time is 500kHz divided by each of the prescalers, so A512 and B1 ~ 1 second
#FUSES WPSB1 //Watch Dog Timer PreScalar B max 1:16
#FUSES WPSA512 //Watch Dog Timer PreScalar A max 1:512
#FUSES PUT64 //Power On Reset Timer value 64ms
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORRES
#FUSES MCLR //Master Clear pin not used for I/O
//#FUSES PROTECT //Code protected from reads
#FUSES WRT //Program Memory Write Protected
#FUSES NODEBUG //No Debug mode for ICD
//#FUSES NOCOE //Device will reset into operational mode
#FUSES ICSP1 //ICD uses PGC1/PGD1 pins
#FUSES NOSSS //No secure segment
#FUSES NORSS //No secure segment RAM
#FUSES NOWRTSS //Secure segment not write protected
#FUSES WRTB //Boot block write protected
#FUSES NOBSS //No boot segment
#FUSES NOEBS
#FUSES NORBS //No Boot RAM defined
#FUSES NOESS
#use delay(clock=24M)
#use rs232(baud=4800, UART1, errors)
|
|
|
 |
andrewg
Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia
|
|
| Posted: Mon Sep 06, 2010 8:34 am |
|
|
So far I've only used a 18F4620/4685, not a dsPIC30, but I don't see why it shouldn't be able to work.
1. Is the whole circuit 3.3V, or do you have level translation involved? I've only used 3.3V - much simpler.
2. Do you have pullups on the CS and SDI lines? While there should always be a pullup on any SPI CS line, I've noticed that it's frequently recommended to have one on the SDI line too, especially when SD cards are involved.
3. You're using fast_io. Have you correctly set the TRIS for MMCSD_PIN_SELECT? e.g. output_drive?
4. Do you have any other SPI device in your code - i.e. any other instance of "#use spi"? I found that two identical "#use spi" instances just don't work.
For the last point, what I ended up doing was modifying mmcsd.c like: | Code: | #ifndef MMCSD_SPI
#if USE_SW_ONLY
/* For software spi */
#use spi(MASTER,CLK=MMCSD_PIN_SCL, DO=MMCSD_PIN_SDO, DI=MMCSD_PIN_SDI, BITS=8, MODE=3, MSB_FIRST, STREAM=MMCSD_SPI, FORCE_SW)
#else
/* For hardware spi */
#use spi(MASTER,CLK=MMCSD_PIN_SCL, DO=MMCSD_PIN_SDO, DI=MMCSD_PIN_SDI, BITS=8, MODE=3, STREAM=MMCSD_SPI, FORCE_HW)
#endif
#endif |
(i.e. bracket with an #ifndef), then use the following in my mainline before any SPI device code: | Code: | #use spi(MASTER, DI=PIN_MISO, DO=PIN_MOSI, CLK=PIN_SCLK, MODE=3, BITS=8, STREAM=SHARED_SPI, FORCE_HW)
#define FLASH_SPI SHARED_SPI
#define MMCSD_SPI SHARED_SPI |
(MMCSD_PINs #define'd later on)
_________________
Andrew |
|
|
tinley
Joined: 09 May 2006
Posts: 66
|
|
| Posted: Mon Sep 06, 2010 9:12 am |
|
|
Hi Andrewg,
Thank you for taking the time to answer.
1. Yes, 3.3V circuit. A bit of a pain, as this chip won't bulk erase on 3.3V!
2. I have 10k pullups on all four lines
3. No! I assumed this would be set in the CCS code!?! I will go and check now!
4. No other SPI devices
I assumed it didn't really matter at this stage if the compiler used a software SPI instead of the preferred h/w one, but I will try your code change, thank you.
One last point, am I correct in thinking that I can choose any pin for the PIN_SELECT please? |
|
|
tinley
Joined: 09 May 2006
Posts: 66
|
|
| Posted: Mon Sep 06, 2010 9:49 am |
|
|
Update.
For some reason my compiler 4.112 does not like:
SET_TRIS_g(0xfdff);
giving:
*** Error 12 "OBO Box.c" Line 353(14,15): Undefined identifier --
Obviously I am doing something stupid!?
Note though that if I scope the pin I do get activity. I also tried rem'ing out the #use fast_io(g) but it made no difference.
Any other ideas greatly appreciated please? |
|
|
andrewg
Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia
|
|
| Posted: Mon Sep 06, 2010 10:07 am |
|
|
I've checked the mmcsd.c and it is doing output_drive for the pin select, my mistake.
Any pin capable of digital I/O is good for PIN_SELECT.
_________________
Andrew |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Mon Sep 06, 2010 12:34 pm |
|
|
Since you mentioned that you're willing to pay for a solution, google "brush electronics". That site sells a complete FAT SD card file system/hardware driver, written for the CCS compiler.
I'm a very satisfied customer - it just works, right "out of the box." |
|
|
collink
Joined: 08 Jan 2010
Posts: 137
Location: Michigan
|
|
| Posted: Mon Sep 06, 2010 1:44 pm |
|
|
| newguy wrote: | Since you mentioned that you're willing to pay for a solution, google "brush electronics". That site sells a complete FAT SD card file system/hardware driver, written for the CCS compiler.
I'm a very satisfied customer - it just works, right "out of the box." |
Yes, I use their stuff too and it works very well. Just as well, in fact, as the CCS routines should have. Why bother providing source code for device drivers if you are just going to put out garbage that seems to work for almost no one? In my opinion they really need to work on their included source code. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Mon Sep 06, 2010 2:50 pm |
|
|
| Microsoft has a US patent on FAT. Microsoft sells licenses. Commercial sales of FAT technology is a possible patent infringement. Make sure whoever sells you a fat solution has a Microsoft license. US law is extra territorial so a US citizen is not shielded by a foreign purchase of a product that might even be legal in the foreign country. |
|
|
andrewg
Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia
|
|
| Posted: Mon Sep 06, 2010 11:00 pm |
|
|
IANAL, but the Microsoft patents are for long file name support, not FAT support. Avoid long file names and you should be fine. Note that the CCS library *does* include LFN support!
It may be that a commercial implementation may be the best route. Two things to try, though:
1. Try a forced software SPI.
2. Turn off fast I/O and revert to standard.
Also, some of the CCS library uses countdown timing loops. Faster CPUs will timeout faster, perhaps too fast? If the CPU speed can be slowed down, that may help provide some clues too.
_________________
Andrew |
|
|
tinley
Joined: 09 May 2006
Posts: 66
|
|
| Posted: Tue Sep 07, 2010 1:58 am |
|
|
| newguy wrote: | Since you mentioned that you're willing to pay for a solution, google "brush electronics". That site sells a complete FAT SD card file system/hardware driver, written for the CCS compiler.
I'm a very satisfied customer - it just works, right "out of the box." |
Unfortunately not for a PCD compiler??? |
|
|
tinley
Joined: 09 May 2006
Posts: 66
|
|
| Posted: Tue Sep 07, 2010 4:36 am |
|
|
Hi Andrewg,
Thank you again for the suggestions.
I have tried all your suggestions now and fitted an 8MHz crystal. Still no go.
I've also been somewhat hung up on why my compiler doesn't like the SET_TRIS_g(0xfdff);
I'll load up an older version of the compiler to check if it is a recent bug and also see if the example drivers work with that? |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Tue Sep 07, 2010 5:05 am |
|
|
| Douglas Kennedy wrote: | | Microsoft has a US patent on FAT. Microsoft sells licenses. Commercial sales of FAT technology is a possible patent infringement. Make sure whoever sells you a fat solution has a Microsoft license. US law is extra territorial so a US citizen is not shielded by a foreign purchase of a product that might even be legal in the foreign country. |
I believe that to read and write fat32 is free, to format media to fat32 requires a license. So as long as you format the card on a PC you are OK 
Also please note, SD hold patents for the SD interface and you require a License to make and sell hardware which uses the SD interface, THIS includes the SPI protocol when accessing SD cards. I found out rather late in the design of my own hardware that this is required and emailed them regarding the SPI interface. I was told it still applies! $3000 initial and $2000 per year (if I remember correctly) |
|
|
tinley
Joined: 09 May 2006
Posts: 66
|
|
| Posted: Tue Sep 07, 2010 5:13 am |
|
|
| Wayne_ wrote: | | Douglas Kennedy wrote: | | Microsoft has a US patent on FAT. Microsoft sells licenses. Commercial sales of FAT technology is a possible patent infringement. Make sure whoever sells you a fat solution has a Microsoft license. US law is extra territorial so a US citizen is not shielded by a foreign purchase of a product that might even be legal in the foreign country. |
I believe that to read and write fat32 is free, to format media to fat32 requires a license. So as long as you format the card on a PC you are OK
Also please note, SD hold patents for the SD interface and you require a License to make and sell hardware which uses the SD interface, THIS includes the SPI protocol when accessing SD cards. I found out rather late in the design of my own hardware that this is required and emailed them regarding the SPI interface. I was told it still applies! $3000 initial and $2000 per year (if I remember correctly) |
OK, so we are using an MMC card then!!! |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1903
|
|
| Posted: Tue Sep 07, 2010 7:41 am |
|
|
| tinley wrote: | | newguy wrote: | Since you mentioned that you're willing to pay for a solution, google "brush electronics". That site sells a complete FAT SD card file system/hardware driver, written for the CCS compiler.
I'm a very satisfied customer - it just works, right "out of the box." |
Unfortunately not for a PCD compiler??? |
It will work for the PCD compiler too.
....Whether PCD will generate useable code at this point in time is debateable, however. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Tue Sep 07, 2010 7:56 am |
|
|
| Quote: | | IANAL, but the Microsoft patents are for long file name support, not FAT support. Avoid long file names and you should be fine. Note that the CCS library *does* include LFN support! |
Perhaps this could be true but it seems a flimsy thread to defend against a patent suit. Your honor we used all of their specifications except we used shorter file names that's why there is no patent infringement. Mr Edison we used all your ideas but we call it a lite bulb not the longer name light bulb.
Now a read only of FAT may be more defensible since nothing new is actually created. Anyway a letter from Microsoft authorizing royalty free use of FAT with short file names has to be the better approach. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
