MEM CHECK FAIL!!!

Johnes · 20 Мар 2015

При написании своей прошвки словил перезагрузку модуля и вывод в UART строки "MEM CHECK FAIL!!!"

Кто нибудь знает о чем мне пытается сказать модуль? .... или где можно почитать про это.

Andy Korg · 20 Мар 2015

Не обращайте внимания. "MEMCHECKFAIL!!!" - это привет по китайски

Johnes · 20 Мар 2015

т.е. это у них такая бага?

Victor · 20 Мар 2015

незанятые прошивкой области флеш забейте нулями, в AT прошивке это помогает

Johnes · 20 Мар 2015

Я просто подумал может я за стек вываливаюсь или еще чаго то порчу.
Ладно ....... тогда осталось разобраться с перезагрузкой, но тут мне кажеться уже виноват watchdog.

pvvx · 17 Апр 2015

Вообще-то: "RTC MEM CHECK FAIL!!!\n"
Процедура: register_chipv6_phy(&esp_init_data_default);
Если вызов rtc_mem_check(1) != 0, то выводится это сообщение, означающее что данные в RTC памяти сбиты, скорее всего из-за отсутствия питания на ножке VDD_RTC.
Т.е. она говорит, что у вас не полноценный модуль

rtc_mem_check(1) делает OR всех 32-х битных слов в памяти часов 0x60001000..60001074 и сравнивает результат по адресу 0x60001078, и если не равны, то китайцы считают, что "RTC MEM CHECK FAIL!!!\n"
rtc_mem_check(0) пересчитывает 32-х битные слово "OR" указанной области и пишет его по адресу 0x60001078.
Это всё адреса RTC_RAM.
Только китайские программисты из Espressif считают контрольную сумму путем OR

Код:

int ICACHE_FLASH_ATTR rtc_mem_check(int flg)
{
    volatile uint32 * ptr = (volatile uint32 *)RTC_RAM_BASE;
    uint32 region_or = 0;
    while(ptr != (volatile uint32 *)(RTC_RAM_BASE + 0x78)) region_or |= *ptr++;
    if(flg==false) {
        *ptr = region_or;
        return false;
    }
    return (*ptr != region_or);
}

И так всё сделано в SDK, что писано Espressif. По этому они исходников не дают - там полный ... детсад кароче...
И не удивительно, что они отлаживают свой SDK уже год и отладить не могут.

Johnes · 17 Апр 2015

Спасибо за исчерпавающую инфу ))
Буду посмотреть на модуль, как там разводка сделана.

pvvx · 17 Апр 2015

Johnes написал(а):
Буду посмотреть на модуль, как там разводка сделана.

Вывод питания часиков не выведен ни на одном китайском модуле для продажи. Всё схвачено - вы должны постоянно покупать новые модули

а они будут вечно писать новые поправки для SDK. В этом весь смысл игры.

Johnes · 17 Апр 2015

обидно .... ну как я понял - можно и с этим жить.

pvvx · 17 Апр 2015

Johnes написал(а):
тогда осталось разобраться с перезагрузкой, но тут мне кажеться уже виноват watchdog.

Уже добрался до него. Вырезайте из libmain.a app_main.o и вставляйте свой. Типа "исходники" на замену app_main.o даны в свалке
Смотрите Web_Base4\lib\newmmain.bat - оно удаляет app_main.o и spi_flash.o из libmain.a.
Это замещается, у меня, Web_Base4\app\web\app_main.c + wdt.c + flash.c.
В wdt.c переписываете на свой лад и модуль никогда не зависнет, если не будете запускать что-то хитрое, управляющее спец. внутренностями чипа (типа общий pll вырубить или отключить всё в нутрях...

Текущая версия app_main.c + wdt.c + flash.c пока оставлена совместимая с китай-SDK. Дальнейшие могут быть уже не совместимы, когда ещё чего заменю в SDK

Johnes · 17 Апр 2015

Спасибо и за эту инфу...... я сейчас немного отложил в сторону esp8266 и упражняюсь с stm32f103. Но как вернусь к этому модулю - так обязательно воспользуюсь вашим вариантом по замене app_main

jmms · 10 Июн 2015

Переодически ловлю данное сообщение при разработке на C++, используя github.com/esp8266/Arduino.
Оно бы нечего, но мне переодически нужно чтобы девайс самостоятельно перезагрузился, а перезагрузка иногда стопорится как раз на этом сообщении.
Можете что ни будь посоветовать на данный счет? Оговорюсь, что я не опытен и править исходники SDK без руководства со стороны не имею возможности. И хорошо бы, если рецепт и есть, запушить его или китайцам или в сообщество github.com/esp8266/Arduino, так все разработчики получат более стабильный код, вместо того чтобы самостоятельно дебажить этот момент.

pvvx · 10 Июн 2015

jmms написал(а):
Переодически ловлю данное сообщение при разработке на C++, используя github.com/esp8266/Arduino.
Оно бы нечего, но мне переодически нужно чтобы девайс самостоятельно перезагрузился, а перезагрузка иногда стопорится как раз на этом сообщении.
Можете что ни будь посоветовать на данный счет?

Перепишите китай-SDK и/или сделайте отдельное питание на VCC_RTC. Проблема неисправимая - контрольная сумма начальной области в RAM-RTC c RF параметрами в китай-SDK считается неправильно и алгоритм работы с ней тоже не верен, даже если изменить метод подсчета и сдалеть правильную CRC. Китайцам это не объяснить.

jmms · 10 Июн 2015

pvvx написал(а):
Перепишите китай-SDK и/или сделайте отдельное питание на VCC_RTC. Проблема неисправимая - контрольная сумма начальной области в RAM-RTC c RF параметрами в китай-SDK считается неправильно.

А есть шанс / возможность намекнуть китайцам на более грамотное решение (если конечно у вас есть это решение), подсчета контрольной суммы?

pvvx · 10 Июн 2015

jmms написал(а):
А есть шанс / возможность намекнуть китайцам на более грамотное решение (если конечно у вас есть это решение), подсчета контрольной суммы?

Это невозможно

Они этого не хотят и этого сообщения "MEM CHECK FAIL!!!" у них нет, т.к. в данный момент при старте модуля ещё не вышел Pll на нормальную частоту и у них в кодах стоит сбросить буфер fifo UART сразу после вывода туда этого сообщения. Но другая ветка старта, если не производится перестройка PLL или сменена процедура вывода в os_printf всё-таки выводит это сообщение и от него нет избавления, т.к. другие процедуры в SDK рушат их-же контрольную китай-OR сумму, без дальнейшего пересчета.

Пересчет китай-OR контрольки есть только в пару процедур, но данные то кто восстановит?

После старта c MEM CHECK FAIL!!!, запустите deep_sleep - часто помогает, т.к. там, в процедуре входа в deep_sleep эта область переписывается и вешается новая OR-китай контролька. В AT и других прошивках необходимо сменить установки связанные WiFi, тогда, при следующем старте без отключения питания или использования CH_PD (софт-перезагрузке) сообщение пропадет.
Но и это теперь не всегда срабатывает, т.к. в SDK от 1.1.0 они вписали новый баг, связанный с user_rf_pre_init(). Она рушит OR-китай контрольку по рандому...
Немного помогает это:

Код:

 void ICACHE_FLASH_ATTR user_rf_pre_init(void)
{
    /* volatile */ uint32 * ptr_reg_rtc_ram = (/* volatile */ uint32 *)0x60001000;
    if((ptr_reg_rtc_ram[24] >> 16) > 4) {
        ptr_reg_rtc_ram[24] &= 0xFFFF;
        ptr_reg_rtc_ram[30] = 0;
    }
}

Производиться проверка, какой режим установлен для RF, и если он более 4-го, то значит старт произошел после обесточенной RAM в RTC, тогда исправляем режим на режим по умолчанию (=0 - будет браться в esp_init_data_default.bin) и сбрасываем OR-китай-контрольку, чтобы явно указать, что там неверные данные...
Часть кода китай-SDK c нововведением user_rf_pre_init() и OR-контролькой описана тут https://github.com/pvvx/esp8266web/blob/master/info/libs/main/bags_Espressif_SDK.c#L10

pvvx · 10 Июн 2015

И не стоит описывать эту проблему китайцам. Они тогда впишут новый баг и на "исправление" затратят ещё килобайты памяти 'heap' и для кода во flash. Все "исправления" указанные им были сделаны только исключительно таким образом, особенно по программе "вы Баунти" для лохов.

В итоге имеем раздувшийся до неприличных размеров китай-SDK с тысячами багами...

jmms · 10 Июн 2015

pvvx написал(а):
И не стоит описывать эту проблему китайцам. Они тогда впишут новый баг и на "исправление" затратят ещё килобайты памяти 'heap' и для кода во flash. Все "исправления" указанные им были сделаны только исключительно таким образом, особенно по программе "вы Баунти" для лохов. В итоге имеем раздувшийся до неприличных размеров китай-SDK с тысячами багами...

Да... Однозначно печально. Я попробую разобраться в том, что вы описали. Большое спасибо за проделываемую работу и за подробный разбор. Пока не могу ответить уверенно, что понял где и что нужно править, но информация отложилась, а значит когда дойду до этого момента - будет где подсмотреть.
Насчет взаимодействия с китайцами, если есть опыт (при условии что он действительно глубокий) и можно сделать работу "за китайцев" (хотя это конечно не всем нравиться делать работу за кого то), выпустить патч для их SDK с исправлением этого момента, и отправить его китайцам, приправив текстом на английском что к чему. Тогда есть шанс, что патч примут "как есть", не наплодив новых багов. Но это процесс кропотливый и очень жаль, что у китайцев нет гитхаба с SDK, да и жаль, что они такие "замкнутые" что ли.
Тем не менее если такую работу все таки проделать - это очень сильно поднимет общую стабильность ESP, уровень доверия к ESP.

pvvx · 10 Июн 2015

jmms написал(а):
Тем не менее если такую работу все таки проделать - это очень сильно поднимет общую стабильность ESP, уровень доверия к ESP.

Этот процесс пока не возможен. Во первых китай-SDK состоит из 90% кода взятого с open-source с нарушением лицензий. Во вторых школа программирования в Китае ещё не поставлена, а текущий подход к этому у них смешон (до популярных баек). В третьих руководство Espressif не хочет нанять нормальных программистов - удавяться от пару центов. В четвертых у них другая цель - привязать вас к их сайту IoT всеми возможными путями и создавать такой SDK, чтобы был постоянный "пиар", за счет "обновления" (исправления) и чтоб каждая новая версия требовала новой реализации модуля с целью увеличения продаж тестовых партий не отлаженных чипов (метод оплаты разработки чипа за счет пользователей). В итоге ситуация неизлечима в ближайшие годы...

jmms · 10 Июн 2015

pvvx, Раз уж в этой теме обсуждались глюки, возникающие при загрузке, то хотел спросить: у меня включен WDT, и по наступлению определенных условий происходит [inline]ESP.reset();[/inline], в консоле я вижу: [inline]wdt reset[/inline], но на самом деле ESP не перезагружается, но переодически перезагрузка работает нормально. В чем может быть проблема? Может быть необходимо подтянуть RST?

IAlex · 27 Ноя 2015

Умные товарищи, просветите народ, какое напряжение типовое и максимальное вы подаете на XPD_DCDC и что он делает при логической единице и логическом нуле? А так же какое типовое и максимальное напряжение на VCC_RTC? (или какое вы сами использовали при котором модуль не перегорал)

MEM CHECK FAIL!!!

New member

Moderator

New member

Administrator

New member

Активный участник сообщества

New member

Активный участник сообщества

New member

Активный участник сообщества

New member

Moderator

Активный участник сообщества

Moderator

Активный участник сообщества

Активный участник сообщества

Moderator

Активный участник сообщества

Moderator

New member