MDSTECH

• 문제점 및 증상
  
  

Q사의 MPU(Memory Protection Unit)기능을 이용하여 Code영역에 불법적으로 Write될 때 Data abort를 발생시켜 문제점을 찾을 수 있습니다. TRACE32에서 Soft Breakpoint는 여러 개 사용할 수 있지만 Code Protection되어 있는 부분, 즉 Read Only 부분은 Onchip Breakpoint를 2개만 설정 가능하기 때문에, Soft Breakpoint로 해서 여러 곳을 설정할 수 있게 하기 위해서는 Code Protection을 해제해야 합니다. 그러나 Code Protection을 하자니, TRACE32에서 Breakpoint를 2개 이상 사용할 수 없어 불편하고 Code Protection을 해제하자니, Code의 비정상적인 Write 접근을 감지할 수 없었습니다.

 
• TRACE32 접근방법(디버깅)
  
  

이러한 진퇴양난의 문제점을 TRACE32의 Command와 CMM을 이용, 3줄을 추가하여 해결하였습니다.

d.s (address.offset(cust_mem_map)+0xC) %long 0xC18//Code Protection 해제 부분

      b.s 0x00000000--0x01ffffff /write             //Code 영역 Range Breakpoint설정 1
      b.s 0x02000000--0x021fffff /write             //Code 영역 Range Breakpoint설정 2


TRACE32에서 위의 Command를 수행하면 Code Protection을 해제하기 때문에 여러 개의 Soft Breakpoint를 설정할 수 있고, 설정된 Range Breakpoint로 인하여 비정상적인 Write access도 감지해낼 수 있습니다.



위에서 “d.s (address.offset(cust_mem_map)+0xC) %long 0xC18” 부분은 Code Protection 부분을 해제함으로써, Soft Breakpoint 여러 개를 걸 수 있도록 한 것입니다. Cust_mem_map은 1M 단위의 Memory Map 공간에 MMU 특성을 부여하는 테이블입니다. 이 전역변수에서 0xC 만큼 떨어진 위치에 Code 영역의 Access 특성을 결정하는 값이 있습니다. 이 값을 0xC18로 설정함으로써 Code Protection을 해제합니다.


이렇게 될 경우 디버깅할 때 Code Protection이 해제되기 때문에 코드 부분을 침범하는 곳을 찾을 수가 없게 됩니다. 그래서 “b.s 0x00000000--0x01ffffff /write” 와 “b.s 0x02000000--0x021fffff /write” 가 필요하게 됩니다. 이 영역은 메모리 0x0에서 0x021fffff 사이의 범위를 침범하는 부분을 찾아낼 수 있도록 한 것입니다. 0x0에서 0x021fffff까지의 범위는 하나의 예로서 Code가 존재하는 부분입니다. 이 부분에 비정상적인 Write Access를 하면 TRACE32는 멈추게 되어 디버깅 할 수 있도록 합니다. 이 기능을 사용하여 Const data에 Write하는 코드와 Null point에 Write 하는 코드를 발견하여 수정할 수 있었습니다.



아래 그림은 위의 3줄을 삽입하여 여러 개의 SW Breakpoint를 설정한 예와 Range Breakpoint를 사용하여 비정상적인 Write Access를 TRACE32가 감지하여 Stop 시킨 것에 관한 것입니다. 왼쪽 창을 보시면 코드 전체에 빨간 표시가 되어 있는 것을 볼 수 있는데 코드 전체에 Write Access Breakpoint가 설정되었다는 것을 알 수 있습니다.

• 결론
  
  
  위에서도 언급했듯이 Code나 RO data가 Write Access 되어 그 값이 변경되었다는 것은 심각한 경우입니다. 그 증상 또한 다양할 수 있습니다. 즉, Data abort가 발생하거나 Prefetch abort가 발생할 수도 있고 그냥 Reset 될 수도 있습니다.
  
  
  Const data가 변경되어 UI에서 글자가 제대로 출력되지 못한 경우도 있었습니다. Null Point에 값을 대입함으로써, Vector table이 망가지기도 했습니다. 아주 엄한 Code가 깨져서 Data abort가 발생하기도 했었습니다.
  
  
  이러한 문제점을 TRACE32의 Range Breakpoint를 사용하여 쉽게 Error 위치를 찾을 수 있었고, 해결할 수 있었습니다. 그냥 간단한 2줄 정도를 CMM에 넣는 것에 비해 그 효과는 엄청났던 것이죠. 이러한 디버깅이 가능하다는 것을 다른 팀에서도 확인을 하고 기존에는 Logging에 의존한 디버깅을 했었는데, Critical한 Error인 경우는 TRACE32를 사용하기 시작했습니다.
  
  
  추가적인 유용한 경험으로는 폰 Halt에 대한 디버깅인데 폰의 Halt를 일컬어 Lock up 걸렸을 때입니다. TRACE32의 Attach 기능을 알기 전에는 폰 Halt된 경우에 그야말로 속수무책이었습니다. 특정 부분에서 Halt된 것이기에 심증은 있으나 정확한 물증이 없었던 것이죠. 이 또한 폰 통화 종료 후 간헐적으로 Halt 된 경우도 있었습니다.
  
  
  이 때 TRACE32를 사용하여 Attach top 시킨 다음에 Halt에 대한 디버깅을 할 수 있었습니다. 결국 MMU 특정 부분, 특정 조건에서 이러한 경우가 발생하는 것을 찾을 수 있었고, 이 문제점은 해결되었습니다. 이러한 기능들은 그야말로 실무에서 Critical Error를 잡기 위한 유용한 디버깅 기능이었습니다.