Debuging W806 in Arduino IDE 2.0.3

[AnatolSher]

На всякий случай дернул у T-Head сервер отладки для Win и Linux. Самодельный CKLink-Lite видит, порты открывает... не ругается
Инструкцию по применению придется переводить с китайского.

Just in case, I pulled the debug server for Win and Linux from T-Head. Homemade CKLink-Lite sees, opens ports ... does not swear
Instructions for use will have to be translated from Chinese.

T-Head-DebugServer-windows-V5.12.11-20211229-1605.zip
T-Head-DebugServer-linux-x86_64-V5.12.11-20211229.sh.tar.gz

UPD:
В рукопашную отладка работает! Надо разбираться как в IDE 2/0/3 ее вкрутить. Я еще не все команды GDB изучил.
Видно какой то косяк... Брекпойнт не установился.

In hand mode, debugging via C-SKY GDB works. We need to figure out how to add it to IDE 2/0/3

[AnatolSher]

Проверил как ведет себя сервер отладки и отладчик в ОС Linux. Программы запускаются

Я сейчас работаю с Linux в виртуальной среде VBox. Последний релиз x64 Fedora
СКLink-Lite успешно замапился.
Нужно подгрузить ncurses-compat-lib (sudo yum install ncurses-compat-libs)
csky-elfabiv2-gdb отладчик лежит в папке .Arduino15/packages/w80x_duino/tools/csky/2021.04.23/bin

I checked how the debug server and debugger behave in Linux OS. Programs run
I'm currently working with Linux in a VBox virtual environment. Latest x64 Fedora release
CKLink-Lite successfully mapped.
You need to download ncurses-compat-lib (sudo yum install ncurses-compat-libs)
csky-elfabiv2-gdb debugger is located in the folder .Arduino15/packages/w80x_duino/tools/csky/2021.04.23/bin

[AnatolSher]

Рекомендация по сборке CKLink-Lite
В схеме у henrycoder обозначен контроллер STM32F103C8T6. Однако, с этим контроллером я получил не стабильную работу.
По моему мнению нужен контроллер не менее 128kb флеш памяти. Например STM32F103CBT6. Такой "голубой таблетки" у меня не было. В дело пошел неизвестный китайский клон с 256kb на борту.

CKLink-Lite build recommendation
In the henrycoder's schematic diagramhas an STM32F103C8T6 controller present. However, with this controller, I did not get stable work.
In my opinion, you need a controller with at least 128kb of flash memory. For example STM32F103CBT6. I didn't have that original "blue pill". An unknown Chinese clone with 256kb on board went into action.

[board707]

Спасибо за информацию.
Честно говоря, пока внимательно в отладку не вникал.
Не могли бы вы расписать по шагам, как установить и запустить отладчик с нашей платой?
Или если где-то есть такое описание - дайте, пожалуйста, ссылку.

[AnatolSher]

На T-Head Debug Server делаю перевод с китайского. Может за пару недель управлюсь
Я еще здесь немного касаюсь темы CDK и отладки с самодельным CKLink-Lite
https://radiokot.ru/forum/viewtopic.php?f=62&t=185076

[AnatolSher]

Оооопс! Повезло :) Нашел туториал на английском!
T-Head Debugger Server User Guide (EN-US).pdf
Что то сегодня прет не по децки :)
C-SKY+Tools+V3+User+Guide-GDB.pdf

[AnatolSher]

Не могли бы вы расписать по шагам, как установить и запустить отладчик с нашей платой? Или если где-то есть такое описание - дайте, пожалуйста, ссылку.

Если Вы имеете в виду саму железяку CKLink-Lite, то вот здесь расписано все
https://hackaday.io/page/12671-how-to-debug-w806-and-w801-mcus

[AnatolSher]

Вот нашел кино как пользоваться олдскульной отладкой GDB на примере STM
https://www.youtube.com/watch?v=D-MbC9N5U7o&t=558s
Но так пока у меня не получилось, не смотря на то, что основные шаги были выполнены успешно.
Китайцы отсылают к dbg.org за туториалом. Читал... долго думал :) Но что то узкоглазые не договаривают

[AnatolSher]

Наткнулся на странную вещь! Вот что выдал мне gdb отладчик

Откуда в elf файле ссылка на несуществующий маршрут на моем компьютере?
Возможно где то лежит сценарий в пакете 80x-duino. Но я его найти не могу. Отладчик затыкается на этом месте
Там вроде написано что нет такого файла. Но у меня и диска D: нету

[board707]

По-моему у товарища nulllab лежали прекомпилированные версии всех .S файлов в его ардуино-пакете, видимо собранные на его компе.
Может их удалить и собрать заново?

[AnatolSher]

Я попробую грохнуть все с расширением *.o и перекомпилировать скетч

[AnatolSher]

Грохнул! Вот что теперь получается

Как заставить ардуинку всегда заново пересобирать ядро?
А то я потерялся уже... :)

[board707]

Как заставить ардуинку всегда заново пересобирать ядро?

Этого не знаю.

Дополнение - нашел, кроме стирания .o файлов, нужно еще переименовать соответвующие исходники. Они там лежат с расширениями .S_ - специально, чтобы не пересобирались каждый раз. Их надо поменять на .S
Только бестолку - сейчас попробовал, не собираются, каких-то других файлов не хватает.

[AnatolSher]

Здается мне что вот тут собака зарыта

These can be overridden in platform.local.txt

compiler.c.extra_flags=
compiler.c.elf.extra_flags=-Wl,--no-whole-archive -nostartfiles -mhard-float
#compiler.S.extra_flags=-I{runtime.tools.csky.path}/csky-elfabiv2/include/csi/csi_core/csi_cdk/ -ID:/C-Sky/CDK/CSKY/csi/csi_core/include/ -ID:/C-Sky/CDK/CSKY/csi/csi_driver/include/
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2bin.extra_flags=
compiler.includes="-I{runtime.tools.csky.path}/csky-elfabiv2/include" "-I{build.core.path}/include" "-I{build.core.path}/include/arch/{build.arch}" "-I{build.core.path}/include/arch/{build.arch}/csi_dsp" "-I{build.core.path}/include/arch/{build.arch}/csi_core" "-I{build.core.path}/include/driver"
compiler.libs={build.core.path}/lib/libdsp.a {build.core.path}/lib/arch/{build.arch}/bsp/startup.o {build.core.path}/lib/arch/{build.arch}/bsp/__rt_entry.o {build.core.path}/lib/arch/{build.arch}/bsp/vectors.o

В нижней строке берутся объектные файлы
А в закомментированной строке идет отсылка на CDK... не SDK! Попробую там пошаманить

[board707]

Я думаю можно стереть эти .o файлы в SDK и попробовать собрать какой-нить из встроенных примеров. И посмотреть, как и с какими опциями SDK их соберет. Потом перенести в ардуино.
В SDK они заведомо собираются, при скачивании с гитхаба там обьектных файлов нет.

Добавка: - а можно просто запустить сборку в СДК и потом положить получившиеся файлы в ардуино пакет, как это сделал товарищ nulllab

[AnatolSher]

Да нееее... Это все разруливается в Platform.txt
После рихтовки параметра
compiler.S.extra_flags= -I{build.core.path}/include -Ibuild.core.path}/include/arch/{build.arch} -I{build.core.path}/include/arch/{build.arch}/csi_dsp -I{build.core.path}/include/arch/{build.arch}/csi_core -I{build.core.path}/include/driver -I{build.core.path}/include/arch/{build.arch}
Компилятор *.S файлы видит, но почему то не создает на них объектники с расширением *.o и *.o.d
Эта фаза зависит наверное от другого параметра

Compile S files

recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" -c "{source_file}" -mcpu={build.mcpu} {compiler.S.flags} -MMD -MP -MT{object_file} -MF{object_file}.d -o "{object_file}" {compiler.S.extra_flags} {build.extra_flags} {compiler.includes} {includes}

Тут я пока ничего не понимаю

[board707]

Чтобы компилятор увидел .S файлы, никаких параметров в настройках "рихтовать" не надо. У меня они видятся сразу.
А для создания .o.d файлов в ардуино просто нет рецепта, вот они и не создаются.
Поэтому я предлагаю посмотреть, как они создаются в СДК - а потом это перенести в наш пакет. На мой взгляд, это самый простой путь.
А подбирать параметры , тем более не очень понимая, что они значат - тупиковый путь.

[AnatolSher]

А для создания .o.d файлов в ардуино просто нет рецепта, вот они и не создаются.

Рецепт есть, только я не понимаю как его поперчить/посолить. Вот здесь он

Compile S files

recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" -c "{source_file}" -mcpu={build.mcpu} {compiler.S.flags} -MMD -MP -MT"{object_file}" -MF"{object_file}.d" -o "{object_file}" {compiler.S.extra_flags} {build.extra_flags} {compiler.includes} {includes}

[AnatolSher]

Мне кажется Вы меня не поняли. Ничего выдергивать не надо.

Теперь понял :)

[AnatolSher]

В общем... Мне удалось заставить компилировать без ошибок. Но толку от этого мало... к сожалению
Если убрать китайские объектники и собрать прошивку, то она не стартует на плате. Похоже этот nullaborg собрал ядро отдельно и исходников не оставил
И еще одно наблюдение. В исходном SDK вообще нет __rt_entry.S И размеры остальных вроде отличаются. На содержимое не проверял.

Вот так происходит сборка в CDK

Я так и сделал в Platform.txt
Но явно __rt_entry.S я не обнаружил. Ни в CDK ни в SDK

Но еще поковыряюсь

[board707]

Вот так происходит сборка в CDK
Я так и сделал в Platform.txt

Выложите куда-нибудь Platform.txt , который у вас получился. Только не скриншотом! Вообще никогда не выкладывайте команды консоли скриншотом(как выше), пожалуйста.

[AnatolSher]

Это был вывод из CDK. Я пока не знаю куда он логи компиляции складывает

[board707]

Не, надо копать дальше. Раз в SDK все собирается и потом работает - значит там все есть для успешной сборки. Вывод - и в ардуино должно собираться.
И, кстати. если вы собираете прошивку для дебага - вам и обьекты из файлов .S надо собирать с ключиками отладки, а не так как прописано в SDK

[AnatolSher]

-g3 -ggdb я ставил

[board707]

Сейчас попробовал - у меня все собирается.

1.Распаковал SDK, взятый по Вашей ссылке
2.Настроил путь к компилятору через make menuconfig
3. make lib
4. make all

После этого в каталоге bin/build/W806/obj/platform/arch/xt804/bsp будут лежать интересующие нас .o файлы. Их можно взять и скопировать в пакет для ардуино. С этими новыми обьектными файлами у меня все собирается и даже работает.
Если нужен файл __rt_entry.o - то его можно сгенерить в том же SDKиз того исходника, что нам оставил товарищ nulllab. Для этого просто подложите файл __rt_entry.S в тот каталог SDK где лежали другие .S файлы и повторить пункты 2 и 3 выше.

PS Выложите куда-нибудь свой Platform.txt, куда вы добавляли рецепт для сборки .о файлов. Только не скриншотом.

[AnatolSher]

Чуть позже... вечером или ночью

На всякий случай
C-SKY+Tools+V3+User+Guide-Compiler.pdf
C-SKY+Tools+V3+User+Guide-Link.pdf

Ну и стандарт

C-SKY+ABIV2+Standards+Manual.pdf
C-SKY+ABIV1+Standards+Manual.pdf

[AnatolSher]

Ну вот... platform.txt
Компилирует без ошибок... но лыжи не едут :)
platform.txt
В результате компиляции все объектники попадают в /tmp и там собираются воедино

А это протокол компиляции из CDK IDE

BuildLog.txt

Возможно я что то упустил... Но уже глаз замылился. И меня уже колбасит не по детцки :) из-за этой проблемы
На сколько я понял, *.S файлы это ассемблерные вставки и они компилируются с такими же опциями как и обычные *.c

[board707]

Ок, я тоже это все проделал. Я даже выставил абсолютно одни и те же опции компиляции при сборке под ардуино и непосредственно в SDK. Все собирается без ошибок, но с обьекниками из SDK прошивка работает, а из ардуино нет.

Предлагаю вернутся к исходному вопросу. Зачем нам нужно пересобирать эти файлы? Если речь о том, чтобы обеспечить работу отладки, то не можем мы скомпилировать правильные файлы в SDK, а потом просто подложить их в Ардуино? Это не решит проблему?

[AnatolSher]

Нам нужно что бы эти объектники были гарантировано с ключом -g3 и были доступны их реальные исходники. Иначе gdb работать как нам хочется не будет.
Я еще попробую воссоздать рабочее окружение nulllaborg-а. Даже еще винт прицепил на комп. Назначил букву D:
Этот товарищ использовал CDK, вот я и подсуну маршрут который прописан в этих объектниках. Посмотрим что получится.
Возможно, то что Вы предлагаете - сработает. Но меня мучает вопрос... какого хрена там делает __rt_entry.S и __rt_entry.o? Если в стандартном SDK после компиляции этого файла не видно... зачем nulllaborg его туда подсунул?
Среда CDK IDE этот файлы генерирует и эти файлы присутствуют в папке /Obj и они участвуют в окончательной сборке прошивки, хотя в логах их следа нет. И тоже все работает. Как то так. Чудеса...

[board707]

Не похоже что в этом дело.
В SDK они собираются без этого маршрута и работают...

Ладно, удачи.
Я пока буольше этим заниматься не буду, отладка это явно не первой важности цель в этом проекте :)

[AnatolSher]

Без отладки будет очень сложно воссоздать стандартный ардуиновский набор Wiring. А потом еще согласовать вызовы внешних библиотек типа Адафруит и т.д Тут printf и морганием светодиодов не обойдешься.
Я еще одну попытку сделаю... Не получится, возьму перерыв :)
Какая задача первоочередная у Вас? Я думаю что надо сборку 0.0.2с сделать с новым Hal

[AnatolSher]

Вот подумал... может версия тулчейна имеет значение? nulllaborg это делал на старье

[AnatolSher]

Не похоже что в этом дело. В SDK они собираются без этого маршрута и работают...

Маршрут нужен для отладчика. По этому маршруту находятся исходники

[board707]

Версия тулчейна не может влиять, потому что файлы, созданные этим новым тулчейном в SDK - работают в ардуино!

Похоже я нашел в чем дело, но пока не знаю, как поправить. Среда ардуино создает обьектные файлы с именем xxxx.S.o и это имя сохраняется в списке обьектных файлов. Однако при сборке библиотеки, похоже, использовано имя xxxx.o и потому часть символов из обьектных файлов не разрешается.
Мне кажется, проблема уйдет, если заставить ардуино ИДЕ собирать эти файлы с именем xxxx.o. Но в рецепте имя выходного файла генерится автоматически и я пока не нашел, как это изменить.

[AnatolSher]

-MMD -MP -MF {object_file}.d -MT {object_file} -o "{object_file}"
Эти опции управляют компилятором и говорят с каким расширением будут выходные файлы
Например
If -o is not specified, the default is to put an executable file in a.out, the object file for source.suffix in source.o, its assembler file in source.s, a precompiled header file in source.suffix.gch, and all preprocessed C source on standard output.
Т.е при компиляции на входе целый винигрет с разными расширениями одного и того же исходника. А вот что линковщик (если такое есть) собирает... это вопрос.

[board707]

Эти опции управляют компилятором и говорят с каким расширением будут выходные файлы

Это я в курсе. Но в рецептах сборки platform.txt это не работает.

В итоге у меня все собирается. Я был прав насчет того, что дело было в именах файлов - проблема в том, что библиотека gcc_csky.ld содержит ссылку на startup.o.

В итоге создал на каждый из трех .S файлов свой рецепт с генерацией обьектного файла .o, а не .S.o . Далее возникла проблема, как не дать ардуине откомпилировать файлы еще раз - пришлось спрятать исходные .S файлы в отдельный каталог снаружи дерева core. Но в итоге теперь все собирается и прошивка работает.

[board707]

Вот вам мой файл
platform.txt
В том каталоге, где лежит platform.txt - создайте директорию slib и скопируйте в нее три наших .S файла. В том каталоге, где они лежали изначально, переименуйте их .S_ - чтобы не подхватывались компилятором.
Для чистоты экперимента соответвующие обьектные файлы можете убрать, чтобы быть увренным, что они сгенерятся заново.
Удачи.

[AnatolSher]

Вот здорово! Спасибо

И еще один "наглый" вопрос :)
Мы можем заставить ардуино иде создавать символические ссылки во временную папку, где собирается прошивка и *.elf файл?
Для дальнейшего юзабилити там должны быть ссылки на два файла. T-Head debug server и cskygdb.
Папка T-Head возникает после инсталяции пакета (см.выше) в домашнем каталоге.

[board707]

Мы можем заставить ардуино иде создавать символические ссылки во временную папку, где собирается прошивка и *.elf файл?

Где эти ссылки должны располагаться? В пользовательском каталоге где скетч?
Определить временную папку, где ИДЕ собирает прошивку - не проблема. А вот для каталога скетча такой переменной сходу не нашел. Если найду, то под линуксом создать ссылку не проблема, под виндой надо пробовать.

[AnatolSher]

Нет. Они должны быть во временной папке где собран *.elf (/tmp)
Это наш предмет отладки

[board707]

Нет. Они должны быть во временной папке где собран *.elf (/tmp) Это наш предмет отладки

У ссылки, так сказать, два конца. Один - где она расположена, а второй - куда она указывает. Я понял, что один из концов - во временной папке где ардуино собирает проект. А второй?

[AnatolSher]

gdb лежит здесь packages\w80x_duino\tools\csky\2021.04.23\bin
T-Head debug server будет лежать в домашнем каталоге после ручной инсталляции под $User
Но, наверное, было бы правильно включить debug server в состав пакета w80x_duino
Единственно что нужно учесть что эта штука имеет зависимость от ncurses-compat-lib (sudo yum install ncurses-compat-libs)
Тогда вообще никаких проблем.

Но в принципе этот пункт избыточен на текущем этапе. Можно ручками запустить debug server (он же прокси между отладчиком CKLink-Lite и gdb)
Но на будущее... когда будем внедрять отладку в Arduino IDE 2х это будет актуально. Т.е T-Head debug server в составе пакета

[board707]

С утра нашел более простое и изящное решение. Не надо никаких рецептов, не надо выкладывать файлы в отдельный каталог... Достаточно открыть файл cores/w806/ld/gcc_csky.ld любым текстовым редактором (это текстовой файл), найти в нем две строки, где встречается имя файла startup.o и исправить его на startup.S.o .
После этого все работает

[AnatolSher]

Я вообще подумал что надо сломать схему сборки ардуиновскую с ее временным каталогом. Всю сборку перенаправить в папку где лежит скетч. Создав там каталог для сборки /build
Но... люди ко всему привыкают :)

[AnatolSher]

С утра нашел более простое и изящное решение.

В итоге результирующий platform.txt как выглядит?

[board707]

Не думаю, что это правильный путь. Все-таки мы (по крайней мере я) хотим создать пакет для Ардуино. Чем ближе мы будем придерживаться ардуино стандартов, тем проще будет интегрировать пакет в среду и тем меньше будет потом проблем с его поддержкой.

[board707]

Файлы
platform.txt
gcc_csky.ld.txt
У второго удалите двойное расширение .тхт, это пришлось добавить, а то форма сообщения такого файла не понимает

[AnatolSher]

Ok. Спасибо

[board707]

Анатолий, по отладке это вы решайте сами, я в нее не вникал. Если надо будет линк на каталог сборки - пишите, сделаю.

Что по последним изменением - помогла Вам перекомпиляция .S файлов? Gdb начал запускаться?

[AnatolSher]

Да! Все прекрасно компилируется, прошивка стартует на плате. Дальше копаю gdb, все запускается.
Возможно, еще с ключами компиляции придется повозиться. Мне кажется есть немного различий в том что делают CDK IDE и Arduino IDE
Исходники стартапа видит! Это уже очень хорошо.

[AnatolSher]

Вот объяснение первых граблей... китайцы из WinnerMicro отвечают
http://ask.winnermicro.com/question/127.html
на это предупреждение

Интересно а в коде ядра есть функция типа __BKPT()

[board707]

Это вы им там вопросы задаете?

[AnatolSher]

:) Мы не первые и не последние кто на эти грабли наступил. Все поиском
__BKPT() я нашел... но он не сработал
Вот тут малопонятное объяснение как рулить памятью камня.
http://ask.winnermicro.com/question/19.html
В теории мы можем указать что должно работать из ОЗУ. Тогда мягкие брекпойнты можно устанавливать из gdb. Но может я ошибаюсь.

Проблема в том что на WinnerMicro нет возможности зарегистрироваться если ты не житель поднебесной.
Надо искать китайца и привлекать к проекту :)

[AnatolSher]

В общем... пришел к выводу что надо научиться рулить памятью камня. Если посмотреть что в .elf написано, то видно что функции main,loop,setup действительно находятся во flash (с 0x08000000), и выполняются оттуда. Там gdb установить soft-breakpoint не может. В отличии от ARM где исполнимый код при старте копируется в специальную область ОЗУ. Поэтому мужик с ролика по отладке STM лихо расставлял точки останова.
Заметил такую странность. В пакете 80x-duino в файле csi_gcc.h присутствует такая конструкция:
`/*
\brief Breakpoint
\details Causes the processor to enter Debug state
Debug tools can use this to investigate system state when the instruction at a particular address is reached.
*/

__ALWAYS_STATIC_INLINE void __BKPT(void)
{
__ASM volatile("bkpt");
}
`
При наличии у процессора аппаратного триггера, он должен тормознуть на месте где написан __BKPT(); - и передать управление отладчику. Это не срабатывает. В этом заключается странность.

А так... все мы сделали правильно. c-sky gdb работает, прошивку можно трассировать. Но есть неудобство. Пока дошагаешь до Loop() - офигеешь :)

[AnatolSher]

Заработало! Оказывается можно через c-sky gdb устанавливать hardware breakpoint
Пошел раскуривать туториал на GDB :)

На этом этапе можно ставить точку.
Второй этап - вкручивание этого хозяйства в Arduino IDE 2.x

[board707]

Поздравляю.
Будете разбираться с GDB - сразу пишите хелп файл. Сначала для меня, а потом мы его в репозиторий положим :)

[board707]

Внес обновления, касающиеся сборки S файлов, на гитхаб.

[AnatolSher]

Выяснил что пока в Arduino IDE 2x встроить отладку других архитектур отличных от ARM пока не возможно. Это печально...но это пока. Зато для настоящих мужиков работает консольная отладка в Linux и весьма не плохо... Привыкнуть надо.

А для ботанов я запилил пакет для CDK под windows. Можно отлаживать как скетч так и ядро wiring.

Я пока не знаю какие возможности предоставляет CDK для управлениями вариантами. Но думаю дефайнами и препроцессорными директивами пока разруливать. Таким образом можно и под w801 настрогать расширений. имхо

[songzhishuo]

Can you give me this package, I think it will be more convenient to use CDK directly if you develop functions later

[AnatolSher]

See email

[eassyly]

can't INSTALL w80x_arduino csky plain
Note:

Downloading packages
w80x_duino:csky@2021.04.23
w80x_duino:w80x_tool@v1.0
w80x_duino:XT804@0.0.3
Installing w80x_duino:csky@2021.04.23
Failed to install platform: w80x_duino:XT804.
Error: 13 INTERNAL: Cannot install tool w80x_duino:csky@2021.04.23: searching package root dir: no unique root dir in archive, found 'C:\Users\eassy\AppData\Local\Arduino15\tmp\package-2833822628\bin' and 'C:\Users\eassy\AppData\Local\Arduino15\tmp\package-2833822628\csky-elfabiv2'

[board707]

Hi @eassyly !
Thanks for your inform.
Please try to install with a new json file https://github.com/board707/w80x_arduino/blob/hal-v0.6.0/package_w80x_test_index.json and report the results here or in issue #18