Работа с RTL00 под eclipse как запустить.

[IgorPV]

Собрался записать проект Simple web server for RTL8710AF в модуль RTL8710AF. Сборка проекта проходит нормально, однако не получается прошить модуль. Использую программатор J-Link подключенный к модулю по интерфейсу SWD. При выполнении из проекта команды Flash_OTA , возникает ошибка при исполнении команд J-Link, чем она вызвана не могу понять. Подскажите какие могут быть причины таких сообщений.

make flash_OTA
make[1]: Entering directory `/d/ESP8266/RTL/RTL00_WEB-master'
cmd /K start "C:\Program Files (x86)\SEGGER\JLink_V612h JLINK_GDBSRV ?= JLinkGDBServer.exe -device Cortex-M3 -if SWD -ir -endian little -speed 1000"

D:\RTL\RTL00_WEB-master>arm-none-eabi-gdb -x flasher/gdb_ota.jlink
GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417-git
Copyright (C) 2017 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 "--host=i686-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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".
Jlink Init:
Notification of completion for asynchronous execution commands is off.
flasher/gdb_ota.jlink:337: Error in sourced command file:
localhost:2331: Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.

 

[A_D]

IgorPV, по идее JLinkGDBServer не запустился. Вот как раз вид команды смущает:

cmd /K start "C:\Program Files (x86)\SEGGER\JLink_V612h JLINK_GDBSRV ?= JLinkGDBServer.exe -device Cortex-M3 -if SWD -ir -endian little -speed 1000"

Видимо пути не все прописали к J-Link драйверам.

 

[pvvx]

IgorPV, по идее JLinkGDBServer не запустился. Вот как раз вид команды смущает:

cmd /K start "C:\Program Files (x86)\SEGGER\JLink_V612h JLINK_GDBSRV ?= JLinkGDBServer.exe -device Cortex-M3 -if SWD -ir -endian little -speed 1000"

Видимо пути не все прописали к J-Link драйверам.

Неа. Там всё более банально - время исполнения приложений и их очередность старта. Не успевает запуститься GDB. На это могут влиять антивирусы и дисковые кэши, установленные в системе.
Повторный вызов иногда исправляет ситуацию... Скрипт кривой, а в winde нет доступной команды ожидания запуска приложения... Я не пользуюсь этими командами и пока не отлаживал на все условия.
У базовой MinGW тоже какие-то непонятки с очередностью исполнения команд самой винды. Доходит до того, что не работает сборка на несколько потоков. Стандартного лечения и локализации данных нестыковок в сети нет, а сам не ковырял. Возможно это проявляется из-за разного предоставления ресурсов (рассинхронизации) для виртуальной машины MinGW и самой Win, когда вызываются разные задачи. Там темный лес и копать сложно. Проще что поменять местами в вызовах или тупо вставить задержки для синхронизации потоков... Не вписывать же в makefile структуру семафоров ...
Конкретнее это проблема у make в MinGW. Если используется другая программа исполнения скрипта сборки - таких нестыковок нет. Тот-же wav на питоне пашет без этих проблем.

Вообще c make из MinGW давно никто не ковырялся, а процы стали многоядерными и всё это поперло...
---------
Пример с всего 2-мя потоками:

Директория build создана до начала сборки
Подобное может выпасть в любой момент, как и не может найти файла, когда он есть и давно, если задана многопоточная сборка проекта.
Сильно сказываетcя наличие закэшированности файловой системы - повторный запуск всегда дает меньше таких выдуманных make ошибок...
Как это разрешить?

 

[A_D]

pvvx, ну запуск GDB сервера я просто вынес в VS на отдельную команду - она всё-равно как для заливки в RAM требуется, так и для прошивки\отладки, потому не увидел смысла каждый раз запускать\закрывать его. GDB сервер кстати остаётся работать, даже если выдернуть SWD (подключившись к ней первый раз при запуске сервера) и потом подключить заново устройство (даже другую аналогичную плату)!
А вот с многопоточностью при сборке и т.д. - не знаю, пока с проблемами такого рода не сталкивался. Просто выставил 4\6 потоков и всё. Без ограничения потоков - там да, в итоге валилась сборка по выделению памяти вроде, потом просто ограничение поставил и нормально стало (но это у вас уже прописано).

 

[pvvx]

pvvx, ну запуск GDB сервера я просто вынес в VS ...

Та я просто о грядущем Что-то надо менять в данной системе... Если брать uVision - это вообще тормоз на больших проектах. VS более интегрирована с нутром Винды, но тоже скоростью сборки не отличается и это совсем не свободное ПО. GNU так-же не является "Свободным ПО" (в нем масса ограничений, обременений и принуждений, заложенных создателем устаревшего понятия свободного ПО - он спецом в концепцию подложил бомбу Ещё не взорвалась, но скоро рванет ).

 

[IgorPV]

Неа. Там всё более банально - время исполнения приложений и их очередность старта. Не успевает запуститься GDB. На это могут влиять антивирусы и дисковые кэши, установленные в системе.
Повторный вызов иногда исправляет ситуацию... Скрипт кривой, а в winde нет доступной команды ожидания запуска приложения... Я не пользуюсь этими командами и пока не отлаживал на все условия.

Попробовал предварительно вручную запустить GDB сервер, теперь доходит до этого момента:

GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417
-git
Selecting device: Cortex-M3
Target endianess set to "little endian"
Resetting target
Target interface speed set to 1000 kHz
System Init:
Writing 0x1FC00002 @ address 0x40000304
Writing 0x00000400 @ address 0x40000250
Writing 0x00000000 @ address 0x40000340
Writing 0x0000DCC4 @ address 0x40000230
Writing 0x00011117 @ address 0x40000210
Writing 0x00011157 @ address 0x40000210
Writing 0x00110011 @ address 0x400002C0
Writing 0xFFFFFFFF @ address 0x40000320
SetCLK 166.66MHz:
Writing 0x00000011 @ address 0x40000014
Init SPI:
flasher/gdb_wrflash.jlink:143 Error in sourced command file:
Cannot access memory at address 0x40000230
(gdb)

Судя по логу почему-то не проходит запись во внешнюю флешку.

 

[A_D]

IgorPV, что то с подключением\проводами, подтяжки можно попробовать добавить на SWD линии по 1К и до питания (если rtl8710 питается не от программатора, а от своего источника).

 

[shaman1010]

Подниму "старенькую" тему.
Сегодня адаптирую связку GitHub - pvvx/RTL00MP3: RTL00(RTL8710AF) Test MP3 с eclips-ом под MacOS.
J-Link большой черный. Цели clean, readfullflash, работают. Цель all спотыкается на:

../RTL00MP3/RTL00_SDKV35a/component/common/network/dhcp/dhcps.c
../RTL00MP3/RTL00_SDKV35a/component/common/network/sntp/sntp.c
../RTL00MP3/RTL00_SDKV35a/component/common/network/netbios/netbios.c
project/src/user/wifi_console.c
project/src/user/atcmd_user.c
../RTL00MP3/RTL00_SDKV35a/component/soc/realtek/8195a/fwlib/ram_lib/rtl_boot.c
===========================================================
Link (build)
arm-none-eabi-gcc: error: build/obj/obj_list.lst: No such file or directory
make[1]: *** [application] Error 1
make: *** [ram_all] Error 2

Т.е. судя по всему кто-то не может создать build/obj/obj_list.lst (сам build с частью наполнения создается нормально).
Где подкрутить?

 

[pvvx]

В RTL00_SDKV35a\sdkbuild.mk
@$(file > $(OBJ_DIR)/obj_list.lst,$(OBJ_LIST))
@$(LD) $(LFLAGS) -o $(ELFFILE) @$(OBJ_DIR)/obj_list.lst $(LIBFLAGS) -T$(LDFILE)
Заменить на
@$(LD) $(LFLAGS) -o $(ELFFILE) $(OBJ_LIST) $(LIBFLAGS) -T$(LDFILE)
----
В Windows, в mingw, командная строка ограничена по размеру и всё не лезет. Это известная фича.
Но почему у вас не может make создать файл, остается загадкой.

 

[shaman1010]

В RTL00_SDKV35a\sdkbuild.mk
@$(file > $(OBJ_DIR)/obj_list.lst,$(OBJ_LIST))
@$(LD) $(LFLAGS) -o $(ELFFILE) @$(OBJ_DIR)/obj_list.lst $(LIBFLAGS) -T$(LDFILE)
Заменить на
@$(LD) $(LFLAGS) -o $(ELFFILE) $(OBJ_LIST) $(LIBFLAGS) -T$(LDFILE)
----
В Windows, в mingw, командная строка ограничена по размеру и всё не лезет. Это известная фича.
Но почему у вас не может make создать файл, остается загадкой.

Так на MacOS же
Сейчас вот так пишет:

../RTL00MP3/RTL00_SDKV35a/sdkbuild.mk:54: *** missing separator.  Stop.
make: *** [ram_all] Error 2

p.s. отбой, глюк копи-паста с форума. Руками строчку перепрописал - запнулось дальше. Копаю.

 

[pvvx]

А дальше, в Ubuntu, будет беда с путями у *.ld файла
Ну тупой gcc в Linux, не понимает, что -L<директория>, указывает путь поиска библиотек и *.ld (и include из него).
Но полезет его искать в своих /usr/lib/gcc/arm-none-eabi/version/../../../arm-none-eabi/bin/ld

 

[shaman1010]

А дальше, в Ubuntu, будет беда с путями у *.ld файла
Ну тупой gcc в Linux, не понимает, что -L<директория>, указывает путь поиска библиотек и *.ld (и include из него).

Ну в linux-е может и так, unix сейчас не понимает, что за exe-шники ему в
../RTL00MP3/RTL00_SDKV35a/component/soc/realtek/8195a/misc/iar_utility/common/tools/rtlaimage
подсовывают

 

[pvvx]

TOOLS_PATH ?= $(SDK_PATH)../tools/
IMAGETOOL = $(PYTHON) $(TOOLS_PATH)rtlaimage/rtlaimage.py

И это не exe это странслированный rtlaimage.py
pyinstaller -c --onedir --onefile -n rtlaimage rtlaimage.py

Всё давно пашет в Win10 WSL (Ubuntu). Там и *.exe и всё пашет, в отличии от Linux.
Искать где спрятался Python не надо.
А MacOS давно сдулась.
----
Вы уж напишите как GCC Linux втолковать где лежит *.ld?
В SDK4.0 для RTL "B" вышло только так
@$(LD) $(LFLAGS) -o $(ELFFILE) @$(OBJ_DIR)/obj_list.lst $(LIBFLAGS) -T$(patsubst sdk/%,$(SDK_PATH)%,$(PATHLIBS))/$(LDFILE)

Ещё надо поправить на большие буквы:
PATHLIBS = sdk/component/soc/realtek/8195a/misc/bsp/lib/common/GCC
Но это само собой... Win-де то всё равно.

 

[pvvx]

Сборка с нуля проекта в WSL 4.526 секунды.

Спойлер: лог

# time make -s clean
real    0m0.685s
user    0m0.063s
sys     0m0.328s
# time make -s -j 32 all
===========================================================
Compile (build)
project/src/user/main.c
project/src/user/spiram_fifo.c
project/src/mad/mad_version.c
project/src/mad/mpg12/layer12.c
project/src/mad/frame.c
project/src/mad/layer3.c
project/src/mad/align.c
project/src/mad/decoder.c
project/src/mad/huffman.c
project/src/mad/fixed.c
project/src/mad/bit.c
project/src/mad/synth.c
project/src/mad/timer.c
project/src/mad/stream.c
project/src/driver/i2s_freertos.c
RTL00_SDKV35a/component/soc/realtek/8195a/fwlib/ram_lib/rtl_bios_data.c
RTL00_SDKV35a/component/soc/realtek/8195a/cmsis/device/system_8195a.c
... вырезано из-за размера - не влезет в сообщение ...
RTL00_SDKV35a/component/common/network/netbios/netbios.c
RTL00_SDKV35a/component/common/network/sntp/sntp.c
project/src/user/atcmd_user.c
project/src/user/wifi_console.c
RTL00_SDKV35a/component/soc/realtek/8195a/fwlib/ram_lib/rtl_boot.c
===========================================================
Link (build)
===========================================================
RtlAImages Utility version 22.01.18
Segment at 0x10000bc8, size 0x00002128 (ram_1)
Segment at 0x10006000, size 0x000497fc (ram_2)
Images size: SRAM 309540 bytes, SDRAM 0 bytes [309540]
-----------------------------------------------------------
Image (build/bin/ota.bin) size 301080 bytes
Image (build/bin/ram_all.bin) size 346132 bytes
===========================================================

real    0m4.526s
user    0m26.313s
sys     0m24.016s

 

[shaman1010]

TOOLS_PATH ?= $(SDK_PATH)../tools/

Только tools туда сначала перенести

Еще закомментировал эхо в flasher.mk мешает

_endgenbin:
#    @echo "-----------------------------------------------------------"
#    @echo "Image ($(OTA_IMAGE)) size $(shell printf '%d\n' $$(( $$(stat --printf="%s" $(OTA_IMAGE)) )) ) bytes"
#    @echo "Image ($(FLASH_IMAGE)) size $(shell printf '%d\n' $$(( $$(stat --printf="%s" $(FLASH_IMAGE)) )) ) bytes"
#    @echo "==========================================================="

Всё давно пашет в Win10 WSL (Ubuntu). Там и *.exe и всё пашет, в отличии от Linux.
Искать где спрятался Python не надо.

На яблоке уже тоже все сложилось

А MacOS давно сдулась.

Я остановился еще на не сдувшемся, со всеми плюшками, до смены курса. Но в целом, похоже, программеры из яблок к мелкомягким потопали. Это да.

Вы уж напишите как GCC Linux втолковать где лежит *.ld?
В SDK4.0 для RTL "B" вышло только так
@$(LD) $(LFLAGS) -o $(ELFFILE) @$(OBJ_DIR)/obj_list.lst $(LIBFLAGS) -T$(patsubst sdk/%,$(SDK_PATH)%,$(PATHLIBS))/$(LDFILE)

Wl, - ?

Ещё надо поправить на большие буквы:
PATHLIBS = sdk/component/soc/realtek/8195a/misc/bsp/lib/common/GCC
Но это само собой... Win-де то всё равно.

Не менял, завелось так. Нужно посмотреть, где обошел.

Сборка с нуля проекта в WSL 4.526 секунды.

Ну да...

RtlAImages Utility version 22.01.18
Segment at 0x10000bc8, size 0x00002160 (ram_1)
Segment at 0x10006000, size 0x00049128 (ram_2)
Images size: SRAM 307848 bytes, SDRAM 0 bytes [307848]

22:29:25 Build Finished (took 13s.744ms)

Спасибо

 

[pvvx]

Win10 msys32, пример sntp из ESP-IDF

# time make clean
real 0m19,886s
user 0m1,725s
sys 0m5,617s
# time make all
real 2m29,363s
user 0m13,066s
sys 0m36,616s

При -j 32

# time make -j 32 clean
real 0m3,738s
user 0m1,658s
sys 0m5,566s
# time make -j 32 all
real 0m52,311s
user 0m17,736s
sys 0m50,319s

Спасибо

Обновил git c MP3... Сунул туда что идет на WSL и на Win (mingw)

 

[shaman1010]

Win10 msys32...
При -j 32

У меня столько нет
Кстати, "B" планируете выводить в свет?

 

[pvvx]

У меня столько нет

Скорость сборки не на прямую зависит от реального кол-ва ядер.
Примерно надо умножать на 2..4 кол-во тредов... Где-то после -j 64 на 8 ядер будут показания уменьшаться, а до x2..x4 увеличиваться...
На Win-де зависит от того, где лежат файлы. Если в WSL в mnt/tmpfs, то сборка будет в 2 раза шустрее, чем на любом win диске (разницы между m.2 ssd/pci и древним IDE у Вынь нет - работает "кещирование" файлов и отложенная запись)
Если у вас кажет 13 сек, то на mnt/tmpfs будет 6 сек.
(Это всё для Win10 WSL).

Кстати, "B" планируете выводить в свет?

Пока нет, но всё уже есть и давно пашет, включая rtlDuino"B".
И там прошивка шустрая - 1.5 Мбит/сек (через COM )
Не хочу ломать кайф Arduin-щикам и Ameba. Пусть сами делают, выкладывают и обслуживают.

 

[shaman1010]

Пока нет, но всё уже есть и давно пашет, включая rtlDuino"B".
И там прошивка шустрая - 1.5 Мбит/сек (через COM )
Не хочу ломать кайф Arduin-щикам и Ameba. Пусть сами делают, выкладывают и обслуживают.

Сарказм он такой сарказм...
С ROM-BIOS уже завершили там?

 

[pvvx]

Сарказм он такой сарказм...

Segment at 0x0800b020, size 0x0003d770 save to xip_image2.p.bin
Segment at 0x10005000, size 0x00000f70 save to ram_2.p.bin
Segment at 0x0800b020, size 0x0003d770 save to T:\Tmp\arduino_build_703051/ota.bin
Segment at 0x10005000, size 0x00000f70 save to T:\Tmp\arduino_build_703051/ota.bin
Images size: Flash 251760 bytes, Ram 3952 bytes [255712]
Скетч использует 255676 байт (12%) памяти устройства. Всего доступно 2097152 байт.
Глобальные переменные используют 34720 байт (14%) динамической памяти, оставляя 206944 байт для локальных переменных. Максимум: 241664 байт.
Цена 500 т.руб для Арддуино-поклонников. Для пишущих и желающих сопровождать - по требованию.
Требуется починить пару warning при сборке частей SDK и переписать номера выводов в примерах для соответствия к модулю.
Пример заснят на старом компе (5 лет ему ) и скорость сборки желает лучшего... На видео ничего не ускорено. (Как включить многопоточную сборку в Arduino я не знаю).

С ROM-BIOS уже завершили там?

А что там? Там вроде всё было Ok. Туда слили всё что было в API и HAL у RTL "A", исправив ошибки и подработав...
Теперь только дрова WiFi торчат в Flash (XIP) и части SRAM.
Для ROM же "кэша" не требуется. Она сама шустрая и не требует его, в отличии от любых Flash.
В итоге объем используемой RAM уменьшился, как и код самой прошивки в Flash.
XIP тоже шустрый - по умолчанию пашет на 100 МГц и имеет 32 кило "кэш".
Ну и есть FPU. Проблем с плавучкой нема...
В отличии от серии "A" ещё добавлен расширенный PMU. Таймеры тактируются от 80 МГц (ну в общем там они разные и у них разные источники, включая внешние (32К тоже можно внешний для deep_sleep и типа), и режимов пачка - счет с I/O с DMA (до 40 МГц), PWM пачка с шагом 40 ns, счет длительности внешнего сигнала, ...).
psRAM прикручивать не пробовал, но по идее должна пахать. Как с ней будет работать DMA - тоже не проверял, но исполнение кода из неё - должно. Если будет работать копирование DMA flash->SRAM, то должно пахать и с psRAM. Можно и счас проверить, но пока нет нужды.