Hi Matt, Issue closed... Here how: - I checked all SPI pins, blinking a LED, everything's working - I then removed my 12K pullup on SS pin. PIC can move out of writing mode (it was previously stuck before stop_writing). - tests reveal inconsistent behavior, sometimes it gets stucks, sometimes not. - when I push the side of the card to force connection, reading works, though not consistent (value is sometime the expected one, sometimes not) - well, something is wrong about the connector. I soldered again the pins, just melting the solder again, replug the card,and... and ?... and .??? it works :) - soldered again my pullup => OK
So.... it seems my micro Sd socket was the faulty one, I guess the many push/pull get rid of connections. Lesson learned. I guess. Tried the SDHC, not success btw. What was interesting here in all of this is the potential report we can have running your procedure. It can definitely help tracking hardware problem, and maybe most importantly, tracking which SD card are supported. Do you think you could build a table of supported SD card, showing results from a reporting sample ? Thanks Seb 2011/11/17 mattschinkel <[email protected]> > As soon as you told me about a bunch of 0xFFFFFFFF.... I had a feeling > it was your hardware, which is why I asked. > > It didn't make any sense that you would get 0xFF and I get 0x00 on > your new high capacity. > > In past experiences getting only 0xFF on SPI means hardware trouble. > Don't take my word for it though. > > So hopefully you can try out MSD now. You should be able to just > replace the device block. > > In any case, we both seem to have the same issues with SDHC cards. We > both get 0x0000000000. Do you get any response at the end of the init > proc as suggested previously? > > Matt. > > On Nov 17, 1:44 am, Sebastien Lelong <[email protected]> > wrote: > > Hi Matt, > > > > Ok this is weird... > > > > I got 0000000000 on my std capacity card. And FFFFFF00 on my high > capacity > > card on the first call, then 0000000000 on other calls (it was in a > forever > > loop btw). More weird, when I switch off/on the PIC, I now only > > have 0000000000, even on first call... > > > > Now, on another PIC. Using my very first Bee, not the exact same > hardware, > > but I wrote minix libs on this one, so I know it's working. SDHC (4GB): > > 0000000000. Std cap (1GB): 08FFFFFFFF. Mmmh.... This one seems to work ? > I > > tried my known-to-work sample, and... it works ! SDHC won't, but that's > > another issue. > > > > So... something is wrong on my hardware on my last bee, something that > has > > changed since it used to work. I'll try SPI pins asap. > > > > At least, we seem to have few procs in order to test if SD card is > > supported or not, right ? > > > > thanks again ! > > Seb > > > > 2011/11/16 mattschinkel <[email protected]> > > > > > > > > > > > > > ok, here's another one to try (after init like the others)... You > > > should get 04FFFFFFFF on your standard capacity card. Bit 2 of the > > > first byte should be set as it is on mine 0b00000100. > > > > > High capacity cards should return something else, although 2 high > > > capacity cards I have tried are not giving me what I am expecting. I > > > get 0000000000 on my high capacity, but should get something like > > > 010001AA00 > > > > > procedure sd_read_if_cond() is > > > sd_chip_select = low -- enable the sd card > > > > > var byte response > > > send_command(SD_SEND_IF_COND, 0x1AA, response) > > > print_byte_hex(serial_data,response) > > > > > print_byte_hex(serial_data,spi_master) -- Get a responce > > > from the card after each command > > > print_byte_hex(serial_data,spi_master) -- Get a responce > > > from the card after each command > > > print_byte_hex(serial_data,spi_master) -- Get a responce > > > from the card after each command > > > print_byte_hex(serial_data,spi_master) -- Get a responce > > > from the card after each command > > > > > spi_master = 0xFF -- send 8 clock pulses > > > > > sd_chip_select = high -- enable the sd card > > > end procedure > > > > > sd_read_if_cond() > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "jallib" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group at > > >http://groups.google.com/group/jallib?hl=en. > > > > -- > > Sébastien Lelong- Hide quoted text - > > > > - Show quoted text - > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > > -- Sébastien Lelong -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
