14
\$\begingroup\$

I'm working on a V-USB project that shows up as a Keyboard using an ATmega328p. The USB part is working great (it's not my first V-USB project), but after I start the V-USB stack with usbInit(), all calls to the SD card library fail. If I call the same functions before usbInit(), everything works perfectly.

I use an Arduino clone called Diavolino, but without the Arduino/wiring framework. I have the USB connected to digital I/O 2 and 3, and the SD card to 10-13 (built-in SPI lines).

I looked through the SD card library and found no sign of it using any interrupts or registers other than SPxx. I also grep'd though the V-USB code, but it doesn't even touch the SPxx registers.

The first sign of the problem was when the device disconnected when it was supposed to access the SD card. Then I put usbPoll() and wdt_reset() calls into all SD card handling loops, and found that in case of writing, the card waits forever for acknowledgement from the card after having sent the last two bytes (CRC-16).

The SD card library I use is sd_raw by Roland Riegel.

\$\endgroup\$
9
  • 2
    \$\begingroup\$ It is my understanding that V-USB is very CPU-intensive, and it's probably introducing unacceptable delays into the SPI routines. Normally, SPI operations are not timing-sensitive, but write and erase operations on SPI FLASH definitely are. \$\endgroup\$
    – Dave Tweed
    Commented Oct 11, 2012 at 13:01
  • \$\begingroup\$ The problem is that even read operations didn't work most of the time, and as I've read, SPI comms are done independently as soon as the data and control registers are set by the running code. \$\endgroup\$
    – dnet
    Commented Oct 11, 2012 at 13:08
  • \$\begingroup\$ @DaveTweed - time sensitive in terms of having to wait for the card yes, but in terms of not being able to keep the card waiting for your program?? \$\endgroup\$
    – Chris Stratton
    Commented Oct 11, 2012 at 13:38
  • 2
    \$\begingroup\$ Likely you are waiting on something that either cannot happen or cannot be detected; for example, the I/O pin might have been reconfigured and no longer be an input, or spurious data/clocks could have been sent to the card, getting it into an undesired state. Also make sure that the mechanism by which the SD library accomplishes required delays hasn't been broken or accelerated. \$\endgroup\$
    – Chris Stratton
    Commented Oct 11, 2012 at 13:40
  • 3
    \$\begingroup\$ You may be having noise or power supply problems, too. Check your rails with a scope and check the SD lines with a logic analyzer to see what's going on. \$\endgroup\$
    – Jim Paris
    Commented Oct 11, 2012 at 21:46

1 Answer 1

Reset to default
1
\$\begingroup\$

I had a problem like that with USART and resolved it by changing the watch dog settings. As you know V-USB uses a watch dog and if you put extra time in one operation, the watch dog gets activated. Try deactivating the watch dog and if you see everything goes well, you can change the watch dog time or you can split the interfering code (the SD card codes in your case) into smaller parts and "Resetting" the watch dog between them. But don't forget to re-activate your watch dog after debugging as it is not recommended to use V-USB without that.

\$\endgroup\$
2
  • \$\begingroup\$ Note that the question mentions having wdt_reset() calls inserted into the SD code; though of course it's possible that this was not done everywhere. \$\endgroup\$
    – Chris Stratton
    Commented Sep 10, 2013 at 22:00
  • 1
    \$\begingroup\$ Yes but it is really worth to try the code with disabling the watch dog. Sometimes especially when the returning data is processed in an interrupt routine, the code gets stuck there and the watch dog gets activated before being reset \$\endgroup\$
    – Aug
    Commented Sep 10, 2013 at 22:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.