기술자료

TI E2E 포럼의 TMS320F28027F 사례를 정리합니다. LaunchPad에서 플래시 소거(Erase)와 잠금 해제(Unlock)가 모두 실패해 CSM 영구 잠김이 의심되는데, MCU를 한 번 교체한 뒤에도 새 칩이 한 번 프로그래밍된 후 똑같이 잠겼다는 질문(스레드 #1688509)과 이에 대한 TI의 진단 내용입니다.

이 스레드는 2026년 10월 23일 현재 TI의 답변이 등록된 상태이며 질문자의 전원 측정 결과 회신은 아직 올라오지 않았습니다. 확인된 사실과 TI의 추정 가설을 구분해서 적었습니다.

1. 포럼 질문자의 상황과 이력

LaunchPad에서 플래시를 지우지도 쓰지도 못하는데 연결과 정지, 메모리 읽기는 모두 정상 동작하는 사례입니다. 질문자의 개발 환경과 경과는 다음과 같습니다.

- 디바이스: TMS320F28027F (48핀 LQFP), LAUNCHXL-F28027F, 온보드 XDS100v2

- 환경: CCS 12.3.0, Windows 11, MotorWare(instaSPIN-FOC) proj_lab01

- 증상: 빌드와 링크는 정상이나 On-Chip Flash 패널의 Erase Flash와 Unlock이 모두 오류 발생. 연결, 정지, 메모리 읽기는 정상

- 재현성: 빈 proj_lab01 프로젝트로도 동일하게 재현되며, 다른 LaunchPad 보드는 정상 동작

- 이력: 문제가 발생한 보드에서 MCU를 한 번 교체했으나, 새 칩도 한 번 정상적으로 프로그래밍된 뒤 같은 방식으로 실패

2. 질문자가 측정한 레지스터와 근거

질문자는 단순 추측이 아니라 레지스터와 빌드 산출물로 상태를 확인했습니다.

- CSMSCR(0x0AEF) = 0x004F: SECURE 비트(bit 0)가 1로, 현재 CSM이 잠긴 상태입니다.

- CSM 보호 플래시 영역 읽기 결과: 0x3F7FF6, 0x3F7FF8 등 보호 영역을 읽으면 전부 0x0000이 반환됩니다. 같은 세션에서 RAM과 부트 ROM은 정상값이 읽힙니다. 지워진 플래시는 0xFFFF로 읽혀야 하므로 CSM이 읽기를 가로채고 있다는 뜻입니다.

- 기본 해제 시퀀스 실패: CCS는 접속할 때마다 비밀번호 위치를 더미 리드(dummy read)한 뒤 CSMKEY0~7에 0xFFFF를 쓰는 기본 해제 시퀀스를 실행합니다. 그런데도 SECURE 비트가 풀리지 않으므로 비밀번호가 기본값(0xFFFF…)이 아닙니다.

- 링커 맵 및 헥사 파일 확인: 애플리케이션은 비밀번호 영역을 쓰지 않습니다. 링커 맵의 CSM_PWL_P0 사용량이 0이고, hex2000 -a 결과에도 0x3F7F80~0x3F7FFF 구간 레코드가 없습니다.

- JTAG 연결 상태: JTAG 스캔 체인 점검과 USB 열거는 정상으로, 프로브나 케이블 문제는 아닙니다.

읽는 법: "플래시를 읽었더니 전부 0x0000"은 그 자체로는 "비밀번호가 0이다"를 뜻하지 않습니다. CSM이 잠긴 동안에는 보호 영역 읽기가 항상 0을 돌려주기 때문입니다. 이 값이 알려 주는 것은 "지금 잠겨 있다" 뿐입니다.

3. TI의 진단: 영구 잠금 여부와 복구 경로

TI는 질문자의 세 가지 질문에 다음과 같이 답했습니다.

1) 영구 잠금인가?

제시된 증거와 일치한다고 답했습니다. 다만 읽기값 0x0000만으로는 비밀번호가 0임을 증명하지 못하고, 증명되는 것은 비밀번호가 0xFFFF가 아니라는 것까지라고 덧붙였습니다. 어느 쪽이든 비밀번호를 모르면 풀 수 없다는 결론은 같습니다.

2) 남은 복구 경로는?

- 더미 리드 + 알려진 128비트 비밀번호를 KEY0~7에 쓰기: 알려진 0이 아닌 비밀번호가 있을 때만 가능합니다.

- 플래시/OTP에 미리 심어 둔 소거 루틴을 보안 SARAM에서 실행: 잠기기 전에 그런 펌웨어를 미리 넣어 둔 경우만 가능합니다.

- Wait Boot 모드: 진단용입니다. 연결 문제와 잠금을 구분할 수 있을 뿐, 잠긴 부품을 되살리지는 못합니다. F2802x는 하드웨어 wait-in-reset을 지원하지 않습니다.

- 비밀번호를 모른 채 JTAG으로 해제: 불가능합니다.

비밀번호 영역이 소거·프로그램 중 손상된 경우 TI가 문서로 밝힌 결과는 "복구 불가, 현실적인 대응은 MCU 교체"입니다.

3) 비밀번호 위치가 0xFFFF가 아니게 되는 원인은?

애플리케이션이 직접 쓴 경우 외에 TI가 짚은 원인은 하나입니다. 정전, 브라운아웃, 타깃 전류 부족으로 소거/프로그램이 중간에 끊긴 경우 비밀번호 영역이 손상되어 영구 잠김이 될 수 있다는 것입니다.

4. 핵심 대목: "칩이 아니라 보드"

TI가 마지막으로 강조한 부분입니다.

칩을 한 번 교체했고, 새 칩이 한 번은 프로그래밍된 뒤 똑같이 실패했다. 같은 보드에서 독립된 두 칩이 같은 방식으로 죽었다면 실리콘보다 보드를 의심해야 한다. 증거로 확인되는 손상 메커니즘은 플래시 작업 중 전원이 부족하거나 불안정해서 소거/프로그램이 중단된 경우뿐이다.

그리고 질문자가 근거로 든 "XRSn = 3.3V, 리셋 해제됨"이라는 DMM 정적 측정은 이 가능성을 배제하지 못한다고 설명했습니다. 플래시 소거·프로그램 순간에는 전류가 순간적으로 크게 흐르기 때문에, 평소 DMM에 3.3V로 찍히는 레일도 그 순간에는 떨어질 수 있습니다. TI의 권고는 다음과 같습니다.

- 플래시 소거/프로그램을 하는 동안 오실로스코프로 VDD와 VDD3VFL을 확인합니다.

- 전원 특성을 확인하기 전에 세 번째 칩으로 교체하면 같은 결과가 반복될 위험이 있습니다.

읽을 때 주의할 점: 여기까지가 TI의 추정입니다. 질문자는 아직 전원 측정 결과를 올리지 않았고, 따라서 원인이 정말 전원인지는 이 시점에 확인되지 않았습니다. "전원이 원인"이라고 단정하지 마시고 "가장 먼저 확인할 가설"로 읽어 주시기 바랍니다.

5. 실무 체크리스트

이 스레드 내용과 TI의 설명을 바탕으로 정리한 순서입니다(체크 2의 세부 전원 경로 점검은 실무 차원에서 덧붙인 항목이며, 나머지는 스레드에서 확인된 내용에 근거합니다).

체크 1. 잠긴 것 같을 때 먼저 확인할 것

- CSMSCR의 SECURE 비트를 읽습니다. 1이면 잠긴 상태입니다.

- 보호 플래시 영역이 0xFFFF가 아니라 0x0000으로 읽히면 CSM이 가로채는 중입니다. 이 값으로 비밀번호를 추측하지 마십시오.

- 비밀번호를 알고 있다면 더미 리드 후 KEY0~7에 쓰는 방법으로 해제를 시도합니다. 모르면 JTAG만으로는 해제할 수 없습니다.

- 부품을 버리기 전에 Wait Boot 모드로 연결 문제와 잠금을 구분해 봅니다(진단용입니다).

체크 2. 같은 보드에서 두 번 이상 같은 증상이 나올 때

- 칩을 또 교체하기 전에 플래시 소거/프로그램 구간의 VDD, VDD3VFL 파형을 스코프로 봅니다. 정적 DMM 값은 근거가 되지 못합니다.

- LaunchPad라면 USB 전원 경로, 보드에 얹은 부하, 프로그래밍 중 전류 여유를 의심합니다. 자체 보드라면 레귤레이터의 순간 전류 용량과 디커플링을 봅니다.

- 프로그래밍 중에 USB 케이블을 건드리거나 전원이 흔들릴 가능성을 줄입니다(허브 대신 본체 직결 포트 등).

체크 3. 양산·검증 단계의 예방

- 양산·검증 라인에서는 프로그래밍 도중 전원이 끊기지 않도록 하는 것이 가장 중요합니다. 소거/프로그램 중단은 비밀번호 영역을 손상시킬 수 있다는 것이 TI의 설명입니다.

- 필요하다면 잠기기 전에 플래시를 소거할 수 있는 루틴을 보안 SARAM에서 돌릴 수 있게 설계해 두는 방법이 있습니다(TI가 언급한 경로이며, 구체적 구현은 TI 문서를 확인하셔야 합니다).

6. 핵심 요약

1) 보호 플래시가 0x0000으로 읽히고 SECURE 비트가 1이면 잠긴 상태입니다. 읽은 값으로 비밀번호를 추측할 수는 없습니다.

2) 비밀번호를 모르면 JTAG만으로는 해제할 수 없고, 복구 경로는 사전에 준비된 경우뿐입니다.

3) TI가 짚은 손상 원인은 소거/프로그램 중 전원 불량으로 인한 중단입니다.

4) 같은 보드에서 두 칩이 같은 방식으로 죽으면 칩보다 보드를 의심하십시오.

5) 세 번째 칩을 얹기 전에 프로그래밍 구간의 VDD, VDD3VFL을 스코프로 보십시오. 정적 DMM 측정은 근거가 되지 못합니다.

칩을 바꾸기 전에, 칩이 죽는 순간의 전원을 먼저 확인하시기 바랍니다. 스레드에 후속 측정 결과가 올라오면 이어서 정리하겠습니다.

원문(출처) : TI E2E 커뮤니티 https://e2e.ti.com/thread/1688509