linguini1 commented on issue #16948: URL: https://github.com/apache/nuttx/issues/16948#issuecomment-3447855188
Based on [this handy decoding tool for the CSD register](https://archive.goughlui.com/static/csdecode2.htm), I think I found the issue. The contents of the response registers after CMD9 are: ``` [ 0.945000] bcm2711_recvlong: Resp 3: 00400e00 [ 0.950000] bcm2711_recvlong: Resp 2: 325b5900 [ 0.955000] bcm2711_recvlong: Resp 1: 00ee7f7f [ 0.959000] bcm2711_recvlong: Resp 0: 800a4040 ``` This gives a CSD of `00400e00325b590000ee7f7f800a4040`. However, [the blog of the person who originally wrote the decoder](https://goughlui.com/2014/01/03/project-read-collect-decode-sd-card-csd-register-data/) lists the CSD register of some similar devices. A similar Samsung 32gb card has `400e00325b590000e9e57f800a4040f1`. Astonishingly similar, although there are no two leading zeroes, and there is an additional trailing `f1`. When I used the decoder from this blog post, I get the same thing as NuttX. However, removing the leading two zeroes, I get the correct device size as 32gb from the parser, just an undefined CRC (which happens to be the trailing two bits). I have two guesses: 1. Something is wrong with the timing on receiving response, such that we're missing the trailing byte each time, and the controller uses a shift register under the hood, hence why there is 00 at the front of the response. 2. Maybe enabling the CRC check for this command will add the CRC at the end. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
