Pinguino Forum

Full Version: PIC32 PINGUIONO's and SD
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
Here is what I did.

I put the two PDE files in F:\Pinguino32X.3-381\examples\10.Libraries\SD

I put all the SD library files in F:\Pinguino32X.3-381\p32\include\pinguino\libraries\sd

I opened in F:\Pinguino32X.3-381

I loaded F:\Pinguino32X.3-381\examples\10.Libraries\SD\YellowWithMount.pde

I compiled for MICRO.

I uploaded.



Oops, forgot to change 8 to 40 but still same thing, NOTHING.

Here are the IOS files.

I will now look at what you did in detail.


With 8 and OTG compiled I get expected results for both pde files.

Sorry I was so delayed in getting back to you, I was working on another post and forgot to keep checking to see if you posted, I wish I could get email notification to work with this forum, does it work for you?

Wow, I just realized that we should both have the same IOS files now (both using 381), isn't that right?
Hi Dale,

I just happened to notice "spi.c {} error fix" in your signature - what was this and has it been included in r381 or the working version that you are using for testing ?.

The reason for asking is that I noticed the following code in spi.c :-
#ifndef SPIx                // Use SPI port 1, see PIC32 Datasheet
    #if defined(PIC32_PINGUINO_OTG) || defined(PIC32_PINGUINO)
        #define SPIx 2        // default SPI port is 2 for 32MX440F256H which has only one SPI port
        #define SPIx 1        // default SPI port is 1

and remembered that the Micro also uses the 32MX440F256H.

Just thinking out loud here.

The OTG and MICRO are physically the same with respect to the SD card, by that I mean their schematic is identical and the signals go to the same PIC pins.

So I look at the different pin assignments in digitalw.c.

We are accounting for the difference in chip select pin assignments (I hope) by using either 8 or 40 when we mount.

But do we need to make sure that the library is taking care of the other 'different pin assignments?
Pic Pin      OTG    MICRO
RB13         8         40
RG6          13        32        
RG7          12        38
RG8          11        37
Hi Dale,

I don't think we need to worry about the other pins as the library files use SPI functions rather than Pinguino pins (which are just another way of addressing a particular port or register) to control the other three SPI lines - so far it appears to be only the CS line that is dealt with separately. But have a look at my last post which overlapped with yours because I did find something in the spi.c which may be a problem.

When I did the test this morning, no I had not updated the spi.c in r381 with my changes.

I have now and they address not only the MICRO exclusion you noted but an actual {} error that I think should get into the actual current files that get distributed.

I discovered the {} error and MICRO exclusion at some point in another thread but to find it in the attached spi.c, just search for '//dk' Here is the thread where I discovered the error and exclusion:

And I have attached the spi.c I am using now so that I can run my current Lazair MICRO code in r381.

Still no yellow led Angry

Hi Dale,

I think I have reached the limit of the things that I can currently think of to try on this one. The only other approach I can think of is to try to tackle the problem from a different angle e.g. to list, and possibly publish, the programs that you have tried on the Micro that appear to function correctly, together with which libraries they each use and full details of the environment in which they were compiled and run. By seeing what does work it might eliminate some areas to look at when trying to work out why the SD library doesn't.

No problem I will do that and keep posting here any questions I have.

Right now I can't figure out why the pinmode command for SDCS is below a digitalwrite for the SDCS in sdmmc.c . Is that meant to be that way? Seems to work either way.

I have been able to use the MICRO I2C and SPI together in my Lazair code so I know the MICO works, in fact I have 2 MICRO's and 3 SD cards that all behave the same way.

I could post the current Lazair code if you think I should.

YellowWithMount.pde works fine on my MICRO's if you rem out one line, the SD.mount(40); line.

I really think another clue is that SOMETIMES the program actually runs, either minutes after powering up, or vary rarely when you power up as it should. So it does run the code sometimes.

Just rambling right now sorry.

To take so long I suppose it's one of:
1. non-responding (probably not present) device and gradually things time out and move on to later code (CDC? serial? A.N.other?)
2. the xtal is kHz but should be MHz LOL
3. some setup code is wrong and the cpu or peripheral divider is miles out
4. er, something else!

Big GrinBig Grin on inside joke.

If it were strange timeouts, shouldn't they be consistent from one powerup to the next and so far I have not been able to get one of these random non-failures to happen on an external power powerup.

Same SD library works with OTG consistently but not ready to revert to it yet.

Thanks for a bit of a redirect.


AND, if you have been following my trials and tribulations so far on getting I2C to work without freezing, could these two problems be related?

For instance, to make it so that my I2C lcd display could be used without random code freezing (stuck somewhere not in my code), I had to use asm("di") before ant I2C bus use and asm("ei") after use.

Is there something weird being done with the PIC configuration on the MICRO vs OTG?

Where would I look to see if there is a difference?

Hi Dale,

I did have another thought after all.

It occurred to me that due to the way the digitalw.c works as OTG P8 = RB13 = Micro P40 and OTG P30 = RD1 = Micro P10 (=YELLOWLED) and as the OTG and Micro cards have the same PIC32 chip and using the same SPI lines to connect to the SD card slot (except for SDCS) if I set SD.mount(40) and compile a program (using just these pins and the SPI functions) as a PIC32 Pinguino Micro, then the our two test programs would compile and could then be uploaded to a PIC32 Pinguino OTG. Initially I was slightly surprised that the program actually ran as intended as I had not made the changes to spi.c in my test environment but it on checking I found that the SD library files are written to specifically use SPI2 !

That the SimplifiedDataLoggerExample was compiled as a Micro is confirmed by the time and date stamp on the files written to the SD card (01 Jan 2012 11:00 GMT) (it seems to have converted from daylight saving time) - this is the default date & time that should be used if it is not an OTG board. To confirm this I recompiled as an OTG with SD.mount(8) and the file on the card had a noticeably different date (a spurious one as the SimplifiedDataLoggerExample does not set the RTCC).

I will have to think what this means - it might be that there is a problem with your specific Micro board (or that I just don't know what is going on Undecided ).

I wonder if there is anyone else reading this thread who has a PIC32 Pinguino Micro who would like to try and see what their board does? The only change in my "test environment" from X.3 r381 are to the SD library as included in post #40 above. Any SD.mount calls need to be SD.mount(40) for the Micro.



to respond to your post #47 above, I think it is deliberate to ensure that the output is in a known state before it is enabled - doing it the other way round might result in an unnecessary transition.

Pages: 1 2 3 4 5 6 7 8