이것은大象嵌入式(Daxiang Embedded) S32K144의 회로도입니다. 현재 문제는 프로그램이 실행되지 않고 flash가 계속 비어 있다는 것입니다. 리셋 버튼을 놓았을 때 RESET의 대지 전압이 1V인데, 이는 분명히 정상적인 값이 아닙니다.
판매자는 칩이 잠겼다고 말하며 RESET에서 출력이 나온다고 했는데, 아래는 RESET 대지 파형입니다.
하지만 제가 GPT에 프로그래밍 과정을 한 번 실행해 보게 했더니, 칩은 잠기지 않았고 flash에는 기록할 수 있지만 곧바로 지워진다고 말했습니다.
제가 전체 과정을 모두 GPT에 제공했을 때 GPT가 내린 설명은 이렇습니다: 칩의 리셋 루프는 워치독이 아니라 LOCKUP 리셋입니다. 빈 flash 상태의 CPU가 0xFFFFFFFE에서 명령어를 가져오고 → 버스 오류 발생 → HardFault(핸들러 역시 0xFFFFFFFE에 있음) → 재귀 → LOCKUP → 리셋 → 다시 반복되며, 주기는 수백 마이크로초입니다.
하지만 제시된 해결책은 하나도 효과가 없었습니다. 고수분들, 이 문제를 해결하는 방법을 아시나요?
IO 리셋이 반복적으로 LOW로 당겨지나요? 플래싱한 프로그램에서 PTA5(RST) IO를 사용하면서 소프트웨어적으로 해당 IO를 LOW로 만들고, 소프트웨어상에서 이 IO의 리셋 기능을 비활성화하지 않았기 때문에 계속 리셋되어 재시작되는 것은 아닌지 확인해 보세요. 정상적인 예제 프로그램을 다시 플래싱해서 테스트해 보세요.
이 1V RESET 전압은 확실히 문제가 있습니다. 정상적으로는 리셋 버튼을 놓으면 RESET이 내부 풀업이나 외부 풀업 저항에 의해 VCC(3.3V)에 가까운 전압으로 올라가야 합니다. 1V라는 것은 풀업이 너무 약하거나, 칩 내부에서 리셋을 계속 낮게 끌어당기고 있다는 뜻입니다.
회로도를 보면 R7 2.2k 풀업은 충분히 강해야 하지만, S32K144의 RESET 핀은 양방향이라는 점을 주의해야 합니다. 즉 칩이 직접 리셋을 낮게 끌어당길 수도 있습니다. 정말로 LOCKUP 루프라면 칩이 수백 마이크로초마다 스스로 한 번씩 리셋할 것이고, 오실로스코프에서 보이는 1.64kHz 톱니파가 바로 그것일 가능성이 큽니다.
먼저 몇 가지를 확인해 보세요.
-
R7 양단 전압을 측정해서, 풀업 저항이 실제로 VCC_MCU에 연결되어 있고 전압이 정상인지 확인하세요. 가끔 개발보드 전원이 헐떡이거나 LDO 출력이 불안정하면 풀업 전압이 충분하지 않을 수 있습니다.
-
리셋 버튼을 분리한 뒤, RESET 핀을 점퍼로 직접 VCC에 연결해서 프로그램이 실행되는지 확인하세요. 실행된다면 문제는 리셋 회로에 있는 것이고, 그래도 안 되면 리셋 회로 문제는 배제할 수 있습니다.
-
J-Link나 PE 디버거로 직접 연결해 보세요. 온보드 OpenSDA를 거치지 말고요. 칩 ID를 인식할 수 있는지 확인하세요. 가끔 온보드 디버거가 리셋에 간섭을 일으키기도 합니다.
-
VDDA와 VREFH를 확인하세요. S32K144의 아날로그 전원이 연결되지 않았거나 불안정하면 이상한 리셋 동작이 나타날 수 있습니다.
GPT가 말한 LOCKUP 루프에 대해서는 논리적으로 맞는 말입니다. 빈 플래시는 실제로 그렇게 동작합니다. 하지만 핵심은 왜 플래시가 비었는가입니다. 프로그래머가 쓰지 못한 것인지, 썼다가 다시 지워진 것인지요? J-Flash나 S32 Design Studio로 칩에 직접 연결해 플래시 내용이 실제로 무엇인지 확인해 보기를 권합니다. 플래시가 정말 전부 FF라면 가장 간단한 blink 프로그램을 먼저 써 넣고 실행되는지 확인하세요. 실행된다면 칩이 잠긴 것이 아니라 프로그래밍 절차 문제이고, 그래도 안 되면 칩이 손상되었거나 잠겼는지를 고려해야 합니다.
GPT의 설명은 실제로 정확합니다. S32K144에서 플래시가 비어 있으면 잘못된 주소에서 fetch가 발생해 HardFault가 나고, 이는 Lockup으로 이어진 뒤 시스템 리셋이 발생합니다. MCU가 리셋 핀을 능동적으로 낮게 구동하고 있기 때문에 보이는 1.64kHz 톱니파형이 나타나는 것입니다. 이를 해결하려면 "Connect under reset"을 지원하는 디버거가 필요합니다. J-Link를 사용 중이라면 J-Link Commander를 열고 unlock kinetis 명령을 실행해 보세요. 이 명령은 코어가 잘못된 명령어를 실행하려고 시도하기 전에 코어를 정지시킵니다.
같은 보드에서 저도 지난달에 똑같이 겪었습니다. GPT 분석이 꽤 정확한데요, LOCKUP 루프가 맞습니다. 다만 리셋 파형에 너무 끌려가지는 마세요.
제가 당시에 해결한 방법은 이렇습니다: 플래시할 때 리셋 버튼을 손으로 누른 채로 있다가, Download를 누른 직후 바로 손을 떼는 것입니다. 칩이 리셋에서 풀려나기 전에 코드가 들어가도록 하는 방식이죠. LOCKUP 루프에 들어가면 SWD 타이밍이 엉망이 되어서, 디버거는 쓰기가 성공한 것처럼 보이지만 실제로는 전혀 쓰이지 않습니다. 나중에 다시 읽어보면 전부 0xFF라서 마치 “지워진” 것처럼 보입니다.
또한 부팅 파일이 S32K144 전용인지 확인해 보세요. STM32에서 포팅한 코드라면 벡터 테이블 위치나 링크 스크립트가 맞지 않을 수 있습니다. S32K144의 Flash 시작 주소는 0x0000_0000이지만, 벡터 테이블에는 반드시 유효한 초기 SP와 Reset_Handler가 포함되어 있어야 합니다. 이 두 값이 0xFFFFFFFF이면 칩이 리셋에서 풀리는 즉시 HardFault에 들어갑니다.
그리고 3.3V가 안정적인지도 측정해 보세요. 이 보드는 USB 전원으로 구동할 때 가끔 전류가 부족해서, 전압이 2.8V 이하로 떨어지면 Flash 쓰기가 조용히 실패합니다. 그러면 역시 "플래시가 안 된다"는 증상이 나옵니다. 더 짧은 USB 케이블로 바꿔보거나 외부 5V를 연결해 보세요.
새 보드인가요? 펌웨어가 없어서 계속 리셋되는 것일 수도 있습니다.
저도 예전에 ESP32S3를 사용할 때 그랬는데, 새 모듈의 flash가 비어 있으면 계속 리셋이 발생합니다. ESP32의 해결 방법은 BOOT 버튼을 누른 상태에서 전원을 넣어 플래시 모드(烧录 모드)로 진입하는 것입니다.
상사가 준 건데, 한 번도 써본 적이 없다고 하네요
공식 예제를 사용했는데 PTA5가 구성되지 않은 것 같습니다.
시도해 봤습니다. kinetis 잠금 해제는 가능했지만, flash에는 여전히 쓸 수 없었습니다. 아니면 써도 다시 지워지는 것 같았습니다.
고마워요, 내일 아침에 한번 시도해 볼게요.