UDK: Общие баги/глюки/проблемы

alexhi · 25 Июн 2015

Поставил UDK 2.0.6 при компиляции пишет:
C:/Espressif/examples/blinky/Makefile:225: recipe for target 'build/app.out' failed
mingw32-make.exe: *** [build/app.out] Error -2146232576

В чем может быть дело?

Отвечу сам себе,может у кого то тоже вылезет
закоментил строку в makefile
#$(Q) $(SDK_TOOLS)/memanalyzer.exe $(OBJDUMP).exe $@
и все заработало. Почему не знаю.

pvvx · 26 Июн 2015

Есть глюк у esptool и он проявляется при компиляции с указанием ошибки в строке 666

Что-то не стыкуется с форматом int в 16-тиричом формате в elf - связана с некорректным разбором формата elf. Устраняется только изменением проекта и новой компиляцией.
Лог не прилагаю, т.к. ошибка не частая и она в глубинах обработчиков...

Так-же есть глобальная ошибка в компиляторе UDK - компиляция с опций -Os дает неработающий код для ESP8266. В основном это проявляется на больших проектах, а не в HelloWord.
И размер кода при -O2 в UDK выходит меньше, чем при -O3. Тоже странность.

alexhi · 26 Июн 2015

alexhi написал(а):
Поставил UDK 2.0.6 при компиляции пишет:
C:/Espressif/examples/blinky/Makefile:225: recipe for target 'build/app.out' failed
mingw32-make.exe: *** [build/app.out] Error -2146232576

В чем может быть дело?

Отвечу сам себе,может у кого то тоже вылезет
закоментил строку в makefile
#$(Q) $(SDK_TOOLS)/memanalyzer.exe $(OBJDUMP).exe $@
и все заработало. Почему не знаю.

"Зуда" почему? сработала

. Memanalyzer.exe не захотел работать с NET 4.0,поставил NET3.5 все заработало.(Windows XP SP3)

pvvx · 2 Июл 2015

Вот глюк 666 (опять поймал - никак не создать bin):

Код:

c:/Espressif/utils/esptool.exe elf2image .output/eagle/debug/image/eagle.app.v6.out -o ..//bin//
Traceback (most recent call last):
  File "esptool.py", line 666, in <module>
  File "esptool.py", line 429, in get_symbol_addr
  File "esptool.py", line 426, in _fetch_symbols
ValueError: invalid literal for int() with base 16: 'U'
../Makefile:181: recipe for target '.output/eagle/debug/bin/eagle.app.v6.bin' failed

jcmvbkbc · 2 Июл 2015

pvvx написал(а):

Вот глюк 666 (опять поймал - никак не создать bin):

Код:

c:/Espressif/utils/esptool.exe elf2image .output/eagle/debug/image/eagle.app.v6.out -o ..//bin//
Traceback (most recent call last):
  File "esptool.py", line 666, in <module>
  File "esptool.py", line 429, in get_symbol_addr
  File "esptool.py", line 426, in _fetch_symbols
ValueError: invalid literal for int() with base 16: 'U'
../Makefile:181: recipe for target '.output/eagle/debug/bin/eagle.app.v6.bin' failed

Попробуй применить следующий дифф к функции _fetch_symbols:

Код:

diff --git a/esptool.py b/esptool.py
index 93ab071..2a83193 100755
--- a/esptool.py
+++ b/esptool.py
@@ -340,7 +340,10 @@ class ELFFile:
             sys.exit(1)
         for l in proc.stdout:
             fields = l.strip().split()
-            self.symbols[fields[2]] = int(fields[0], 16)
+            try:
+                self.symbols[fields[2]] = int(fields[0], 16)
+            except:
+                print "Ignoring "+l
     def get_symbol_addr(self, sym):
         self._fetch_symbols()

pvvx · 2 Июл 2015

jcmvbkbc написал(а):
Попробуй применить следующий дифф к функции _fetch_symbols:

Буфера у питона по умолчанию не хватает. Надо что-то менять полностью. В stdout вывод длится несколько секунд

Пока xtensa-lx106-elf-nm.exe отсортирует, пока выведет... а цикла нема.
proc.stdout.readline() тоже самое - затягивает малый кусок...
На proc.wait() висит, распечатав начало.
Я уже помучал:

Код:

    def _fetch_symbols(self):

        if self.symbols is not None:
            return
        self.symbols = {}
        try:
            tool_nm = "C:\\Espressif\\xtensa-lx106-elf\\bin\\xtensa-lx106-elf-nm.exe"
            if os.getenv('XTENSA_CORE')=='lx106':
                tool_nm = "xt-nm"
            tmpsection = tempfile.mktemp(suffix=".symbol")

            proc = subprocess.Popen([tool_nm, "-g", self.name], stdout=subprocess.PIPE)
            l = ' '
            while l:
                l = proc.stdout.readline()
                fields = l.strip().split()
                if len(fields) >= 2:
                   print("Symbol %s = %s " % (fields[2], fields[0]))
                try:
                   self.symbols[fields[2]] = int(fields[0], 16)
                except ValueError as verr:
                   print("Se %s = %s ? %s" % (fields[1], fields[0], str(self.symbols)))
                   pass
                except Exception as ex:
                   print("Sy %s = %s ? %s" % (fields[1], fields[0], str(self.symbols)))
                   pass
        except OSError:
            print "Error calling "+tool_nm+", do you have Xtensa toolchain in PATH?"
            sys.exit(1)

и бросил этот кусок, надо другим методом... проще через файл... т.к. похоже, что лажает xtensa-lx106-elf-nm.exe
Это работает всегда:

Код:

cmd = 'C:\\Espressif\\xtensa-lx106-elf\\bin\\xtensa-lx106-elf-nm.exe -g ' + elf_file + ' > eagle.app.sym'
#print cmd
os.system(cmd)

fp = file('./eagle.app.sym')
if fp is None:
    print "open sym file error\n"
    exit

lines = fp.readlines()

fp.close()

entry_addr = None
p = re.compile('(\w*)(\sT\s)(call_user_start)$')
for line in lines:
    m = p.search(line)
    if m != None:
        entry_addr = m.group(1)
        #entry_addr = int(entry_addr, 16)
        print entry_addr

if entry_addr is None:
    print 'no entry point!!'
    exit

jcmvbkbc · 2 Июл 2015

pvvx написал(а):
Буфера у питона по умолчанию не хватает. Надо что-то менять полностью.

Начни с себя, узнай как в твоей ОС работают пайпы, это может пригодиться в будущем.

nikolz · 2 Июл 2015

pvvx написал(а):
Есть глюк у esptool и он проявляется при компиляции с указанием ошибки в строке 666
Что-то не стыкуется с форматом int в 16-тиричом формате в elf - связана с некорректным разбором формата elf. Устраняется только изменением проекта и новой компиляцией.
Лог не прилагаю, т.к. ошибка не частая и она в глубинах обработчиков...

Так-же есть глобальная ошибка в компиляторе UDK - компиляция с опций -Os дает неработающий код для ESP8266. В основном это проявляется на больших проектах, а не в HelloWord.
И размер кода при -O2 в UDK выходит меньше, чем при -O3. Тоже странность.

У меня компиляция с опций -Os дает работающий код для ESP8266. А размер кода при -O2 в UDK выходит больше.

pvvx · 2 Июл 2015

Починил по быстрому:

Код:

    def _fetch_symbols(self):
        if self.symbols is not None:
            return
        self.symbols = {}
        fname = os.getenv('TEMP');
        if fname == None:
                  fname = '.'
        fname += '\\eagle.app.sym'
        cmd = 'C:\\Espressif\\xtensa-lx106-elf\\bin\\xtensa-lx106-elf-nm.exe -g ' + self.name + ' >'+fname
        print cmd
        os.system(cmd)
        fps = file(fname)
        if fps is None:
            print "open sym file error\n"
            exit(1)
        lines = fps.readlines()
        fps.close()
        for l in lines:
           fields = l.strip().split()
           try:
              self.symbols[fields[2]] = int(fields[0], 16)
           except ValueError as verr:
              pass  
           except Exception as ex:
              pass

Теперь работает.

pvvx · 2 Июл 2015

nikolz написал(а):
У меня компиляция с опций -Os дает работающий код для ESP8266. А размер кода при -O2 в UDK выходит больше.

Вам же там описано - для ваших проектов "HelloWord" это безразлично, как и последняя, уже исправленная ошибка в esptool.py. Вам хватит для os_printf("HelloWord") буфера для всех символов

Затем откройте online-справочник по gcc и прочитайте на какие опции отличается трансляция кода с -Os. Возможно через несколько лет придет понимание

Потом странслируйте код и побольше (возьмите у кого-нить) и сравните размер у -O2 + опции и -O3. Потом пишите чего нить

nikolz · 2 Июл 2015

pvvx написал(а):
Вам же там описано - для ваших проектов "HelloWord" это безразлично, как и последняя, уже исправленная ошибка в esptool.py. Вам хватит для os_printf("HelloWord") буфера для всех символов
Затем откройте online-справочник по gcc и прочитайте на какие опции отличается трансляция кода с -Os. Возможно через несколько лет придет понимание
Потом странслируйте код и побольше (возьмите у кого-нить) и сравните размер у -O2 + опции и -O3. Потом пишите чего нить

Это Вы очевидно с собой говорите в зеркало.
Да так и до маразма не долго.
А если Вам интересно, Что я собираю, то собираю NODEMCU китайское и памяти больше получается чем у Вас.
Но Вы продолжайте и далее беседовать с зеркалом.
Вам не привыкать.

nikolz · 2 Июл 2015

pvvx · 3 Июл 2015

nikolz написал(а):
pvvx,
посмотрите что сделал китаец и раньше Вас.
А Вы все д-мом исходите
Вот так распределена память в NODEMCU от 27.06.2015
Все константы переброшены во флеш.
Пожалуй больше RAM уже не освободишь.
------------------------------------------------------------------------------
Section info:
Section| Description| Start (hex)| End (hex)|Used space
------------------------------------------------------------------------------
data| Initialized Data (RAM)| 3FFE8000| 3FFE8B44| 2884
rodata| ReadOnly Data (RAM)| 3FFE8B44| 3FFE8B4C| 8
bss| Uninitialized Data (RAM)| 3FFE8B50| 3FFF1A80| 36656
text| Cached Code (IRAM)| 40100000| 401079E4| 31204
irom0_text| Uncached Code (SPI)| 40210000| 4026D6EC| 382700
Total Used RAM : 39548
Free RAM : 42372
Free IRam : 1582
------------------------------------------------------------------------------

На это вам тоже уже отвечал. Такое решение не применимо - ведет к ошибкам при чтении и записи flash. Вы же не знаете реализацию

И она опубликована давно и у всех, кроме вас было время подумать и проверить.
Пока только мой вариант работает c тем тормозным методом прерываниям с "протектед" и восстановлением по обращению к каждому байту размешенному в flash или в IRAM.
У меня всё уже давно размещено в IRAM и ошибок, как у NodeMCU при чтении/записи Flash данный метод не вызывает

IRAM не отключается на ходу и пока только в моих проектах её много - 48 килобайт.
Мап-файл с постепенно перерабатываемым проектом EspLua.ru лежит тут.
И отличий там больше, но мне лень даже перечислять, не то что делать. Как нибудь почуток доделаю, т.к. в других проектах многое уже реализовал, но туда не впихнул.
Основные отличия пока такие (об остальных пока умолчу - нефиг вам знать):
Общей свободной памяти больше, чем в NodeMCU, хотя используется полный SDK 1.1.2.
Загрузка до старта кода в 10 раз быстрее. Spiffs работает на 16 Мегабайт flash и тоже в десятки раз быстрее...
PS: проект EspLua был затеян для того, чтобы вынудить авторов NodeMCU хоть что-то сделать. Подвижки уже есть, но как-всегда - кривые...

pvvx · 4 Июл 2015

jcmvbkbc написал(а):
Начни с себя, узнай как в твоей ОС работают пайпы, это может пригодиться в будущем.

Пипа работает в зависимости от опций задаваемых в Popen. Там задается и размер буфера и есть ли он вообще.
Так что вам уже поздно по аналогии рекомендовать "Начните с себя"

Факт в том, что проблема не в int(fields[0], 16), а в том что не все переменные передаются, если их много. Или конкретнее - esptool.py в связке со всем остальным имеет ошибку и исправление уже дано https://github.com/pvvx/esp8266web/blob/master/esptool.py.

jcmvbkbc · 4 Июл 2015

pvvx написал(а):
Пипа работает в зависимости от опций задаваемых в Popen. Там задается и размер буфера и есть ли он вообще.
Факт в том, что проблема не в int(fields[0], 16), а в том что не все переменные передаются, если их много.

С невозмутимым видом нести ахинею -- это не талант.
Неумение отличать пайпы ОС от обёрток языка -- это, наверно, от неумения читать. Незнание того, на что влияет размер буфера языка можно списать на общую необразованность.
А говорить о фактах, даже не удосужившись заглянуть в вывод nm, чтобы увидеть как отображаются weak-символы (подсказка:

Код:

402620d0 A _irom0_text_end
40240000 A _irom0_text_start
         w _ITM_deregisterTMCloneTable
         w _ITM_registerTMCloneTable

) -- это п****больство.

pvvx, ты п****бол?

pvvx · 4 Июл 2015

jcmvbkbc написал(а):
С невозмутимым видом нести ахинею -- это не талант.
Неумение отличать пайпы ОС от обёрток языка -- это, наверно, от неумения читать. Незнание того, на что влияет размер буфера языка можно списать на общую необразованность.
А говорить о фактах, даже не удосужившись заглянуть в вывод nm, чтобы увидеть как отображаются weak-символы (подсказка:

Код:

402620d0 A _irom0_text_end 40240000 A _irom0_text_start w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable

) -- это п****больство.

pvvx, ты п****бол?

Сделайте вывод символов в питоне и поймете что вы дебил

proc = subprocess.Popen([tool_nm, '-g', self.name], stdout=subprocess.PIPE)

jcmvbkbc · 4 Июл 2015

pvvx, ты свои правки в апстрим предложи, вместо того чтобы с дебилом пререкаться

pvvx · 4 Июл 2015

jcmvbkbc написал(а):
pvvx, ты свои правки в апстрим предложи, вместо того чтобы с дебилом пререкаться

Я и так дал работающий вариант. Вам что-то не нравится?
Проблема была объявлена и решена. Решений может быть множество.
И в таблице есть и undefined symbols = U - это на котором спотыкалось в примере к объявлению ошибки

jcmvbkbc · 4 Июл 2015

pvvx написал(а):
Я и так дал работающий вариант. Вам что-то не нравится?

Мне не нравится твоё хитрож***е п****больство.

pvvx написал(а):
И в таблице есть и undefined symbols = U - это на котором спотыкалось в примере к объявлению ошибки

Вот молодец, теперь осталось признать, что с пайпами все было в порядке с самого начала -- и ты на пути к выздоровлению.

pvvx · 4 Июл 2015

jcmvbkbc написал(а):
Вот молодец, теперь осталось признать, что с пайпами все было в порядке с самого начала -- и ты на пути к выздоровлению.

class subprocess.Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None,creationflags=0)
Выздоравливайте

Первым делом было вставлено:

Код:

            try:
               self.symbols[fields[2]] = int(fields[0], 16)
            except ValueError as verr:
               pass  
            except Exception as ex:
               pass

UDK: Общие баги/глюки/проблемы

Member

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

Member

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

New member

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

New member

Well-known member

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

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

Well-known member

Well-known member

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

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

New member

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

New member

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

New member

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