К1921ВГ015 перестал отлаживаться в Syntacore

[ZZZRF413]

Всем доброго дня!

Помогите пожалуйста по следующему вопросу: в Syntacore перестала запускаться отладка микроконтроллера К1921ВГ015.
Я на опробование купил отладочную плату BlueBird соответственно с микроконтроллером К1921ВГ015 и программатор BlueProg. В качестве среды разработки выбрал Syntacore IDE. Там все устанавливал по большей части руководствуясь документом "Быстрый старт с микроконтроллером К1921ВГ015 (версия от 16.07.2024г.)". Все настроилось и хорошо работало. Настраивал я на двух компьютерах: сначала на стационарном, где мне удалось помигать светодиодиком, а потом уже на ноутбуке, где я на этой плате (BlueBird) делал, на базе примера, и отлаживал свою тестовувую прошивкую. Я, нормально поработав день (все хорошо работало), на следующей день ничего не меняя запускаю отладку и получаю ошибку, которая далее уже не пропадает. Скриншот с ошибкой в приложении. Моя тестовая прошивка, на основе примера, в микроконтроллере целая - работает.

1.png (345.26 КБ) 1309 просмотров

Syntacore console:

Код: Выделить всё

Open On-Chip Debugger -00247-g90632ca40-dirty (2025-07-29-16:47)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
ERROR: invalid command name "gdb"
ERROR: invalid command name "telnet"
ERROR: invalid command name "tcl"
DEPRECATED! use 'adapter speed' not 'adapter_khz'
sw_reset_halt
Info : clock speed 2000 kHz
Info : JTAG tap: K1921VG015.cpu tap/device found: 0x00000d5b (mfg: 0x6ad (CloudBEAR LLC), part: 0x0000, ver: 0x0)
Info : JTAG tap: BSCAN.bscan tap/device found: 0x20c5f44d (mfg: 0x226 (MediaTek), part: 0x0c5f, ver: 0x2)
Info : datacount=2 progbufsize=16
Error: unable to halt hart 0
Error:   dmcontrol=0x80000001
Error:   dmstatus =0x00000c82
Error: Fatal: Hart 0 failed to halt during examine()
Warn : target K1921VG015.cpu examination failed
Info : starting gdb server for K1921VG015.cpu on 3333
Info : Listening on port 3333 for gdb connections
Error: Target not examined yet
ERROR: 
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Error: Target not examined yet
Error executing event gdb-attach on target K1921VG015.cpu:

Error: Target not examined yet
Info : CHIPID error -4, CHIPID=a816f010
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected
shutdown command invoked

В чем может быть проблема и как её исправить?

[RabidRabbit]

Вам же openocd насыпал кучу еггогов. У Вас случайно на плате вход SERVEN на питание не подключен? Судя по схеме, он там болтается в воздухе, и хотя по РП он "pull-down", подключите на всякий случай его джампером к "земле". Если не помогает, можно попробовать сервисное стирание флэша.

[ZZZRF413]

Вам же openocd насыпал кучу еггогов.

Да, я их вижу, но что с ними делать незнаю, поскольку опыта нет работы с openocd.

У Вас случайно на плате вход SERVEN на питание не подключен?

Да, он никуда не подключен, пин в воздухе. Плата в таком состоянии пришла (джампер был на пине, но не установлен на землю). Попробую установить джампер на землю. Т.е. при штатной работе он должен быть в нуле. А так в каких случаях его надо использовать? В каком случае он должен быть в единице?

Если не помогает, можно попробовать сервисное стирание флэша

Если понадобиться, то сервисное стирание флэша, где-нибудь описано как проводить?

[RabidRabbit]

Описание в РП "7.2 Сервисный сброс всей Flash-памяти".
Я делаю так:
На SERVER лог. "1", далее отключить питание/подать питание, запускаю openocd, оно подключается как обычно, потом подключаюсь через gdb (out.elf - какая-нибудь собранная прошивка для К1921ВГ015)

Код: Выделить всё

$ gdb-multiarch out.elf
GNU gdb (Debian 16.3-1) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from out.elf...
(gdb) target extended-remote :3333
Remote debugging using :3333
0x80000000 in ?? ()
(gdb) 

При этом openocd ругается вот так

Код: Выделить всё

Warn : Failed to read memory via program buffer.
Warn : Failed to read memory via system bus.
Warn : Failed to read memory via abstract access.
Error: Target K1921VG015.cpu: Failed to read memory (addr=0x7ffffffc)
Error:   progbuf=failed, sysbus=failed, abstract=failed

Далее собственно команда на стирание:

Код: Выделить всё

(gdb) set {int}0x3000F104=256
(gdb)

После этого openocd начинает сыпать ошибки

Код: Выделить всё

Error: Target K1921VG015.cpu: Failed to read memory (addr=0x56)
Error:   progbuf=failed, sysbus=failed, abstract=failed

Далее можно отключить питание, переключить SERVEN на "землю" и продолжать работать

[ZZZRF413]

Описание в РП "7.2 Сервисный сброс всей Flash-памяти".
Я делаю так:

Спасибо!

Попробовал установить джампер на пин SERVEN (и GND). Не помогло - все такие же ошибки. Но я заметил одну особенность - каждый раз новый CHIPID (см. логи в приложении и скриншот).

2.png (348.84 КБ) 1265 просмотров

С чем это может быть связанно? Может быть перед стиранием памяти что-нибудь ещё попробовать? Может быть попробовать понизить частоту JTAG (как это сделать я незнаю)?

[RabidRabbit]

В k1921vg015.cfg поставьте adapter speed 500

[ZZZRF413]

В k1921vg015.cfg поставьте adapter speed 500

Спасибо, попробовал, но к сожалению понижение скорости обмена данными по JTAG не помогло. Все тоже самое и такой же случайный CHIPID.

запускаю openocd, оно подключается как обычно, потом подключаюсь через gdb

А нужно ли делать ещё какую-нибудь настройку самого openocd? Просто я с ним совсем не работал. И если нужно есть ли инструкция или какие-нибудь другие материалы?

[ZZZRF413]

И ещё общий вопрос: а можно на время отладки flash-ку не программировать, а загружать программу в ОЗУ?

[RabidRabbit]

И ещё общий вопрос: а можно на время отладки flash-ку не программировать, а загружать программу в ОЗУ?

Можно. Собираете для запуска в ОЗУ, подключаетесь через gdb, даёте команду load - и ваша прога заливается в ОЗУ, можно ставить брыкпоинты и отлаживаться.
Сборка для запуска в ОЗУ обычно производится со "скриптом" компоновщика, который часто обозван как ram.ld. В "SDK" от НИИЭТ это вроде k1921vg015_ram.ld

[ZZZRF413]

Связь удалось восстановить. По итогу проблема похоже была в не "пропаемом" USB разъеме на плате программатора. Питание платы микроконтроллера и программатора как раз шло от компьютера через USB разъем.

Что я ещё сделал:
1) Обновил зашивку программатора BlueProg до 2.9, по инструкции
https://gitflic.ru/project/vitalii-nechaev/blueprog

2) Выполнил сервисный сброс flash-памяти по инструкции
https://www.электроника-и-программирова ... erven.html
Сброс не с первой попытки, но прошел успешно. В приложении скриншот "Правильно стирание flash в сервисном режиме.png" с логом нормального сервисного сброса flash-памяти.

3) Выполняя действие 2 я обратил внимание, что в зависимости от "нажима" на USB кабель около разъема программатора разный результат подключения - то видит микроконтроллер, то не видит. См. скриншот "Подключение к плате.png" в приложении.