2010-11-28 2 views
4

ST 마이크로 일렉트로닉스 STM32F103VE 마이크로 컨트롤러를 기반으로하는 맞춤형 보드가 있으며, 마이크로 컨트롤러의 SDIO 버스에 MiniSD 카드가 연결되어 있습니다. 전기 연결은 정확히 STM3210E-EVAL board schematics에서 확인한대로 이루어졌으며 다시 확인되었으므로 정확하다는 확신이 들었습니다. 불행히도 내가 겪고있는 것이 하드웨어 문제인지 테스트하기위한 평가 보드가 없지만 그렇게 보이지는 않습니다. 아래의 테스트에서 저는 최근에 구입 한 Kingston 2GB MicroSD 카드 (모델명 MBLYG2/2GB)를 사용하여 MiniSD 어댑터에 제공된 MicroSD를 사용하여 최신 SD 카드 사양을 준수해야합니다. 아직 다른 카드로 테스트하지 않았습니다.CRC 실패로 인해 SDIO 버스 초기화 문제가 발생했습니다.

나는 무슨 일이 일어나고 있는지 이해하기 위해 SD 카드의 물리적 레이어 단순화 된 사양을 따르고 있습니다. 사용중인 코드는이 마이크로 컨트롤러를위한 ST Micro의 표준 주변 장치 라이브러리와 함께 제공되는 예제 SDIO 코드입니다. 그것은 CMD0 (GO_IDLE_STATE), CMD8 (SEND_IF_COND), 그리고 나서 ACMD41 (SD_SEND_OP_COND)를 전송함으로써 시작된다. 이것은 CMD55 (APP_CMD) 다음에 CMD41을 전송함으로써 이루어진다. 클럭 라인은 400kHz로 클럭되며 디버깅 작업의 일부로 CMD0과 CMD8 사이에 약 100 클럭 사이클의 지연을 추가했습니다. SPI에서 작동 할 때 적어도 필자는 어딘가 읽었습니다. 방법. 아래에 언급 된 수정 외에도 코드는 예제 코드와 정확히 동일합니다.

처음 예제 코드를 실행하려고했을 때, CMD55는 마이크로 컨트롤러가 CMD8에 대한 응답을 버퍼링했기 때문에 발생했지만 CMD55에 대한 응답을 확인할 때 샘플 코드가 CMD8의 응답을 검색하지 못하기 때문에 발생했습니다. , 코드는 실제로 CMD8에 대한 응답을보고 그것에 의해 화가났습니다. 필자는 CMD55를 전송하기 전에 마이크로 컨트롤러의 SDIO 주변 장치에서 CMDREND 플래그를 지움으로써이 문제를 해결했다. 따라서 코드가 CMD55에 대한 응답을 체크했을 때 더 이상 CMD8의 응답을 버퍼링하지 않았다.

다음 문제와 내가 현재 고집하고있는 것은 CMD55에 대한 응답에서 카드 상태 필드 (COM_CRC_ERROR)의 23 번째 비트가 설정되어 있으며 이는 이전 명령의 CRC 검사가 실패했음을 나타냅니다 사양에. 마이크로 컨트롤러가 자동으로 CRC를 계산하지만 논리 분석기를 회로에 연결하여 올바른지 확인했습니다. 난 웹 애플 리케이션을 사용하고 있습니다 (미안 해요, 내가 새로운 사용자이기 때문에 연결할 수 없습니다,하지만 "CRC ghsi"에 대한 Google이고 첫 번째 결과입니다) 다항식 x^7 + x ^를 사용하여 CRC를 검증합니다. 3 + 1 사양에 따라. 이것은 나에 의해 포맷 및 주석 로직 분석기 출력입니다 :

// uC sends CMD0, CRC OK, no response: 
01 000000 00000000000000000000000000000000 1001010 1 
// uC sends CMD8, CRC OK, check byte = 0xAA: 
01 001000 00000000000000000000000110101010 1000011 1 
// SD card responds to CMD8, CRC OK, check byte echoed back = 0xAA: 
00 001000 00000000000000000000000110101010 0001001 1 
// uC sends CMD55, CRC OK: 
01 110111 00000000000000000000000000000000 0110010 1 
// SD card responds to CMD55, CRC OK, note card status bits 23, 8 and 5 set; 
// bit 23 = COM_CRC_ERROR, bit 8 = READY_FOR_DATA and bit 5 = APP_CMD: 
00 110111 00000000100000000000000100100000 0000100 1 

이 또한 내가 CMD55에게 교환이 위의 비트 직후 두 번째로 시도하는 경우 (23) 설정 해제 참고 :

// uC sends CMD55, CRC OK: 
01 110111 00000000000000000000000000000000 0110010 1 
// SD card responds to CMD55, CRC OK, bits 8 and 5 still set but 23 not set: 
00 110111 00000000000000000000000100100000 1000001 1 

주를이 CMD55를 보내기 전에 CMD8을 두 번 보내려고했지만 아무런 차이가 없었습니다. 첫 번째 CMD55는 항상 비트 23을 반환합니다. 시도 할 때마다 이것을 재현 할 수 있기 때문에 고장이나 잡음이있는 문제는 아니라고 생각합니다. CRC는 마이크로 컨트롤러 자체로 계산되므로 외부 엔티티 (로직 애널라이저)에서 볼 수있는 것처럼 보이며 위에서 언급 한 웹 사이트에서 확인되었으므로 카드의 CRC 검사가 실패 할 수 있음을 알 수 없습니다.

어떻게 든 예상 되나요? 어쩌면 나는 각 명령 사이에 정해진 수의 클럭 사이클을 기다려야한다. (어딘가에 8 사이클이어야한다는 것을 읽고, 나는 그것을 존중한다고 생각한다)? 첫 번째 CMD55가 실패하고 방해가된다면 두 번째 CMD55를 보낼 수 있습니까? 아니면 부작용이 있습니까? 문제가 해결 되더라도 CRC 검사가 실패한 이유를 알고 싶습니다. 잘못 입력했다고 생각하지 않습니다.

답변

3

문제점을 발견했습니다. CMD55가 올바른 응답을 읽을 수 있도록 CMD8 응답 버퍼를 플러시하도록 코드를 수정해야만 모든 로직 테스트가 회로에 연결되었습니다. 로직 애널라이저를 제거한 후, 코드가 작동하기 시작했습니다. 아마도 라인에 노이즈가 주입되었을 것입니다. 지연은 필요하지 않았지만 사양을 따르기 위해 CMD0보다 74 클록 사이클 지연이 더 걸렸다.

0

STM message boards을 확인하십시오.

AFAIK, 버그는 주변 라이브러리의 최신 버전 (3.4.0)에서 수정되었습니다.

+0

내 개발 환경에 바로 실행할 수있는 버전이 없기 때문에 버전 3.4.0을 아직 사용해 보지 못했지만 해결 될 수 있다고 언급 한 이후로 프로젝트를 만들 계획입니다. 하지만 코드의 관련 부분을 이미 살펴본 결과 내 문제와 관련이있는 변경 사항을 발견하지 못했습니다. – swineone