요 근래, 파일 시스템 테스트 하다가 안되서 고생고생 했네요.
그 고생한 내용은 다음과 같습니다.
파일 관련 함수는 거의 다 테스트를 했는데, f_read() 함수만 유독 실행이 될 때도 있고,
어떤 때는 계속 실행이 안되고 Hardfault Error 인터럽트로 점프해서 멈춰 있었습니다.
같은(거의 비슷한?) 입력 파라메터를 갖고 있는 f_write() 함수는 또 잘 된다.
FRESULT f_read (FIL* fp, void* buff, UINT btr, UINT* br); /* Read data from a file */
FRESULT f_write (FIL* fp, const void* buff, UINT btw, UINT* bw); /* Write data to a file */
하~.., 그래서 사용자 함수를 하나 만들어서 파라메터를 f_read() 와 같이 정의를 해서 테스트를 해보니 f_read()함수와 같은 증상이 발생. ㅜㅜ
안되는 원인을 찾아 보려고 f_read()함수의 파라메터의 입력을 각각 1가지씩 사용자 함수에 적용해서 테스트를 해 봤더니,
입력 인자 중 void* buff 가 문제였습니다.
원인은 입력 인자인 배열(void *buff)을 f_write()에서 보다 많이 잡아서 Stack overflow 가 걸리는 것이었습니다.
에러가 나면 스택 오버플로우 인지 확인도 못하고(혹시 아시는 분 있으시면 방법을 알려 주시면 감사하겠습니다),
그냥 프로그램이 멈춰버리니.. 며칠을 밤새고 나서야 찾을 수 있었습니다.
이번 글의 요점은, 파일 시스템 관련 함수를 사용할 경우에는 스텍을 충분히 확보하라 입니다.
그럼, 다음은 스텍을 늘리는 방법입니다. 방법은 2가지가 있네요.
1. startup_stm32f411xe.s 파일을 열어서 다음과 같이 스택 사이즈를 변경합니다.
2. CUBE 툴에서 project > Setting 메뉴에서 수정할 수도 있습니다. (저는 큐브 툴로 KEIL 소스를 만들어서 이런 방법도 있음을 알려 드립니다)
스택이 0x400 일 때 멈춰버린 프로그램이..
스택을 0x800 으로 고치니까 아주 잘 됩니다. 잘 되서 f_lseek()함수도 사용해서 파일의 offset를 막 이동해 가면서 읽어서 UART로 마구마구 뿌려 댔습니다. ^^
그런데, 나중에 알게된 사실인데...
큐브 툴의 Help 메뉴를 누르면 UM1718.pdf 파일이 열리는데, 이 곳의 7번의 제목의 글에 스택을 충분이 할당하라는 내용이 약간 나옵니다. ㅜㅜ 저와 같은 문제로 고생하는 사람이 많진 않지만 약간 있나 봅니다.
많았으면 반드시 스택을 많이 잡고 시작하라고 했을 텐데.
그리고 이 PDF의 파일 시스템 예제가 인터넷에 돌아다니는 예제 보다, 가장 잘 나온 것 같습니다.
참고하시면 도움이 될 것 같습니다.
댓글 없음:
댓글 쓰기