Jump to content

    

pokk

Участник
  • Content Count

    115
  • Joined

  • Last visited

Community Reputation

0 Обычный

About pokk

  • Rank
    Частый гость

Recent Profile Visitors

1824 profile views
  1. Внешней нету, есть только внутренняя, это как сначала пишем в отдельную область а после перезагрузки в boot копирует от туда в основное ПО? Не с изменяемыми настройками а с дефолтными. В принципе да =) , для сохранение всех перемененных во Flash создал структуру, и вся работа с сохранением идет через её, вот в ней все и находиться и серийник и IP и калибровочные константы. На это думаю сделать проверку, был ли он проинициализирован (wiznet w5500), и считать с него, если он потерял IP, то вбить дефолтный. Но да алгоритм проверки потерял не потерял IP это вилами по воде.
  2. У меня нету столько ОЗУ, что бы принять всю новую прошивку, а потом пошить её, так что прошиваю по мере приема образа прошивки. А как в вашем случае происходит запись серийного номера или что-то типа него ? Я его устанавливаю через WEB под паролем (пользователю это не видно и не доступно) И заношу серийный номер в дефолтную область, что бы если основные настройки будут не валидны, то полностью все восстановиться + серийник Я уже думаю сделать что бы по переходу в бут (перезагрузке) внешнему TCP/IP не дергать reset, тогда ip останется там.
  3. 1) В первом пакете передается адрес блока настроек 2) Если их нету (при первом прошивки через бут ) то , бут ставит свой дефолтный IP.
  4. Делаю bootloader на TFTP с внешним TCP/IP стеком (Один IP адрес) После того как приложение с IP адресом XXXX поймала начала пакета TFTP,происходит перезагрузка в bootloader, он заново инициализируемый и ему надо указать с каким IP ему работать, по этому, он считывает секцию настроек основного приложения и от туда достает IP который был установлен пользователем.
  5. В дефолтную структуру размешаю руками, и она достаточно большая, если так же размешать в пользовательскую, то 1) не удобно туда и туда записывать значения 2) Однозначно когда нибудь получиться так что в одну структуру внес одни изменения а в другой забыл и они стали разными. Раньше я в процессе работы ПО копировать из дефолтной структуры в пользовательскую (1 раз когда пользовательская структуру была пустой) А теперь мне для бутлоадера надо что бы в bin,hex файле они обе были инициализированы.
  6. Добрый день есть две структуры с настройками ПО, располагаются они в разных секция flash. Одна структура хранит дефолтные настройки, вторая текущие которые задает пользователь во время работы ПО. Как на этапе компиляции можно продублировать(скопировать) значения дефолтных настроек во вторую структуру(в пользовательскую) ?
  7. 1) Как правильно выравнивать секцию, по размеру страницы flash ? 2) Как задать размещение секции на начало страницы ?
  8. Появилось время продолжил разбираться, реализовал размещение CRC в таблице прерывания, только вот возник вопрос, как IAR указать чтобы он считал CRC до адреса где он его расположил CRC (секции checksum) и после секции? Как IAR считает CRC ? т.е до расчета CRC что находиться в секции .checksum ? Либо он в процессе расчета перезаполняет секцию?
  9. Добрый день, понадобилось некоторые перемеренные перенести в начальный адрес ОЗУ, сделал секцию: place at address mem:__ICFEDIT_region_RAM_start__ { readwrite section .StartingRam}; Разместил примеренные в секции (Блочно можно указать? Что бы не к каждой переменной модификатор добавлять.) uint16_t CopyMaxLen@".StartingRam"; //-------------------------------------------- Dump32_t AddrCopyHead@".StartingRam"; Dump16_t AddrCopyLen@".StartingRam"; Dump32_t AddrCopyBuff@".StartingRam"; //-------------------------------------------- static Dump8_t VarSaveDump8@".StartingRam"; static Dump16_t VarSaveDump16@".StartingRam"; static Dump32_t VarSaveDump32@".StartingRam"; Смотрю map файл: "A3": 0xb8 .StartingRam zero 0x20000000 0x2c debuger.o [1] .StartingRam zero 0x2000002c 0x18 debuger.o [1] .StartingRam zero 0x20000044 0x2c debuger.o [1] .StartingRam zero 0x20000070 0x18 debuger.o [1] .StartingRam zero 0x20000088 0x2c debuger.o [1] .StartingRam zero 0x200000b4 0x2 debuger.o [1] - 0x200000b6 0xb6 Вижу что переменная CopyMaxLen разместилась в самом конце, это почему так? Я ожидал что они разместиться как я их объявил, в том же порядке. Хотя остальные разместились в порядке объявления.
  10. В общем понадобилось сделать перезагрузку всего процессора, после чего начали детектироваться повторные аварии ( в журнале аварий) в следствии того что, все предыдущее состояния аварий сбрасываться в дефолтное состояние. Что бы этого не происходило надо бы добавить __no_init , но тогда: 1) По включению(аппаратному) в этих переменных всякая фигня находиться. 2) Есть состояния которые занесены в структуру и к ним модификатор __no_init не добавить =(. А другие поля структуры надо жестко выставить. В общем пока остановился на таком алгоритме: if(GetStatusRestart()==HARDWARE_RESTART){ //сбрассываем перименные в дефолтное состояние }else{ //Прогманный сброс нечего не делаем. } И в каждом модуле указываешь, что сбросить при аппаратном включении или программном перебросе. Вроде бы вариант не плохой, но все же хочется ещё лучше =), можно ли сделать отдельную секцию которая будет инициализировать только при аппаратной перезагрузке ? и все требуеммые перименные размещать в ней ?
  11. Ошибка происходит через сутки и больше под отладкой столько не просидит(частенько слетает отладочный режим от любого включение бп) + основной комп на ночь обесточивается, а плата гоняется в другой комнате, где есть постоянное сетевое напряжение. Ну голый dump памяти сложно анализировать..., когда тебе надо посмотреть значение кучу массивов и структур, а у тебя только адреса... как-то не очень вручную зависимости искать (примеренная -> адрес). Хотя уже сейчас есть идея, считать все ОЗУ, а потом на другой плате через отладчик обратно заполнять ОЗУ и анализировать через memory, symbolic memory сколько угодно.
  12. Добрый день подскажите, можно ли сохранить из под отладки все значения переменных в symbolic memory, нашел сохранение диапазона адресов в hex файл, но это не визуально. Дело в том что пытаюсь найти баг, который через несколько суток, перетирает структуру (константные значения тоже перетираются левыми значениями), так вот сделал выдачу по запросам несколько перименных по usart, но это как то медленно происходит, хочу сразу увидеть что случилось, с озу и откуда началось перетирание. Появилась идея после "зависона" ПО подключиться к нему через отладчик, но остановиться в векторе прерывания reset, и от туда считать ОЗУ и тд. Но вот сохранить всю память как она отображается в symbolic memory как-то не нашел.
  13. Сделал так: Положил CRC в начало прошивки а структуру сдвинул на 4 байта, а в загрузчике накладываю структуру (с присутствие поля CRC_Appl ) по началу адреса. extern uint32_t __checksum; typedef struct{ //uint32_t CRC_Appl; uint16_t ID; uint32_t endAddr; uint32_t size_page; }s_botloader_header; //-------------------------------------------------------------------------------------------------- const s_botloader_header botloader_header@0x8005004={ .ID=0xAACC, // идетификатор что бы муссор не пихали .endAddr=0x803F7FF, }; Но не нравится мне такой вариант все же, хочеться более надежно, что бы CRC в структуре была сразу.
  14. Можно по подробнее, это как у меня секция приложения и секция настроек ? или Когда приложение разбивается на несколько секций ? А для чего такое, используют? Я тут по смотрел, моя прошивка занимает где-то только 30% памяти, остальное в hex, bin забито 0xFF, можно ли как то правильно заливать только ту часть которая содержит прошивку, без стирания всего flash? Все же приятнее, если прошивка залетает за пару секунд а не десяток. Но тут опасаюсь получить кучу непонятных багов, если при уменьшении размера новой прошивки, куски старой останутся не тронутыми, и это все соединиться (хотя можно стереть + 1 страницу с запасом).
  15. Добрый день, подскажите с алгоритмом бутлоадера. Устройство (stm32) содержит 3 области памяти bootloader, сама прошивка(app), и блок настроек (Setting тут находиться IP адрес, mac и тд ). Пока рассматриваю следующий алгоритм. 1) При включении устройства сразу попадаем в загрузчик там сверяем CRC прошивки (appl), если CRC сошлась то переходим в него, если нет то остаемся в bootloader и ждем прошивку. 2) При обновлении прошивки, загрузчику предается шапка app в которой содержаться ID, CRC, размер страницы, и тд.. а после сама прошивка. это я уже частично реализовал, остались следующие вопросы: 1) Как сделать переход из appl обратно в booloader ? При получении шапки прошивки в appl(без ответа TFTP на этот пакет) установить байт в озу на обновление , и сделать программный reset, и при повторном запросе(по таймауту, так как не было ответа) шапки appl принять её уже в загрузчике и начать обновление. 2) Какой IP установить загрузчику дефолтный свой ? Так как ip у приложение может смениться пользователем, и после reset загрузчик, не поймает пакет, так как будет находиться на другом IP. Можно из bootloader считывать область настроек, и доставать от туда IP, но при первом прошитии bootloader, секции настроек нету. Можно считывать секцию setting и проверять её CRC и в случае отсутствия устанавливать дефолтный ip, но как потом выяснить какой же ip установился ? 3 ) В каком формата передавать прошивку hex или bin? Пока не вижу преимущества hex формат, только больший геморрой с парсингом и со склеиванием кусков, до размера страници flash.