Stlink: STM32L052K8로 플래시를 시도하면 플래시 메모리가 손상됨

그것은 이상한 문제입니다. 문제의 원인을 즉시 알 수 없었습니다. L1 로더는 거의 동일하기 때문에 L0 칩과 호환됩니다.

조금 이상해 보입니다. 디버그 플래그가 있거나 더 많은 정보를 제공하기 위해 켜야 할 것이 있는지 알려주세요.

엘프가 아닌 st-flash로 플랫 바이너리를 플래시 해보세요.

플래시를 파일로 다시 읽어서 비교하거나 gdb 또는 예제로 검사 해보십시오.
x / 32x 0x8000000

벡터 테이블의 시작이 표시되어야합니다.
바이너리는 어디에서 왔으며 그것이 좋은지 어떻게 알 수 있습니까?

또한 주소가 RAM에있는 것 같은 경우 BOOT 핀의 상태는 어떻습니까?

제가 살펴 보겠습니다. 어쨌든 디버거로 .elf를 업로드하는 대신 .bin 파일을 플래시하는 방법을 배우려고했습니다.

코드는 ST의 예 중 하나 였지만 벡터 테이블이있는 위치를 다시 살펴 보겠습니다.

BOOT0 핀은 접지되어 있으므로 RAM으로 부팅해야한다고 생각하지 않습니다.

이 질문에 대해 하루나 이틀 이내에 답변 해 드리겠습니다. 조언에 감사드립니다!

좋아, L0 테스트 프로그램 (특히 ST의 LSI 초기화 예)을 L031K6 Nucleo-32 보드에 플래시하려고했는데 제대로 작동합니다.

그러나 L051K8에서는 여전히 문제가 발생합니다. 가장 큰 차이점은 일반 USB 동글을 사용하여 L051K8 보드를 프로그래밍하고 온보드 ST-Link / V2-1 디버거를 L031K6 Nucleo 보드에 사용하고 있다는 것입니다. USB 디버거에서 펌웨어 업데이트를 시도했지만 도움이되지 않았습니다.

두 경우 모두 arm-eabi-none-nm 로 벡터 테이블이 올바르게 배치되었는지 확인했습니다. 08000000 R g_pfnVectors

st-flash write main.bin 0x08000000 를 사용하여 .bin 파일을 L051K8로 플래시하면 오류가 발생하지만 여전히 성공을보고합니다. 나중에 칩에 연결하면 프로그램이 0xFFFFFFFE에 고정되어 있음을 알 수 있습니다.

다음은 st-flash 의 출력입니다.

st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c: 
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!

하지만 ST의 GUI 유틸리티로 플래시 메모리를 살펴보면 0x08000000에서 시작하는 .bin 파일의 16 진수를 볼 수 있습니다. 프로그램 시작시 벡터 테이블처럼 보입니다. 그리고 기록 된 메모리는 0x080047E0에서 끝나는 것처럼 보이며 이는 프로그램 크기에 맞는 것 같습니다.

잘 모르겠습니다. 이것이 다른 사람이 복제 할 수있는 것이 아니라면 제가 사용하는 칩이나 보드 일 수 있다고 생각합니다.

안녕하세요,

블루 필 보드 (STM32F103C8X)와 동일한 문제
'arm-none-eabi-gdb'를 사용하는 모든 프로그램 후에 성공했고 프로그램은 보드에서 잘 실행되지만 다시 프로그래밍하려고하면 다음과 같은 문제가 발생했습니다.

st-util

[ abdullatif @ Host-001 ~] $ st-util
st-util 1.5.0
2018-05-04T23 : 47 : 27 정보 common.c : 장치 매개 변수로드 중 ....
2018-05-04T23 : 47 : 27 WARN common.c : 잘못된 플래시 유형, 장치 선언을 확인하십시오.
2018-05-04T23 : 47 : 27 정보 gdb-server.c : 칩 ID는 00000000, 코어 ID는 00000000입니다.
2018-05-04T23 : 47 : 27 정보 gdb-server.c : * : 4242에서 수신 중 ...
2018-05-04T23 : 47 : 40 정보 gdb-server.c : 0 hw 중단 점 레지스터를 찾았습니다.
2018-05-04T23 : 47 : 40 정보 gdb-server.c : GDB가 연결되었습니다.

gdb

[ abdullatif @ Host-001 빌드] $ arm-none-eabi-gdb Stm32blink.elf
GNU gdb (GDB) 8.1
저작권 (C) 2018 Free Software Foundation, Inc.
라이선스 GPLv3 + : GNU GPL 버전 3 이상 http://gnu.org/licenses/gpl.html
이것은 자유 소프트웨어입니다. 여러분은 자유롭게 변경하고 재배포 할 수 있습니다.
법이 허용하는 한 보증은 없습니다. "복사 표시"를 입력합니다.
자세한 내용은 "보증 표시"를 참조하십시오.
이 GDB는 "--host = x86_64-pc-linux-gnu --target = arm-none-eabi"로 구성되었습니다.
구성 세부 사항을 보려면 "show configuration"을 입력하십시오.
버그보고 지침은 다음을 참조하십시오.
http://www.gnu.org/software/gdb/bugs/
다음에서 온라인으로 GDB 설명서 및 기타 문서 리소스를 찾으십시오.
http://www.gnu.org/software/gdb/documentation/ .
도움말을 보려면 "help"를 입력하십시오.
"단어"와 관련된 명령을 검색하려면 "apropos word"를 입력하십시오 ...
Stm32blink.elf에서 기호 읽기 ... 완료.
(gdb) 대상 확장 원격 : 4242
: 4242를 사용한 원격 디버깅
0x00000000 in ?? ()
(gdb) 부하
로딩 섹션 .isr_vector, 크기 0x10c lma 0x8000000
로드 실패
(gdb)

보드가 다시 작동하려면 'st-flash'로 부트 로더를 플래시해야합니다.

나는 F103 문제가 내가 본 것과 동일하다고 확신하지 않습니다. 이 도구에서 상당히 잘 지원되는 것으로 보이며 L0 문제는 빈 칩에서도 발생합니다.

이 문제의 원래 제목이 잘못되었습니다. 죄송합니다. 다음 두 장치에서 동작이 발생합니다.

• STM32L052K8

• STM32L082KZ

나는 src/chipid.c 를보고 L0x1 및 L0x3 칩에 대한 참조 매뉴얼 만 설정에 참조되었음을 확인했습니다. L0x2 칩에 큰 차이점이 있습니까?

다음 diff는 STM32L052K8을 사용하여이 문제를 완전히 해결하는 것으로 보이지만 이상적인 솔루션이 아니라고 생각합니다.

diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
 }

 int stlink_erase_flash_mass(stlink_t *sl) {
-    if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+    if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
         /* erase each page */
         int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
         for (i = 0; i < num_pages; i++) {

이 변경 사항은 ID 0x0417 와 연관된 일반 L0x3 레이블로 식별되는 칩에서 대량 지우기에 대한 L0 특정 동작을 제거합니다.

L0 -특정 논리가 이러한 'Category-3' L0x2 칩에 문제를 일으키는 이유를 모르겠습니다. STM32L031 Nucleo 보드에서 잘 작동하는 것 같습니다. 여기서 칩의 ID는 'Category-2'장치로 식별되는 0x0425 입니다.

STM32L151CC와 유사한 문제가 있습니다.
동일한 오류가 발생하고 확인 단계에서 실패합니다.
ST-Link 유틸리티를 사용하여 수동으로 메모리를 확인하면 플래시가 올바르게 기록 된 것으로 표시됩니다.
장치에 읽기 / 쓰기 보호가 설정되어 있지 않습니다.

st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c: 
write_half_pages failed == -1
 55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

@WRansohoff : 릴리스 v1.5.1에 ​​문제가 여전히 존재하는지 확인하십시오.

물론입니다. STM32L0 카테고리 2 칩에서도 이러한 현상이 계속 발생하는지 확인합니다.

하지만 대부분의 보드는 스토리지 ATM에 있으므로 5 월에 이사를 마칠 때까지 할 수 없을 것입니다. 미안합니다.

@WRansohoff : 이것에 대한 업데이트가 있습니까?

안녕하세요, STM32L433RC와 동일한 문제가 있습니다.
st-util 1.6.1을 사용하고 있습니다.

MCU의 플래시를 지우십시오.
이 기사 사용 : https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming

STM32Cube에서 SWD / JTAG 핀을 표시하는 것을 잊었을 수 있습니다.