I have recently started investigating issues on a custom product that uses the DM385 and have a board that starts to boot off the SD card, but for some reason terminates. I am working this effort after the initial design and did not take part in that. I am also new to SD card protocols, so this has been a crash course for me. But it looks like I have made some progress to the point of having a few questions.
When the board is put in a BTMODE to boot off the SD Card, I can see the continuous "C" characters on the console. When 2 versions of boot code on 2 different bootable SD cards are put into the board, the "C" characters disappear (presumably recognizing the SD cards). A card without the correct image displays the "C" character (or no SD card displays the "C"s). The card being used are SD XC I . It is my understanding that seeing the "C"'s on the console is a good thing, and implies all the clocks and power are OK. Is that correct?
So, I decided to look at the CMD lines to the SD card. When scoping out the CLK line with the CMD line and comparing them with the SPRUHG1 Technical manual, 16.3.3.2 Card Detection, Identification, and Selection Flowchart, I can follow the CMD lines (decoded at each CMDX interval) almost to the end. I see the following sequence; (CMD0, CMD8, CMD55, <CMD 41 and CMD55 repeat at least 30 times while card is busy>, CMD2, CMD3, CMD9, CMD4 . I am assuming I am following this chart correctly as the commands are in sequence compared to the chart, but it could be diverging from this.
1) According to the 16.3.3.2 FlowChart 16.34, everything looks good as far as CMD codes and flowchart are concerned. It makes sense to me the loop could take awhile while the SD Card is busy, and it does break out into CMD2 and CMD3. However, the flowchart indicates it should enter CMD7 and I am getting CMD9. I do not know what the CMD4 would be for after that. Can you explain what CMD9 and CMD4 could mean (as far as the SD card boot) and if this is significant?
2) This is the timing I captured, so it may have no bearing on any suggestions, but may provide some insight; On my scope I am able to capture (starting at the beginning of the CLK trains) the following; CLK goes low for 61us, then CLK has 3 sets of 340us pulses, CLK trains then are about 580us or longer, 31us CLK lows between the trains (presumably for response from SD card ??), and 4.16us clock cycles, ~175ms of CLK and CMD pulses appear upon startup, but no console information appears. See screenshots attached!
3)In order to capture the CMD bits, decode them into CMD numbers and follow the chart, I used only the CMD bits after the CLK line went low (31us). This may be a wrong presumption, but it appears to match the flow chart. So, presumably, the extra CMD bits (while the clock is running) are not used but I do not know why they are still changing if the CMD sequence is only 48 bits long. It looks like all the CLK trains are longer than 48 bits. I could not make sense of the CMD bits at the end of each CLK pulse train.
4) The SD cards are SD XC I which should be 3.0 compliant , but if the flowchart and CMD sequence I followed is correct, they were identified as standard 1.x cards. I do not know what this means, or if it could have an impact on the boot up sequence.
Specifically, if there are other lines I should be looking at and capturing to identify the boot up issue, please let me know!
Edit: Reading over the Physical Layer specification, it indicates the CMD9 and CMD4 affect the clock rate for data xfer, so I have added a 4th screenshot showing the end of the pulse trains (after CMD4). It appears there are 3 sets of higher clock rates but the CMD line just goes high after the 4th starts.
First Image shows initial clocking (yellow) followed by CMD start up (blue)
Second Image shows general clocking trains with low time and initial CMD0
Third image shows cursors on 6-bit CMD pulses. This image also shows the CMD9 I captured, where CMD7 was expected on boot sequence.
4th Image, per edit, shows end of pulse train, higher clocking but CMD goes high.