Friday 19 October 2012

Sourceboost SD Card reader

We're having a bit of a time of it at the minute, just trying to get our PIC16F1825 to correctly initialise an SD card. It's not helped by the fact that we're using a new chip we've never used before, in a language/syntax we've not used for a long time, with a compiler we've never seen, using hardware peripherals we've only ever simulated in software. These last few days have been a very steep learning curve!

At last night's BuildBrighton meeting, Jason spent a good few hours going over all our registers and code to see if there was anything obviously wrong, but found nothing. But we couldn't even get the SPI hardware module on the PIC to operate, let alone send data using it!

Jason has a Scanalogic Logic Probe/Analyser which has proved invaluable in finding out what's going on at a pin-wiggling level. Using it, it took just a few minutes to realise that one of our fuse settings was incorrect and that instead of sending data over SPI, we were outputting the PIC clock signal onto the (multiplexed) SPI_OUT pin. D'oh.

With the Scanalogic Probe in place, we were able to actually see pin activity as data was exchanged between the devices



Using this helped us identify where things were initially going wrong and after three hours of getting nowhere, we finally manged to see SPI data being sent over the pins. Now our problem is, there's nothing coming back from the SD card!


In the image above, the blue line is the SPI clock. The yellow is the SPI data going from the PIC to the SD Card. Red is the trigger pin (used to start the probe reading the data) and the green is *supposed* to be the data coming back from the SD card.....

3 comments:

  1. This is why all the low level stuff can sometimes scare me, as you have no clue where the problem is as it's not coming up as an exception in the code, so it could be just about anything (but generally something extremely simple). Looking forward to what you come up with though!

    ReplyDelete
  2. It's true, when you get a completely "dead" response - whether it's a PIC not behaving (that's why we all have a blinky hex ready to burn, just to make sure there mcu is actually alive and can flicker an output pin) or more frustratingly, not getting a response from a peripheral.

    Thankfully, Jason's logic probe was invaluable in problem solving. And despite all indications being a problem with hardware (a bad connection or missing power/ground somewhere) because the response was a 0v flatline, it turns out that it was a software issue all along!

    But I know what you mean. It's not scary so much - just frustrating to debug!

    ReplyDelete
  3. The initialize the compilers hardware are so steep with curves. It such a peripherals and syntax of the new chips simulated software.


    R4 3DS

    ReplyDelete