• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Из флэш не стартует

sharikov

Active member
Пытаюсь прошить работающее в рам приложение во флэш. Не стартует.
SDK и скрипты из RTL00MP3.

=========================================================

ROM Version: 0.3

Build ToolChain Version: gcc version 4.8.3 (Realtek ASDK-4.8.3p1 Build 2003)

=========================================================
Check boot type form eFuse
SPI Initial
Image1 length: 0x3a98, Image Addr: 0x10000bc8
Image1 Validate OK, Going jump to Image1
BOOT from Flash:YES
===== Enter Image 1 ====

load NEW fw 0
Flash Image2:Addr 0xb000, Len 249508, Load to SRAM 0x10006000
No Image3
Img2 Sign: RTKWin, InfaStart @ 0x1000604d
===== Enter Image 2 ====
RTL8195A[HAL]: Hard Fault Error!!!!
RTL8195A[HAL]: R0 = 0x0
RTL8195A[HAL]: R1 = 0x4
RTL8195A[HAL]: R2 = 0x40002004
RTL8195A[HAL]: R3 = 0x3040
RTL8195A[HAL]: R12 = 0x1c
RTL8195A[HAL]: LR = 0x100060b3
RTL8195A[HAL]: PC = 0x100079c4
RTL8195A[HAL]: PSR = 0x1000200
RTL8195A[HAL]: BFAR = 0x8
RTL8195A[HAL]: CFSR = 0x10000
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: 0x00
RTL8195A[HAL]: Systick priority: 0x00


пошаговый проход с помощью jtag показал что падает в функции InfraStart(void) на вызове InitSoCPM();
в теле последней дизассемблер показывает "UNDEFINED INSTRUCTION". Дамп этой области = 0xff. Видимо не прошилась. Шил jflash, видимо она не попала в ram_all.bin
 

pvvx

Активный участник сообщества
Пытаюсь прошить работающее в рам приложение во флэш. Не стартует.
SDK и скрипты из RTL00MP3.
Ничего не понятно. :)
В RAM elf работает или bin-бинарник?
пошаговый проход с помощью jtag показал что падает в функции InfraStart(void) на вызове InitSoCPM();
в теле последней дизассемблер показывает "UNDEFINED INSTRUCTION". Дамп этой области = 0xff. Видимо не прошилась. Шил jflash, видимо она не попала в ram_all.bin
Какая-то секция (сегмент) не вписан в *.ld (т.е. вписан, но в другую область - к примеру TCM)?
Загрузчик грузится в TCM RAM при отладке. В бинарнике, при загрузке с Flash этого не требуется...
Откройте файлы *.map и *.nmap и посмотрите куда и чего в вашем проекте мапиться...
У InitSoCPM() секция ".text.InitSoCPM".
 
Последнее редактирование:

sharikov

Active member
Ничего не понятно. :)
В RAM elf работает или bin-бинарник?
Бинарник.
monitor load_image build/bin/ram_1.r.bin 0x10000bc8 bin
monitor load_image build/bin/ram_2.bin 0x10006000 bin
monitor reset halt
monitor mww 0x40000210 0x20200113
...

Какая-то секция (сегмент) не вписан в *.ld (т.е. вписан, но в другую область - к примеру TCM)?
Загрузчик грузится в TCM RAM при отладке. В бинарнике, при загрузке с Flash этого не требуется...
Откройте файлы *.map и *.nmap и посмотрите куда и чего в вашем проекте мапиться...
У InitSoCPM() секция ".text.InitSoCPM".
ld из RTL00MP3 я его не трогал.
Поменял генератор бинарников на амебовский под линукс с их же загрузчиком.
(потому что почти все скрипты не полностью либо неправильно генерят image header)
Стало веселее. Теперь все грузится (слил дамп озу), доходит до main, выполняет его и при запуске шедулера не запуская его выходит из main

/*Enable Schedule, Start Kernel
if(rtw_get_scheduler_state() == OS_SCHEDULER_NOT_STARTED)
vTaskStartScheduler();
else
vTaskDelete(NULL);

выполняется по ветке vTaskDelete(NULL);
после чего виснет
 

pvvx

Активный участник сообщества
ld из RTL00MP3 я его не трогал.
Поменял генератор бинарников на амебовский под линукс с их же загрузчиком.
(потому что почти все скрипты не полностью либо неправильно генерят image header)
Смысл действий и что делаете опять не ясно, и что неправильно генерят?
src pick · pvvx/RTL00MP3@34d4d9f · GitHub
add & fix (pick.exe) tools · pvvx/RTL00MP3@c6b52fd · GitHub

C последними файлами от Ameba ram_1.p.bin и ram_1.r.bin не работает на модуле RTL00 SDK и rtlDuino. Уже писал про это. А их вариант Arduino - не проверял.
Я гоняю Flash на DIO, а они в режиме SIO :)
У них Spic настраивается по другому, наверно для 8195 с внешней Flash - Расширенные команды и опции для Flash в Spic загружаются другие... Чего-то ещё...
Ситуацию с Flash не разрулите, пока не сделаете исходники к hal_spi_flash_ram.c и правильный hal_spi_flash.h :)
А пока там бардак, что и к какому чипу... :p
 
Последнее редактирование:

sharikov

Active member
Заработало.
Код:
=========================================================

ROM Version: 0.3

Build ToolChain Version: gcc version 4.8.3 (Realtek ASDK-4.8.3p1 Build 2003)

=========================================================
Check boot type form eFuse
SPI Initial
Image1 length: 0x3a98, Image Addr: 0x10000bc8
Image1 Validate OK, Going jump to Image1
BOOT from Flash:YES
===== Enter Image 1 ====

load NEW fw 0
Flash Image2:Addr 0xb000, Len 249480, Load to SRAM 0x10006000
No Image3
Img2 Sign: RTKWin, InfaStart @ 0x1000604d
===== Enter Image 2 ====
GPIO init
Main start

CLK CPU         83333333 Hz
RAM heap        165416 bytes    TCM heap        43184 bytes
interface 1 is initialized
interface 0 is initialized
Initializing WIFI ...
WLAN_AP_ACTIVATE_
LwIP_DHCP: dhcp stop.
Deinitializing WIFI ...
[rltk_wlan_deinit] Wait for RxStop
WIFI deinitialized
Initializing WIFI ...
WIFI initialized
Starting AP ...
RTL8710 started
WIFI initialized
espFsInit=0
esphttpd: active and listening to connections.
Httpd init
RAM heap        127176 bytes    TCM heap        2264 bytes

RTL8195A[Driver]: +OnAuth: 68:05:71:7e:be:aa

RTL8195A[Driver]: +OnAssocReq
Conn req from  192.168.3.2:42199, using pool slot 0
httpserver acpt index 0 sockfd 1!
URL = /index.tpl
Is url index 0
Is url index 2
Heatshrink compressed file; decode parms = 4
Pool slot 0 is done. Cleaning up for next req
RAM heap        135536 bytes    TCM heap        2264 bytes
URL = /style.css
Is url index 0
Is url index 10
Heatshrink compressed file; decode parms = 4
Conn req from  192.168.3.2:42455, using pool slot 1
httpserver acpt index 1 sockfd 2!
Pool slot 0 is done. Cleaning up for next req
RAM heap        134792 bytes    TCM heap        2264 bytes
Conn req from  192.168.3.2:42711, using pool slot 2
httpserver acpt index 2 sockfd 3!
URL = /cats/cross-eyed-cat.jpg
Is url index 0
Is url index 10
Conn req from  192.168.3.2:42967, using pool slot 3
httpserver acpt index 3 sockfd 4!
URL = /cats/junge-katze-iv.jpg
Is url index 0
Is url index 10
URL = /cats/kitten-loves-toy.jpg
Is url index 0
Is url index 10
Pool slot 2 is done. Cleaning up for next req
RAM heap        134728 bytes    TCM heap        2264 bytes
Pool slot 1 is done. Cleaning up for next req
RAM heap        134760 bytes    TCM heap        2264 bytes
Pool slot 3 is done. Cleaning up for next req
RAM heap        134792 bytes    TCM heap        2264 bytes
Надо было обновить pick (и заодно обновил checksum).
Почему то проц работает на 83MHz хотя при отладке в рам на 166. Разберусь позже.
make -f flasher.mk flashweb затирает калибровку потому что флэшер openocd пишет все без обхода системных областей. Надо писать раздельно image1 и image2. Или допилить флэшер чтобы обходил калибровку.

pick.cpp без изменений не собирается под линукс (там пару строчек поменять). Вы обновите чтобы был платформонезависимым или брать амебовский / вставлять свой ?
pick.cpp в репе RTL00MP3 поэтому лучше чтобы вы его поправили чтобы не разводить бардак и весь sdk брать из одного источника.
 

pvvx

Активный участник сообщества
Заработало.
Почему то проц работает на 83MHz хотя при отладке в рам на 166. Разберусь позже.
По тому что по разным веткам в бут стартует и в ветке старта с flash в SDK 3.4 вписали:
Код:
void __attribute__((section(".hal.ram.text"))) SYSCpuClkConfig(int ChipID, int SysCpuClk) {
    int flg = 0;
    DBG_SPIF_INFO("SYSCpuClkConfig(0x%x)\n", SysCpuClk);
    if(HAL_PERI_ON_READ32(REG_SOC_FUNC_EN) & BIT_SOC_FLASH_EN) {
        SpicWaitWipRtl8195A(); //_SpicWaitWipDoneRefinedRtl8195A(); ???
       flg = 1;
    }
//    if (ChipID == CHIP_ID_8710AF && (!SysCpuClk)) SysCpuClk = 1; <---------- вот эту бяку
    HalCpuClkConfig(SysCpuClk);
    HalDelayUs(1000);
    StartupHalInitPlatformLogUart();
    if (flg) {
        SpicOneBitCalibrationRtl8195A(SysCpuClk); // extern u32 SpicOneBitCalibrationRtl8195A(IN u8 SysCpuClk);
/* разные версии
        // Disable SPI_FLASH User Mode
       HAL_SPI_WRITE32(REG_SPIC_SSIENR, 0);
        HAL_SPI_WRITE32(REG_SPIC_VALID_CMD,
                (HAL_SPI_READ32(REG_SPIC_VALID_CMD)|(FLASH_VLD_DUAL_CMDS))); */
        SpicCalibrationRtl8195A(StartupSpicBitMode, 0);
    }
}
Надо же маркетинг поддерживать - RTL8711AF должен быть дороже RTL8710AF (хотя пока найдены различия всего в оттиске краски на пластике чипа).
RTL8710AF уверенно работает на 200MHz - тесты сутками.
RTL871x - OverClock CPU Можно и больше, но оставил для "энтузиастов" :)
200 MHz вообще для данного SoC предусмотрены в ROM. RTL871xAF не нагружен - у него мозгов меньше включено и тактируется - тепловые нагрузки меньше чем у 8195.
Возможно на конвейере стоит сортировка по току потребления на RTL8711AF и RTL8710AF...
 
Последнее редактирование:

sharikov

Active member
Запустил на 166 из флэш.
Все таки он немножко греется в режиме AP. Конечно не кипятильник как esp.
 

pvvx

Активный участник сообщества
Запустил на 166 из флэш.
Все таки он немножко греется в режиме AP. Конечно не кипятильник как esp.
Ну WiFi же. Вынь и положъ пол Вт на данной технологии nm.
Шкалу соотношения MHz/потребление CPU я же почти нарисовал - https://esp8266.ru/forum/attachments/clk_cpu_power-gif.2122/ Замер потребления RTL00 V1.0. - 13 mA разницы от CLK CPU =0 до 166MHz (но надо уточнять - в том тесте были не корректированы клоки для периферии CPU - они могли и дать сильную разницу - тому-же SPIC и прочим контроллерам делители не корректировались)
CPU - это всего до четверти от WiFi в режиме передачи...
По рисунку видите, что при 166 RTL8710AF в режиме без троттлинга превышает потребление ESP8266 в режиме пониженного потребления :). В SDK 3.3 ещё не было включено кода режимов снижения потребления, а всяким хотелкинам надо было показать, что RTL жрет меньше ESP8266 :)
При этом не поправил счетчики-корректоры тиков в SDK для sleep режимов. Они рассчитаны на 166 MHz и при 83 MHz возникает (набегает) ошибка в счете времени (халтурщики).
 
Последнее редактирование:
Сверху Снизу