• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

printf

sharikov

Active member
С printf в RTL непонятное. Их как минимум три штуки (возможно больше):
DiagPrintf, rtl_printf и просто printf.

В большинстве примеров используют printf. У меня он не всегда работал и я недолго думая стал использовать DiagPrintf - он работает всегда.

Однако при отладке rtlhttpd столкнулся с разрушением переменных которое проявляется в виде HardFault. Долго искал ошибку в esphttpd, не нашел но выявил разрушение переменных после DiagPrintf с большим количеством аргументов . Убрал DiagPrintf - баг ушел. Но печать отладочной информации в Log UART нужна. Printf у меня почему-то просто ничего не печатает.
 

pvvx

Активный участник сообщества
С printf в RTL непонятное. Их как минимум три штуки (возможно больше):
DiagPrintf, rtl_printf и просто printf.
Если смотреть весь код, то названий и больше.
Но используется DiagPrintf из ROM и патч в RAM - rtl_printf.
Все остальные названия идут через #defane xxxprintxx rtl_xxprintxx/DiagxxPrintxx (смотрите #include в вашем коде - они приводят к разному вызову по printf - к DiagPrintf или rtl_printf, в зависимости и от последовательности включения #include)
DiagPrintf неправильный - имеет в конце return 1 и имеет ограничения связанные с используемыми буферами в области ram-rom от включенных в ROM базовых либ СИ.
printf должен возвращать кол-во напечатанных символов, как и sprintf/vprintf/... Очень неудобно если он этого не делает, особенно при выводе форматированных строк с "\t".
Так-же, при RTOS не всё хорошо с многозадачностью в DiagPrintf, rtl_printf.
Два процесса выводят символы (куски строк) в перемешку, а использованный стиль написания строк вывода у программиста в SDK, начинающаяся с "\r\n", а не кончающаяся ими приводит к тому, что строки в стандартных мониторах затираются новыми :) Половину SDK (в моей версии) исправил от этой болезни, кроме частей находящихся в бинарных либах...
@sharikov - Ищите базовые составляющие vXprintf и собирайте из него правильную printf. Все ваши вопросы подробно расписаны в любом описании стандартных библиотек СИ (stdio.h).
printf — Википедия
 
Последнее редактирование:

pvvx

Активный участник сообщества
Однако при отладке rtlhttpd столкнулся с разрушением переменных которое проявляется в виде HardFault. Долго искал ошибку в esphttpd, не нашел но выявил разрушение переменных после DiagPrintf с большим количеством аргументов .
Это может быть связано с уже описанным - порче загрузчиком области ram-rom - переменных rtl_impure_ptr и менеджера памяти в ROM.
Вам никуда не деться, пока не напишите правильный bootloader. :p :)
Или думаете почему я не ещё не слепил его... Там не всё просто так и надо много чего совместить и разработать/переработать полную концепцию для всего SDK. А пока сторонней помощи = нуль. Это требует и такое же отношение к сторонним вопросам :)
RTL871x BootLoader
Авто дизасм->си DiagPrintf()
Код:
//----- (0000F39C) --------------------------------------------------------
signed int DiagPrintf(int *a1, int a2, int a3, int a4)
{
  int varg_r1;
  int varg_r2;
  int varg_r3;

  varg_r1 = a2;
  varg_r2 = a3;
  varg_r3 = a4;
  VSprintf(0, a1, &varg_r1);
  return 1;
}
При VSprintf(0,..) используется HalSerialPutcRtl8195a()
т.е. вывод в LogUart не буферизирован и DiagPrintf используется для отладки, чтобы распечатать сообщения до точки останова или возникновения ошибки...
Так-же у DiagPrintf нет никаких mutex и semaphores для поддержки в RTOS совместного доступа/вывода в устройство LogUART...
При буферизации и использовании DMA для вывода, сообщение может ещё не вывестись, как уже отработает точка останова или сваливание в "протектед".

int rtl_printf(const char *fmt, ...) имеет:
Код:
  if ( !libc_has_init )
  {
    rtl_libc_init();
    libc_has_init = 1;
  }
Которая:
Код:
void rtl_libc_init()
{
  _rom_mallocr_init_v1_00();
  init_rom_libgloss_ram_map();
}
использует ресурсы области ram-rom.
и
Код:
struct _rom_libgloss_ram_map
{
  int (*libgloss_close)(int);
  int (*libgloss_fstat)(int, stat *);
  int (*libgloss_isatty)(int);
  int (*libgloss_lseek)(int, int, int);
  int (*libgloss_open)(char *, int, int);
  int (*libgloss_read)(int, char *, int);
  int (*libgloss_write)(int, const char *, int);
  void *(*libgloss_sbrk)(int);
};
void init_rom_libgloss_ram_map()
{
  rom_libgloss_ram_map.libgloss_close = ram_libgloss_close;
  rom_libgloss_ram_map.libgloss_fstat = ram_libgloss_fstat;
  rom_libgloss_ram_map.libgloss_isatty = ram_libgloss_isatty;
  rom_libgloss_ram_map.libgloss_lseek = ram_libgloss_lseek;
  rom_libgloss_ram_map.libgloss_open = ram_libgloss_open;
  rom_libgloss_ram_map.libgloss_read = ram_libgloss_read;
  rom_libgloss_ram_map.libgloss_write = ram_libgloss_write;
  rom_libgloss_ram_map.libgloss_sbrk = ram_libgloss_sbrk;
}

 
Последнее редактирование:

sharikov

Active member
DiagPrintf неправильный - имеет в конце return 1 и имеет ограничения связанные с используемыми буферами в области ram-rom от включенных в ROM базовых либ СИ.
return 1 не беспокоит я это никогда не использовал а с буферами могут быть проблемы. Какую область использует DiagPrintf ? Сколько стека используется и какого ? Он буферизированный? Тормозит ли поток пока не выведет всю строку ?

Так-же, при RTOS не всё хорошо с многозадачностью в DiagPrintf, rtl_printf.
Это тоже беспокоит в части буферов данных. Перемешивание строк я как нибудь переживу.

@sharikov - Ищите базовые составляющие vXprintf и собирайте из него правильную printf. Все ваши вопросы подробно расписаны в любом описании стандартных библиотек СИ (stdio.h).
Пошел искать.

Это может быть связано с уже описанным - порче загрузчиком области ram-rom - переменных rtl_impure_ptr и менеджера памяти в ROM.
Вот это предложение особенно неприятно. Как с этим загрузчиком работают амебовские приложения ? Там в половине DiagPrintf а в остальной части перемешаны printf(-->rtl_printf) и DiagPrintf.

Портятся области выделенные malloc.
Обнаружилось когда поднял STATION+AP. Открываю страницу по адресу AP со смартфона после этого не закрывая соединения отключаю wifi на смартфоне потом открываю страницу по ip STATION, потом закрываю вкладку браузера (вызовет закрытие соединения). При использовании DiagPrintf получаю HardFault из-за разрушенных переменных esphttpd core. Без DiagPrintf переменные целы и esphttpd работает. Без манипуляций с отключением от AP при открытом соединении работает.
 

pvvx

Активный участник сообщества
return 1 не беспокоит я это никогда не использовал а с буферами могут быть проблемы. Какую область использует DiagPrintf ? Сколько стека используется и какого ? Он буферизированный? Тормозит ли поток пока не выведет всю строку ?
Ответил уже до вашего вопроса.
На остальное тоже дописал, до вопросов :)
 

pvvx

Активный участник сообщества
Обнаружилось когда поднял STATION+AP.
WiFi тоже использует функции из ROM задействующие ram-rom.
Много-ядерность и много-поточность у printf может приводить к "протектед" и любой шизе. Вы должны сами следить о повторности вызова их, когда одна уже работает...

RAM для функций ROM распределяется через - см. rom_wlan_ram_map.h

И что не понятного в DiagPrintf и совместного использования с ней rtl_printf? DiagPrintf исключительно для отладки с небуферизированным выводом. Всё остальное - как назначите. Вам не о чем не говорит "Diag" ? :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Портятся области выделенные malloc.
По поводу, почему вы используете bootloader до SDK3.4 2015г для версии чипов c ROM, которых не было в свободном доступе, c другой версией SDK (> 3.5) и ROM v01+v02 обращайтесь в Realtek или к продавцу модуля :) :)
Правда и они вас не заставляли вписывать в модуль новый SDK и старый загрузчик, как и беспорядочно использовать хидеры в своем проекте с разными вызовами printf. :)
Обнаружилось когда поднял STATION+AP. Открываю страницу по адресу AP со смартфона после этого не закрывая соединения отключаю wifi на смартфоне потом открываю страницу по ip STATION, потом закрываю вкладку браузера (вызовет закрытие соединения). При использовании DiagPrintf получаю HardFault из-за разрушенных переменных esphttpd core. Без DiagPrintf переменные целы и esphttpd работает. Без манипуляций с отключением от AP при открытом соединении работает.
Вы бы ещё какой детский проект привели, который не работает с RTOS.
Причины ошибок - ваше неверное "портирование".
Вроде всё описал. Теперь поправьте свой проект с esphttpd, да не забудьте, что стандартный printf в ESP вписанный отдельно в закрытые либы (esp_printf_plus) возвращает кол-во выведенных символов и имеет несколько отличий и ошибок в интерпретации всяких %.., а в версии Arduino к ESP printf вообще собран известными халтурщиками и от него ожидать можно чего угодно :) Т.е. напрямую они не "портируются" в другие "балалайки", как и большая часть кода написанного "сообществом" фриков ESP.
Для "портирования" ищите исходные коды, которые вошли в тот проект ESP, и меняете их обратно, согласно первоисточнику. Тогда проект может и заработает на любой "балалайке".
 
Последнее редактирование:

pvvx

Активный участник сообщества
Есть ещё component\common\api\platform\stdlib_patch.c
Там DiagPrintfPatch(), но он не входит в стандартные проекты.
 

sharikov

Active member
Есть ещё component\common\api\platform\stdlib_patch.c
Там DiagPrintfPatch(), но он не входит в стандартные проекты.
DiagPrintfPatch() не помогла --> HardFault. Ну исходники хотя бы есть и определение printf = DiagPrintfPatch. Хоть что-то.
Меня смущает маленький размер TCM Heap - 328 байт. Он становится таким еще при старте сразу после wifi_on().
Код:
URL = /index.tpl
Is url index 0
Is url index 2
Heatshrink compressed file; decode parms = ffffffb4
Pool slot 2 is done. Cleaning up for next req
RAM heap        116736 bytes    TCM heap        328 bytes
httpdDisconCb 192.168.0.3:11978
BUG
Pool slot 0: socket closed.
httpdDisconCb cgi:0x613a6562
RTL8195A[HAL]: Hard Fault Error!!!!
RTL8195A[HAL]: R0 = 0x100612d8
RTL8195A[HAL]: R1 = 0x40003014
RTL8195A[HAL]: R2 = 0xd
RTL8195A[HAL]: R3 = 0x613a6562
RTL8195A[HAL]: R12 = 0x1c
RTL8195A[HAL]: LR = 0x1000980f
RTL8195A[HAL]: PC = 0x613a6562
RTL8195A[HAL]: PSR = 0x20000000
RTL8195A[HAL]: BFAR = 0x8
RTL8195A[HAL]: CFSR = 0x100
RTL8195A[HAL]: HFSR = 0x40000000
RTL8195A[HAL]: DFSR = 0x0
RTL8195A[HAL]: AFSR = 0x0
RTL8195A[HAL]: PriMask 0x0
RTL8195A[HAL]: BasePri 0x0
RTL8195A[HAL]: SVC priority: 0x00
RTL8195A[HAL]: PendSVC priority: 0xf0
RTL8195A[HAL]: Systick priority: 0xf0
Проверил rtl_printf
Она фатальна: в приложении сразу виснет с отключением jtag. В main() работает.
 

pvvx

Активный участник сообщества
Меня смущает маленький размер TCM Heap - 328 байт. Он становится таким еще при старте сразу после wifi_on().
А мне так нравится. На что там вам не хватает места?
Я туда распределил что хотел, стартующее по умолчанию. Если там места нет, то задействуется основной Heap.
Что у вас ещё стартует по умолчанию и не лезет туда? :)
В стандартной SDK 3.5a вообще стоял игнор, что TCM heap кончился. И пофиг всё, что процесс не запустился (главное молча :)).
Он там был заявлен меньшим размером. На все примеры не хватало ^^ "пофиг всё".
LwIP пользовал TCM на статические буфера. Теперь динамические в TCM и обычном Heap. Зачем ему доступ данных без тактов ожидания? :confused: У него трафик до 2- мег в сек.
В TCM я и празместил стеки задач RTOS... Так быстрее работают процессы... процедуры...
RTL00MP3/freertos_service.c at master · pvvx/RTL00MP3 · GitHub
RTL00MP3/tasks.c at master · pvvx/RTL00MP3 · GitHub
...
Вообще для каждого проекта надо делать своё распределение по TCM/SRAM/SDRAM heap, в зависимости от требуемой скорости выполнения - без тактов ожидания, с изредка тактами ожидания при кривости align, тормоз в 16 битную шину доступа к чипу SDRAM с тактами ожидания.

Этой возможности в SDK не было. Счас затычка - если не хватает то берем другую...
Проверил rtl_printf
Она фатальна: в приложении сразу виснет с отключением jtag. В main() работает.
Творите чудеса - у меня так не выходит :)
Вроде она выглядит так (в lib_rtlstd.a:ram_libc.o)
Код:
int rtl_printf(const char *fmt, ...) {
    va_list args;
    va_start (args, fmt);
    if (!libc_has_init) {
        rtl_libc_init();
        libc_has_init = 1;
    }
    int result = __rtl_vfprintf_r_v1_00(_rtl_impure_ptr,
            _rtl_impure_ptr->_stdout, fmt, args);
    __rtl_fflush_r_v1_00(_rtl_impure_ptr, _rtl_impure_ptr->_stdout);
    return result;
}
Где в ней отключение Jtag и распределение памяти, если вывод идет в stdout?
_rtl_impure_ptr есть, он кажет на структуру _reent, в ней есть FILE _stdout, все они сидят в области ram-rom, что вам уже описывал.

PS: реверс исходников lib_rtlstd.a не получите - плохо себя ведете. :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Затруднения с RTL ожидались. На этот случай заранее предусмотрен "план Б":
Посмотреть вложение 3539
Хороший план. Будете первым, кто сделает на ESP стабильное рабочее изделие... :)
Китайцы пытались, кое чего вышло. Но использовали SDK 0.92. Там глюки известны и обходятся. Вышло некоторое время работающее устройство... На постоянную работу всё равно не потянуло.

На RTL я уже сделал. Испытания прошли.
Могу подсказать - есть такая функция (всё там-же, в lib_rtlstd.a):
Код:
// Data declarations
char *heap_end;
//----- ram_libgloss_sbrk()
char *ram_libgloss_sbrk(int incr) {
    char *prev_heap_end;

    if (!heap_end)
        heap_end = (char *) &end;
    prev_heap_end = heap_end;
    heap_end += incr;
    return prev_heap_end;
}
Найдете "end" (он экспорт в либу - extern char end; ) и исправите *.ld.
На RTL8711AM у китайцев уже год выпускаются разные изделия. "Отзывов" вроде нет.
Переходники WiFi-UART вроде тоже работают. К примеру на модулях RAK с RTL8711Ax...
 
Последнее редактирование:

sharikov

Active member
Могу подсказать - есть такая функция (всё там-же, в lib_rtlstd.a):
Код:
// Data declarations
char *heap_end;
//----- ram_libgloss_sbrk()
char *ram_libgloss_sbrk(int incr) {
    char *prev_heap_end;

    if (!heap_end)
        heap_end = (char *) &end;
    prev_heap_end = heap_end;
    heap_end += incr;
    return prev_heap_end;
}
Найдете "end" (он экспорт в либу - extern char end; ) и исправите *.ld.
На RTL8711AM у китайцев уже год выпускаются разные изделия. "Отзывов" вроде нет.
Переходники WiFi-UART вроде тоже работают. К примеру на модулях RAK с RTL8711Ax...
Нужно включить режим Station + AP, поднять оба соединения и дать запросы к httpd. Если только AP проблема не проявляется, без соединения не проявляется.
Как ram_libgloss_sbrk соотносится с pvPortMalloc ?
(уже посмотрел - ram_libgloss_sbrk вызывается дважды из ROM
первый вызов 0x10061130 L=0x418 и второй 0x10061548 L=0xab8. Второе - буфер wifi я там вижу ответы сервера)
У ram_libgloss_sbrk другая область памяти она растет в сторону стека. end объявлен глобально.
 

pvvx

Активный участник сообщества
У ram_libgloss_sbrk другая область памяти она растет в сторону стека. end объявлен глобально.
Она растет в сторону прямо и непосредственно по Heap, т.к. отталкивается от bss, а за ним область heap TCM или в SRAM (смотрие где объявлена :) есть разные варианты *.ld ) . Тем самым затирает разметку первых блоков heap и данных в них :p
Таких приколов в закрытых частях кода SDK более 3-х штук. Один исправил (локализовал и выделил место) - это второй, есть и третий, не считая области ram-rom. А может и больше :)
Похоже это всё сделано спецом. :p
 
Последнее редактирование:

pvvx

Активный участник сообщества
Как ram_libgloss_sbrk соотносится с pvPortMalloc ?
Нашли как? :)
Всякая статистика и прочие процедуры для WiFi смешаны с этим... и с обчными процедурами xpintf(). Буфера кароче... в названии rtl_std_lib уже всё сказано.
Вот вам два файлика, чтобы не расстраивались. Хидера там пока нет, но они работают, у меня. :)
Потестю, причешу bootloader (с ним и всякими *.ld и уже export-rom_v04.txt это всё повязано).

Дополнил до 3-х :) Всё равно не разберетесь... Но хоть отловите кого... Тогда соберу вариант на гит.
Размер роста heap_end определите - не всё же мне одному... Потом дырочку ему сделаем с проверкой в коде (исходник то уже rtl_std_lib есть и рабочий)...
 

Вложения

Последнее редактирование:

sharikov

Active member
не помогло. station+ap упал после отключения клиента от ap при открытом сокете.
Код:
RTL8195A[Driver]: +OnAuth: 68:05:71:7e:be:aa

RTL8195A[Driver]: +OnAssocReq
rtl_printf test 4
rtl_printf test 4
Conn req from  192.168.43.2:27885, using pool slot 1
[httpdConnectCb:819] 0x1005ca38
[httpdConnectCb:827] 0x1005c618
[httpdConnectCb:833] 0x1005c5f8
rtl_printf test 5
httpserver acpt index 1 sockfd 2!
rtl_printf test 4
URL = /index.tpl
Is url index 0
Is url index 2
Is url index 10
/index.tpl not found. 404!
Pool slot 1 is done. Cleaning up for next req
RAM heap        116888 bytes    TCM heap        328 bytes
rtl_printf test 4
rtl_printf test 4
URL = /index.tpl
Is url index 0
Is url index 2
Is url index 10
/index.tpl not found. 404!
Pool slot 1 is done. Cleaning up for next req
RAM heap        116888 bytes    TCM heap        328 bytes
rtl_printf test 4
rtl_printf test 4
URL = /index.tpl
Is url index 0
Is url index 2
Is url index 10
/index.tpl not found. 404!
Pool slot 1 is done. Cleaning up for next req
RAM heap        116888 bytes    TCM heap        328 bytes
rtl_printf test 4
rtl_printf test 4
URL = /index.tpl
Is url index 0
Is url index 2
Is url index 10
/index.tpl not found. 404!
Pool slot 1 is done. Cleaning up for next req
RAM heap        116888 bytes    TCM heap        328 bytes
rtl_printf test 4
rtl_printf test 4
URL = /index.tpl
Is url index 0
Is url index 2
Is url index 10
/index.tpl not found. 404!
Pool slot 1 is done. Cleaning up for next req
RAM heap        116888 bytes    TCM heap        328 bytes
rtl_printf test 4

RTL8195A[Driver]: ap recv deauth reason code(3) sta:68:05:71:7e:be:aa
rtl_printf test 4
BUG
RTL8195A[HAL]: Hard Fault Error!!!!
RTL8195A[HAL]: R0 = 0x1005bdf0
RTL8195A[HAL]: R1 = 0x40003014
RTL8195A[HAL]: R2 = 0x3a65373a
RTL8195A[HAL]: R3 = 0x47
RTL8195A[HAL]: R12 = 0x12
RTL8195A[HAL]: LR = 0x10008e03
RTL8195A[HAL]: PC = 0x1000964a
RTL8195A[HAL]: PSR = 0x21000000
RTL8195A[HAL]: BFAR = 0x3a653b3a
RTL8195A[HAL]: CFSR = 0x8200
RTL8195A[HAL]: HFSR = 0x40000000
RTL8195A[HAL]: DFSR = 0x0
RTL8195A[HAL]: AFSR = 0x0
RTL8195A[HAL]: PriMask 0x0
RTL8195A[HAL]: BasePri 0x0
RTL8195A[HAL]: SVC priority: 0x00
RTL8195A[HAL]: PendSVC priority: 0xf0
RTL8195A[HAL]: Systick priority: 0xf0
Ну хотя бы оно запускается и даже rtl_printf печатает.

---
UPD
Поспешил. Не всегда работает. Проблемы с подключением к точке доступа.
Подключается и отключается, непрерывно пишет в лог "Cannot allocate pbuf to receive packet"
 
Последнее редактирование:

pvvx

Активный участник сообщества
не помогло. station+ap упал после отключения клиента от ap при открытом сокете.
Ну хотя бы оно запускается и даже rtl_printf печатает.
---
UPD
Поспешил. Не всегда работает. Проблемы с подключением к точке доступа.
Какие проблемы? Не подключается?
С чем боритесь то?
С повторным вхождением в printf? Или что? Тема вроде про printf...
От куда в программе может быть “протектед” – что-то не проинициализировали перед обращением или сами так что написали в коде…
В данном SDKвсё написано тупенько, классически.
Ошибки есть, но тоже тупенькие - просто забыто что-то. Вы их исправили перед сборкой своего проекта? Уже указывал на них...
Подключается и отключается, непрерывно пишет в лог "Cannot allocate pbuf to receive packet"
Что вы забыли в ethernetif_recv() или ethernetif_mii_recv()? :confused:
Прикручиваете внешнюю изернет phy?
Или пытаетесь в закрытый интерфейс "wlan" передать что-то? :)
Гадать можно долго, что вы там творите, но скорее всего, пытаетесь что-то принять или отослать через LwIPв отсутствующее, не активное или не проинициализированное netifсоединение. И делаете это с упорством :) Он вам жалуется:

// Allocate buffer to store received packet
p = pbuf_alloc(PBUF_RAW, total_len, PBUF_POOL);
if (p == NULL) {
printf("\n\rCannot allocate pbuf to receive packet");
return; }
А может не принимаете данные, застолбив все буфера LwIP. Нехорошо так издеваться с LwIP :)
 
Последнее редактирование:

sharikov

Active member
Какие проблемы? Не подключается?
С чем боритесь то?
С повторным вхождением в printf? Или что? Тема вроде про printf...
От куда в программе может быть “протектед” – что-то не проинициализировали перед обращением или сами так что написали в коде…
Борюсь с неработоспособностью под нагрузкой.
С "Cannot allocate pbuf to receive packet" разобрался: переносил соединение с wifi в отдельный файл и забыл инициализировать Lwip. Ему это не нравилось.

Проблема printf остается.
Проблема разрушения памяти остается.
 

pvvx

Активный участник сообщества
Проблема printf остается.
Проблема разрушения памяти остается.
Но эти проблемы только у вас. И в связи с чем вы тоже скрываете. :)
Размер роста heap_end так и не дали. Это наверно к рекомендации не давать мне больше ничего в открытые источники? :)

У вас проблемы с этим -> printf — Википедия ?
 
Последнее редактирование:

pvvx

Активный участник сообщества
Проблема разрушения памяти остается.
Включите вывод отладки в SDK и с запросами памяти TCM будет всё видно:
Код:
CLK CPU         100000000 Hz
RAM heap        84240 bytes
TCM heap        64768 bytes
RAM Heap Memory List:
 [0]=0x0x10057600, 0
 [1]=0x0x10002360, 15512
 [2]=0x0x1005f3e0, 68632
TCM Free List:
 prev 100577f4, chunk 1fff0000, size 64768

[TCM Inf]allocmem(804)
[TCM Inf]allocmem(5124)
[TCM Inf]allocmem(4004)
interface 1 is initialized
interface 0 is initialized
Initializing WIFI ...
[TCM Inf]allocmem(6092)
[TCM Inf]allocmem(3748)
Initial Spi Flash Controller
[SPIF Inf]SpicWaitWipDoneRefinedRtl8195A(0x1)
...
[SPIF Inf]SpicRxCmdRefinedRtl8195A(0x5, 0x100543e0)
[TCM Inf]allocmem(800)
[TCM Inf]allocmem(944)
[TCM Inf]allocmem(3400)
[TCM Inf]allocmem(744)
[TCM Inf]allocmem(744)
[TCM Inf]allocmem(540)
[TCM Inf]allocmem(1672)

Start LOG SERVICE MODE

[TCM Inf]allocmem(5892)
[TCM Inf]allocmem(1028)
[TCM Inf]allocmem(1028)
[TCM Inf]allocmem(2052)
[TCM Inf]allocmem(2052)
[TCM Inf]allocmem(1028)
[TCM Inf]allocmem(1028)
Time at start 1687 ms.
WIFI initialized
[FEEP Inf]read obj id: 5730[280]
[FEEP Inf]base seg: 0xfe000 [-1]
[FEEP Inf]read ok, faddr: 0xfe354, size: 280

RTL8195A[Driver]: set ssid [*****]
wifi_indication(): WIFI_EVENT_SCAN_DONE
Time at start 2976 ms.
RTL8195A[Driver]: start auth to bc:ae:c5:eb:09:90
...
Interface 0 IP address: 192.168.1.122
Time at start 3805 ms.
[FEEP Inf]read obj id: 4c30[44]
[FEEP Inf]base seg: 0xfe000 [-1]
[FEEP Inf]obj not found
[FEEP Inf]read obj id: 5530[8]
[FEEP Inf]base seg: 0xfe000 [-1]
[FEEP Inf]read ok, faddr: 0xfe470, size: 8

AT_UART_CONF: 38400,8,1,0,0
[UART Inf]HalRuartInitRtl8195a: [UART 2] PinSel=0
...
[UART Inf]HalRuartGenBaudRateRtl8195a: BaudRate:9600 Divisor:548 Ovsr:19 Ovsr_ADj:0x0
...
[GPIO Inf]HAL_GPIO_IntCtrl_8195a: port_num=0 pin_num=0 pin_mode=135
[GPIO Inf]GPIO_Int_SetType_8195a: level_edge=1 polarity=0
[GPIO Inf]GPIO RegWrite: Reg[0x38] = 0x1
[GPIO Inf]GPIO RegWrite: Reg[0x3c] = 0x0
[GPIO Inf]GPIO RegWrite: Reg[0x30] = 0x1
# ATSW=c
LoadWifiConfig(): Read from FLASH!
LoadWifiConfig(): local_config.boot_mode=0x77665502
LoadWifiConfig(): local_config.ssid=RTL8710
LoadWifiConfig(): local_config.channel=1
LoadWifiConfig(): local_config.security_type=1
LoadWifiConfig(): local_config.password=0123456789
WEB:Enter start web server!
[MEM] After do cmd, available heap 65464+21992
LwIP_DHCP: dhcp stop.
Deinitializing WIFI ...
 wifi_indication():Disconnection indication received
WIFI deinitialized
Initializing WIFI ...
[TCM Inf]allocmem(6092)
[TCM Inf]allocmem(3748)
[TCM Inf]allocmem(2384)
[TCM Inf]allocmem(944)
[TCM Inf]allocmem(3400)
[TCM Inf]allocmem(744)
[TCM Inf]allocmem(744)
[TCM Inf]allocmem(540)
[TCM Inf]allocmem(4168)
[TCM Inf]allocmem(5892)
[TCM Inf]allocmem(1028)
[TCM Inf]allocmem(1028)
[TCM Inf]allocmem(2052)
[TCM Inf]allocmem(2052)
[TCM Inf]allocmem(1028)
[TCM Inf]allocmem(1028)
WIFI initialized
wifi_indication():Connect indication received: 00:fffffff8:ffffff87:11:00:12
# ATST
CLK CPU         100000000 Hz
RAM heap        64032 bytes
TCM heap        17912 bytes
RAM Heap Memory List:
 [0]=0x0x10057600, 0
 [1]=0x0x100605d8, 64032
TCM Free List:
 prev 100577f4, chunk 1fff0000, size 17912
Не думаю, что там какие-то ошибки, кроме ваших...
 
Сверху Снизу