Hi, I'm using Steve's wonderful SD card module (4.1.4) but having iffy results. Here's hoping my dumb mistake is obvious to you...
I have reassigned the SD's chip select (CS) pin to PortD.2 (its default is PortC.2). Oddly, D2 doesn't go low when I run SD.Init() routine, it is always high, causing SD.Init() to return a "No response" code. Obviously so -- the SD card never got a select signal (CS is active low).
The SD module code looks OK, and I have declared the pin reassignment prior to the include statement, as
#option SD_CS = PortD.2
Include "SDFileSystem.bas"
Any idea what I'm doing wrong? Why can't I pipe the CS signal out PortD.2?
SD Module Pin assignments
Moderators: David Barker, Jerry Messina
-
breakthrough
- Posts: 8
- Joined: Wed Jul 29, 2009 9:43 pm
- Location: WA
SD Module Pin assignments
"If we use fuel to get our power, we are living on our capital and exhausting it rapidly. This method is barbarous and wantonly wasteful and will have to be stopped in the interest of coming generations." - Nikola Tesla
-
Senacharim
- Posts: 139
- Joined: Tue Aug 10, 2010 5:19 pm
- Location: Ventura, CA
-
breakthrough
- Posts: 8
- Joined: Wed Jul 29, 2009 9:43 pm
- Location: WA
Hi, thank you for your replies!
Yes, PortD was assigned as digital (not Parallel hardware port) and the other definitions are correct. The SDFileSystem module defaults to PortC.2 for the /CS line and I resoldered the circuit for that connection, still to no avail.
The major problem here is that calling SD.Init() actually hangs, in MSSP mode, and in SW mode it pauses awhile the returns the "No Response" error code. This happens with all the default pins wired to the SD card.
The speed is set at SpiOscDiv16, but adjusting it doesn't produce changes. The clock crystal is 2 or 4 MHz (I tried changing that from 2, to 4, no improvement).
The SD itself is a 2GB Kingston, and I am using a TXB0104 level shifter IC to conserve battery life (it is more efficient than the resistive divider method shown in the module .chm and .pdf files).
SDFileSystem worked when my code was smaller, even with the PortD.2 pin designation for /CS line. As my code has grown, I get the mystery assembler errors others have noticed for large programs (even though I'm not using custom modules -- just one long page of routines!) and the SDFile module has stopped working, won't drive /CS low, etc. Maybe that's a clue? I haven't figured out what's holding up the module.
Thanks for any random ideas you may have!
Yes, PortD was assigned as digital (not Parallel hardware port) and the other definitions are correct. The SDFileSystem module defaults to PortC.2 for the /CS line and I resoldered the circuit for that connection, still to no avail.
The major problem here is that calling SD.Init() actually hangs, in MSSP mode, and in SW mode it pauses awhile the returns the "No Response" error code. This happens with all the default pins wired to the SD card.
The speed is set at SpiOscDiv16, but adjusting it doesn't produce changes. The clock crystal is 2 or 4 MHz (I tried changing that from 2, to 4, no improvement).
The SD itself is a 2GB Kingston, and I am using a TXB0104 level shifter IC to conserve battery life (it is more efficient than the resistive divider method shown in the module .chm and .pdf files).
SDFileSystem worked when my code was smaller, even with the PortD.2 pin designation for /CS line. As my code has grown, I get the mystery assembler errors others have noticed for large programs (even though I'm not using custom modules -- just one long page of routines!) and the SDFile module has stopped working, won't drive /CS low, etc. Maybe that's a clue? I haven't figured out what's holding up the module.
Thanks for any random ideas you may have!
"If we use fuel to get our power, we are living on our capital and exhausting it rapidly. This method is barbarous and wantonly wasteful and will have to be stopped in the interest of coming generations." - Nikola Tesla
-
breakthrough
- Posts: 8
- Joined: Wed Jul 29, 2009 9:43 pm
- Location: WA
Whups -- Dah, I forgot to mention the PIC is an 18F4523 type.
I reviewed the silicon errata also, and there are issues with MSSP in this chip, but they don't appear relevant to the usage here. (There is a potential issue with the Div64 clock rate but I use lower dividers on account of the intended 2 MHz crystal the PIC is to run at).
Have had some trouble wading through the large SDFileSystem module code -- this is well crafted! -- though I can't clearly discern where MSSP could hang the code? But it's sure hanging somewhere!
I reviewed the silicon errata also, and there are issues with MSSP in this chip, but they don't appear relevant to the usage here. (There is a potential issue with the Div64 clock rate but I use lower dividers on account of the intended 2 MHz crystal the PIC is to run at).
Have had some trouble wading through the large SDFileSystem module code -- this is well crafted! -- though I can't clearly discern where MSSP could hang the code? But it's sure hanging somewhere!
"If we use fuel to get our power, we are living on our capital and exhausting it rapidly. This method is barbarous and wantonly wasteful and will have to be stopped in the interest of coming generations." - Nikola Tesla
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
I routinely have huge programs with no issues like that whatsoever. "mystery assembler errors" are usually a good indication that you've got something wrong in the structure somewhere. These can be very hard to track down, but I'd start by splitting things up into smaller chunks and excluding them bit by bit until the errors go away.As my code has grown, I get the mystery assembler errors others have noticed for large programs (even though I'm not using custom modules -- just one long page of routines!) and the SDFile module has stopped working, won't drive /CS low, etc. Maybe that's a clue?
What version of SF are you using?
-
Senacharim
- Posts: 139
- Joined: Tue Aug 10, 2010 5:19 pm
- Location: Ventura, CA
Basic troubleshooting--are you certain the SD Card is powered appropriately?
Have you tried a different SD Card to see if you get the same results?
What voltage are you running the PIC at? If it's 5v, the TTL signaling from the PIC goes out at ~4.3v, while acceptable signal levels to an SD Card max at 3.6v...
Also--2MHz oscillator? I'm fairly certain your PIC's internal oscillator can go faster than that, you may wish to explore this option for testing purposes.
Have you tried a different SD Card to see if you get the same results?
What voltage are you running the PIC at? If it's 5v, the TTL signaling from the PIC goes out at ~4.3v, while acceptable signal levels to an SD Card max at 3.6v...
Also--2MHz oscillator? I'm fairly certain your PIC's internal oscillator can go faster than that, you may wish to explore this option for testing purposes.
Surviving Member
Bermuda Triangle Battalion
from 2026 to 1992
Voted "Most likely to time travel"--Class of 2024.
Bermuda Triangle Battalion
from 2026 to 1992
Voted "Most likely to time travel"--Class of 2024.
Thats a good point.
Have you got acceptable level shifting both ways?
I've used Steve's excellen SD module quite a bit. The only issues I ever had were pullups , level shifting and supply. All hardware twiddles that were sorted in 5 minutes.
The only code probs I had were when experimenting with older/smaller SDs and MMCs.
Other than that , perfect.
Have you tried soft vs hard comms?
Is your PSU for the card OK?
I've never had the mystery assembler errors, is your SF install corrupted?
Have you got acceptable level shifting both ways?
I've used Steve's excellen SD module quite a bit. The only issues I ever had were pullups , level shifting and supply. All hardware twiddles that were sorted in 5 minutes.
The only code probs I had were when experimenting with older/smaller SDs and MMCs.
Other than that , perfect.
Have you tried soft vs hard comms?
Is your PSU for the card OK?
I've never had the mystery assembler errors, is your SF install corrupted?
-
breakthrough
- Posts: 8
- Joined: Wed Jul 29, 2009 9:43 pm
- Location: WA
Hey thanks for the replies. I am using a 2MHz oscillator to keep the power drain of the PIC low. Also using the TXB0104 level shifter to minimize power drain, rather than the resistive level shifters. I have tried a 4 MHz oscillator xtal instead, with the same hang. The TXB0104 I have verified with a digital scope, it shifts the 5.0V PIC supply line to the 3.30V SD Vdd flawlessly in both directions. I can't find an electrical problem here which is why I posted the trouble to the forum. I've gone through all that, it's my job to solve those problems on my own!
The thing that stumps me here is that in the MSSP mode, the call to SD.Init() hangs. Why would it hang!? Reading the module code, stuff like While loops always appear to include a way to time-out, that is, indefinite hangs are not an option.
When I use the SW mode, the module takes infernally long -- some 45 seconds with a 4MHz xtal -- to finally come back, "No response".
During that time, from reading the SD module code, one of the very first items of business is bringing the /CS line low, in order that the SD card is enabled, since it's a low-state enable. I should obviously see that the PIC pin assigned to that line (whether PortC.2 by default, or any #option I define) is going low shortly after the SD.Init() call.
But, it doesn't. In MSSP mode, there's no transition to low on the /CS line, and it sits forever. In SW mode, there's still no logic transition on the /CS line, and almost a minute later it says "No response".
So, development on that project is at a standstill...
The thing that stumps me here is that in the MSSP mode, the call to SD.Init() hangs. Why would it hang!? Reading the module code, stuff like While loops always appear to include a way to time-out, that is, indefinite hangs are not an option.
When I use the SW mode, the module takes infernally long -- some 45 seconds with a 4MHz xtal -- to finally come back, "No response".
During that time, from reading the SD module code, one of the very first items of business is bringing the /CS line low, in order that the SD card is enabled, since it's a low-state enable. I should obviously see that the PIC pin assigned to that line (whether PortC.2 by default, or any #option I define) is going low shortly after the SD.Init() call.
But, it doesn't. In MSSP mode, there's no transition to low on the /CS line, and it sits forever. In SW mode, there's still no logic transition on the /CS line, and almost a minute later it says "No response".
So, development on that project is at a standstill...
"If we use fuel to get our power, we are living on our capital and exhausting it rapidly. This method is barbarous and wantonly wasteful and will have to be stopped in the interest of coming generations." - Nikola Tesla
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Since it used to work "when my code was smaller", that's probably a clue. I don't see much that would keep you from seeing the CS line go low, esp. since you've tried it in both SW and MSSP modes on two different port pins.
What's in the rest of the code? Are you using interrupts by chance?
I don't know how you're testing things, but if you have one of the ICD's (like the pickit2) you can do source-level debugging in MPLAB by importing a .cof file. That would let you set breakpoints, examine registers, etc.
What's in the rest of the code? Are you using interrupts by chance?
I don't know how you're testing things, but if you have one of the ICD's (like the pickit2) you can do source-level debugging in MPLAB by importing a .cof file. That would let you set breakpoints, examine registers, etc.
-
Senacharim
- Posts: 139
- Joined: Tue Aug 10, 2010 5:19 pm
- Location: Ventura, CA
I know this is rather non-specific, but I find it helpful, perhaps it will help you too. Here goes:
When I'm troubleshooting, I pretty much always find it helpful to verify my assumptions. Is there something else that you're absolutely certain is working? Double check.
Simplify! If you make a simple 'SD Card is working' program which does almost nothing but interact with the SD Card and then say "success!" does that work? At what point does it break when you add more code? Likely there's a clue there.
Lastly, every time something should be working--like all the parts are in place, the code is good, but for some reason it just doesn't go--then it's something stupid. Some tiny little easily overlooked thing which you'll kick yourself for when you find & correct.
Good luck. Looking forward to hearing of your success on this.
When I'm troubleshooting, I pretty much always find it helpful to verify my assumptions. Is there something else that you're absolutely certain is working? Double check.
Simplify! If you make a simple 'SD Card is working' program which does almost nothing but interact with the SD Card and then say "success!" does that work? At what point does it break when you add more code? Likely there's a clue there.
Lastly, every time something should be working--like all the parts are in place, the code is good, but for some reason it just doesn't go--then it's something stupid. Some tiny little easily overlooked thing which you'll kick yourself for when you find & correct.
Good luck. Looking forward to hearing of your success on this.
Surviving Member
Bermuda Triangle Battalion
from 2026 to 1992
Voted "Most likely to time travel"--Class of 2024.
Bermuda Triangle Battalion
from 2026 to 1992
Voted "Most likely to time travel"--Class of 2024.
-
breakthrough
- Posts: 8
- Joined: Wed Jul 29, 2009 9:43 pm
- Location: WA
SD Module and Interrupts
Hey, thanks for the helpful suggestions! I appreciate those.
Senacharim -- you are absolutely right, (or at least I really agree!) that it's often a stupid thing in this type of case, that exposes a bad assumption made somewhere.
Jerry, I think your question might expose what assumption it is. Yes, this code does use the structured interrupts provided by SF. (Two timers assert interrupts to yield a precision low duty cycle low power pulse generator. That's the PIC's primary job! Periodically it breaks, does some A/D and logs to the SD card.) The hardware PWM could not yield the low duty and high resolution needed so I used this timer / interrupt method.
Now, SD.Init() still hangs even when it is called up "first" in the code, before any interrupts are enabled. Since the interrupt routine changes a port pin explicitly, providing the pulse generator output, I can see that the interrupt routine is not running, since OSC1 and OSC2 crystals are running but the pulses generated by the interrupt routine are absent. At one point I put marker code to drive another pin if the Interrupt routine was ever called, but this pin remained silent as well.
I had assumed at that point, the interrupt code is loaded into the PIC's flash, but none of the vectors are logically enabled, so it's mute... nothing's being interrupted until I enable it.
I also tried explitly disabling the interrupts before calling SD.Init() so that procedure would not get distracted (if that's the right word), but still it would hang. So I thought, interrupts are not the problem here...
But: there is a routine I call first before anything else, which sets up the Port pins and other registers, initializes arrays, etc. In that initialization routine, I did set up the Timer configurations as well as enabling Global interrupts. The Datasheet shows the interrupt logic schematic, and I turned on the top level enable lines.
I didn't set bits enabling any particular interrupt sources, but I do remember enabling the top-level stuff...
Do I need to explicitly disable ALL interrupts from the top down, before calling SD routines? Do the SD routines use interrupt vectors? I'm wondering why you asked.
Senacharim -- you are absolutely right, (or at least I really agree!) that it's often a stupid thing in this type of case, that exposes a bad assumption made somewhere.
Jerry, I think your question might expose what assumption it is. Yes, this code does use the structured interrupts provided by SF. (Two timers assert interrupts to yield a precision low duty cycle low power pulse generator. That's the PIC's primary job! Periodically it breaks, does some A/D and logs to the SD card.) The hardware PWM could not yield the low duty and high resolution needed so I used this timer / interrupt method.
Now, SD.Init() still hangs even when it is called up "first" in the code, before any interrupts are enabled. Since the interrupt routine changes a port pin explicitly, providing the pulse generator output, I can see that the interrupt routine is not running, since OSC1 and OSC2 crystals are running but the pulses generated by the interrupt routine are absent. At one point I put marker code to drive another pin if the Interrupt routine was ever called, but this pin remained silent as well.
I had assumed at that point, the interrupt code is loaded into the PIC's flash, but none of the vectors are logically enabled, so it's mute... nothing's being interrupted until I enable it.
I also tried explitly disabling the interrupts before calling SD.Init() so that procedure would not get distracted (if that's the right word), but still it would hang. So I thought, interrupts are not the problem here...
But: there is a routine I call first before anything else, which sets up the Port pins and other registers, initializes arrays, etc. In that initialization routine, I did set up the Timer configurations as well as enabling Global interrupts. The Datasheet shows the interrupt logic schematic, and I turned on the top level enable lines.
I didn't set bits enabling any particular interrupt sources, but I do remember enabling the top-level stuff...
Do I need to explicitly disable ALL interrupts from the top down, before calling SD routines? Do the SD routines use interrupt vectors? I'm wondering why you asked.
"If we use fuel to get our power, we are living on our capital and exhausting it rapidly. This method is barbarous and wantonly wasteful and will have to be stopped in the interest of coming generations." - Nikola Tesla
-
Senacharim
- Posts: 139
- Joined: Tue Aug 10, 2010 5:19 pm
- Location: Ventura, CA
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
I wouldn't think so. The SD routines don't use interrupts. I asked because it's very easy to forget about context saving and associated stack frame conflict issues when you're using interrupts, and that can cause all sorts of mysterious problems.Do I need to explicitly disable ALL interrupts from the top down, before calling SD routines? Do the SD routines use interrupt vectors? I'm wondering why you asked.
It sounds like that's not the issue here. My only comment would be regarding your initialization routine where you enable the global interrupt flags. Again, it doesn't sound like this is an issue, but it might be safer to use the SF Enable()/Disable() functions for that. I'm always nervous about setting GIEH/GIEL without knowing that all the other peripheral bits are masked appropriately. Probably just me being paranoid...