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

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

S

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

pvvx

Активный участник сообщества
sharikov написал(а):
Пытаюсь прошить работающее в рам приложение во флэш. Не стартует.
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".
 
Последнее редактирование:
S

sharikov

Active member
pvvx написал(а):
Ничего не понятно. :)
В 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

pvvx

Активный участник сообщества
sharikov написал(а):
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
 
Последнее редактирование:
S

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

pvvx

Активный участник сообщества
sharikov написал(а):
Заработало.
Почему то проц работает на 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...
 
Последнее редактирование:
S

sharikov

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

pvvx

Активный участник сообщества
sharikov написал(а):
Запустил на 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 возникает (набегает) ошибка в счете времени (халтурщики).
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу