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
Yes, I've been following the di/ei / i2c / spi /whatnot!

I'm glad you got the little joke.

This is a real puzzle. I wish I could figure it out.

If the Micro are different depending how they're powered, it's clue. Grounding or rate of rise of power rails or (something).

Maybe... but if no SD.mount(40); in the program, I get instant Yellow blinks always, on every, powerup (and reset button) from USB or external power.

The yellow blinks with SD.mount(40); in the code are very rare indeed, been quit a while since I have seen it and I think I am wearing reset button and connectors out.


AND BTW, you are my other hero here
Wrongly soldered (wrongly connected) SD card socket?

Misaligned or whatever.

Big Grin Big Grin Big Grin Big Grin

Now I need some hardware/trisbiting help.

The boards are solid and have no cold or bad solder.

Remember we just sort-of realized that Olimex took off the 32megakilahz Wink xtal for the RTCC and ran the two xtal input pins to CON1 2 & 3 which should be OK.

BUT, somehow the PIC is in a mode that is sensing those two sensitive pins AND there may be interrupts (ha another tie in) that are bothering the code.

I can make it blink the yellow lights properly and consistently (ha) if I put my skin across CON1 2 & 3......

WOW, this could be big!!! Maybe all kinds off weird things will stop happening. Big Grin

If possible, we need a condition that if code is MICRO compiled, those pins are turned off, otherwise we need to terminate those two pins in the hardware so they don't interfere (to GND of Vdd or something).

Do I need to research this more or is this enough for one of you to say, OH, thats easy, lets just add this one line here.

If we do it software wise, it has to be a on/off setting in case someone does add the xtal.

Are we all Big Grin now?

Hi Dale,

I believe that all the tristate input/outputs default to inputs on power up.

What you could do is try including some extra code to set the appropriate pins to output and then setting them either low or high or just put a couple of reasonably high value resistors to ground or 3V3. It probably doesn't matter which - I would just choose that which uses the least power.

Well, I don't know but you've done well because it sure looks to be the critical hint (or more)!!!

Maybe hunt through the init code that gets called behind the scenes before setup() - it must config the xtal or the chip (*) for the xtal or something. Sorry but off the top of my head I don't know what/how.

(*) I mean the PIC32, I suppose it needs telling it has a 32kHz xtal and there's a fair chance the init code never got changed for this oddity of the Olimex MICRO board (i.e. that it hasn't got the 32kHz xtal!).

Mark (mf)

But that is my second choice, can't we do it in software. Why only these two pins sensitive. Tells me that there may be a software solution. Is there?


looks like we are all talking at once, LOL

I'm going to lunch, been at it 12hrs now, please someone give me that one liner (or whatever) code change......
Gotta look at that init code Smile

Say it's telling the CPU to run at X times the xtal speed, for the xtal it hasn't got....

Looking at the MicroChip data as well as being possibly used Xtal oscillator these are also "Change Notification" inputs - see Section 12. I/O Ports DS61120E. They have various built-in pull-up and pull-down capabilities that would need to be activated.

Also to quote from another MicroChip document "All port I/O pins are defined as inputs after a device Reset." so there may not be any need to specifically configure them other than to deal with this issue.

It would be worth seeing if any other PIC32 Pinguino Micro users have similar problems or whether Dale has just been unlucky with the particular board he has.

I also noticed that on the OTG in addition to the xtal there are 10pF capacitors to ground which might would also reduce their susceptibility to noise.

Regards and congratulations on the progress - hopefully we can soon put this one behind us and I think we may also have found a few other bugs in the process.
(06-05-2012, 07:57 PM)mf01 Wrote: [ -> ]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.



Missed this altogether, you were zeroing in on the RTCC stuff too, WOW.


(06-05-2012, 09:39 PM)mf01 Wrote: [ -> ]or whether Dale has just been unlucky with the particular board he has.

BUT, I have two boards and acted same on both...

Hard to believe unlucky at that point, but as I have come to learn, ANYTHING is possible and it will happen.
Pages: 1 2 3 4 5 6 7 8