Jump to content

    

Dimonira

Свой
  • Content Count

    436
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Dimonira

  • Rank
    Местный

Recent Profile Visitors

1232 profile views
  1. Заработало! Я предположил, что коли в отладчике программа работает, а без него нет, то скорее всего как-то гадит загрузчик. В загрузчике я перенёс все инициализации Куба в начале main-а в место после кода запуска приложения (см. выше). Если выкинуть комментарии, то код стал таким: int main(void) { // Если нет признака необходимости перепрошивки FLASH памяти if(fwinfo.magic != MAGIC_WORD_32) { // Если адрес стека валидный (д.б. равен _estack в .ld файле), то переходим к запуску программы пользователя if(((*(__IO uint32_t*) USER_FLASH_FIRST_PAGE_ADDRESS) & 0x2FFE0000) == 0x20080000) { // Адрес программы пользователя JumpAddress = *(__IO uint32_t*)(USER_FLASH_FIRST_PAGE_ADDRESS + 4); Jump_To_Application = (pFunction) JumpAddress; // Установка указателя стека __set_MSP(*(__IO uint32_t*) USER_FLASH_FIRST_PAGE_ADDRESS); // Переходим к выполнению программы пользователя Jump_To_Application(); while(1); } else // Если адрес стека не валидный { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); // Мигаем LED для сигнализации и ничего не делаем for(;;) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); HAL_Delay(100); HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); HAL_Delay(900); } } } HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); // зажигаем LED для сигнализации MX_RTC_Init(); MX_LWIP_Init(); httpd_init(); while(1) { MX_LWIP_Process(); } } Теперь всё отлично работает! Вопрос закрыт.
  2. Читали первый пост невнимательно. Я там писал, что "надо в файле system_stm32f7xx.c задать для VECT_TAB_OFFSET значение 0x20000". Так что с учётом этого: SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */ получается значение VTOR = 0x8020000. В отладчике смотрю - так и есть. Так что дело не в этом. Сейчас переделал расположение загрузчика и программы в флеше. Точнее не их, а признака необходимости перепрошивки. Прошлый раз я для этого использовал последнее слово в флеше: если оно равно определённому коду, то это значит, что загрузчик при старте должен запускать себя для перепрошивки программы, а не саму программу. Получалось, что после прошивки программы, последнее слово затирается (ибо все сектора флеша под программу стираются) и после рестарта загрузчик всегда запускает программу. Программа, если надо перепрошиться (по команде с хоста), записывает код и рестартует, после чего загрузчик входит в режим прошивки. Теперь я сделал по другому, ибо понадобилось как-то маркировать версию прошитой программы. Для загрузчика отвёл три первых сектора (вместо четырёх) по 32К, а в следующем секторе теперь держу условно "таблицу firmware", в которой содержится код для входа в режим перепрошивки и номер версии программы. После прошивки загрузчика код для входа в режим прошивки программы задан автоматом. Когда загрузчик прошьёт программу, то в случае успеха (что важно) стирает сектор с таблицей firmware. После рестарта загрузчик уже запускает программу, которая проверяет номер версии. Поскольку номер ещё не прошит, программа его прошивает в таблицу firmware. При последующих стартах версия только проверяется и показывается в лог. Если надо перепрошить программу, то как и ранее, программа записывает код для входа в режим прошивки по команде от хоста и рестартует. Так вот теперь, программа при запуске отладчиком работает (раньше не работала). Но при автономном запуске железки опять стоит - выдачи по ethernet нет, а она ждёт завершения работы dhcp клиента. С одной стороны, хорошо, что в отладчике работает. А с другой непонятно как теперь искать трабл. Можно ли как-то подключиться к SWV "на ходу"? Правда у меня тут J-Link, а STM32 ST-LINK Utility его не понимает. Есть ли что-нибудь другое подцепиться?
  3. Вернул стартовый адрес 0x08000000, а всё равно не работает. Взял другую плату, на которой прежняя версия работает. Прошил - не работает. Короче, не работало из-за включения кэшей CPU SCB_EnableICache и SCB_EnableDCache (других отличий не было). Раньше их не включал, а тут решил "улучшить". Отключил кэши и заработало. Обрадовался, думал теперь и прошивочный вариант заработает. Хрен там. Вернулся к версии для прошивки (с адреса 0x08020000) - после прошивки не работает. По прежнему не посылаются пакеты в Ethernet. Какие логи? Может быть прошивальщик не "чистит" после себя что-то. На всякий случай вот код запуска приложения прошивальщиком (USER_FLASH_FIRST_PAGE_ADDRESS = 0x8020000). Я в нём ничего не менял кроме значения адреса стека на 0x20080000. // Если адрес стека валидный (д.б. равен _estack в .ld файле), то переходим к запуску программы пользователя if(((*(__IO uint32_t*) USER_FLASH_FIRST_PAGE_ADDRESS) & 0x2FFE0000) == 0x20080000) { // Адрес программы пользователя JumpAddress = *(__IO uint32_t*)(USER_FLASH_FIRST_PAGE_ADDRESS + 4); Jump_To_Application = (pFunction) JumpAddress; // Установка указателя стека __set_MSP(*(__IO uint32_t*) USER_FLASH_FIRST_PAGE_ADDRESS); // Переходим к выполнению программы пользователя Jump_To_Application(); while(1); } Я сам ничего "не говорил". В тестовом приложении мигание светодиода сделано через HAL_Delay, а она работает через SysTick, который тикает по прерываниям. Раз это работало, значит с прерываниями ОК (я так думаю). В стартовом коде есть это: SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */ Здесь FLASH_BASE равно 0x08000000.
  4. Есть приложение, сделанное Кубом, с FreeRTOS, Lwip и прочим. Оно работает на своей плате с STM32F777. Встал вопрос как обновлять прошивку платы. Самый удобный путь в нашем случае - удалённо через Ethernet, не влезая в изделие. Для реализации такого способа взял за основу проект LwIP_IAP для F7 из репозитория примеров. Сделал свой проект в Кубе (исходный проект устаревший и не компилировался), а нужные куски взял из примера (с исправлениями ошибок и под свой процессор). В итоге прошивальщик заработал. Использую HTTP. Под прошивальщик отвёл первые 128К флеша. Загружаемая программа должна стартовать соответственно с адреса 0x08020000. Плюс надо перенести таблицу прерываний. Для этих целей в программе надо в файле system_stm32f7xx.c задать для VECT_TAB_OFFSET значение 0x20000 и в файле настроек линкера STM32F777VITX_FLASH.ld в секции MEMORY в строке FLASH задать стартовый адрес 0x08020000, уменьшив LENGTH соответственно на 0x20000. При построении приложение надо включить конверсию в BIN-файл, который потом и загружается прошивальщиком. Сделал тестовое приложение мигания светодиодом, проделав описанные выше манипуляции, прошил браузером, перезагрузился - работает. Далее переделал основное приложение. После прошивки оно не работает. По светодиодам видно, что оно стартует. Дальше посмотрел отладчиком, оказалось, что никакие пакеты по Ethernet не выдаются. У меня стоит ожидание получения сетевых настроек через DHCP, так что дальше этого цикла ожидания программа не идёт. Как я понял, выдача пакетов делается через DMA, но её нет. Непонятно почему. Правда, по времени наложилось обновление IDE до версии 1.1.0, но я сравнивал исходники (после миграции и регенерации Кубом), отличия есть, но это ретушь (главное - теперь не затираются исправления где не попадя, например, в файле линкера). Есть мысли?
  5. STM32F777: Странное поведение NETCONN

    Кажется, я понял в чём дело. Подозреваю директиву #pragma pack(1) в своих заголовках. Исправил на пару #pragma pack(push, 1)/#pragma pack(pop), но проверить пока не могу - железо на работе. Не нашёл как удалить тему.
  6. Так везде в той или иной степени, всё зависит от запущенности (ака бедности) конторы.
  7. Я же не буду за свои покупать для работы анализатор. Итак уже натаскал на работу всякого, и тестер, и батарейки, и конвертер usb-ethernet, и планки памяти и т.д., уже всего и не упомню. Я сделал простейший костыль - чтение лишних битов. И этот костыль работает 100%. Ни одного сбоя не было, ибо если читается не то, что записывалось, то вызывается ErrorHandler с вечным циклом. В него ни разу процессор не заходил. Да и вопрос этот померк с свете другой проблемы (в соседней ветке).
  8. RDY не задействован, ибо в SPI интерфейсе отсутствует и Лог. анализатора нет.
  9. Столкнулся со странностью поведения NETCONN (но, может и сам где-то накосячил). Есть две задачи FreeRTOS, в каждой из которых создаётся свой NETCONN объект. В задаче, которая выполняется первой, странностей при создании NETCONN объекта нет. А во второй задаче есть: объект, возвращаемый netconn_new содержит некорректный адрес юниона pcb - он будто задом-наперёд. Я заходил пошагово в функцию netconn_new_with_proto_and_callback (она вызывается при netconn_new), в ней создаётся объект conn абсолютно нормальный: Но на следующем шаге, когда его адрес возвращается в точку вызова функции, отладчик показывает объект NETCONN с некорректным адресом pcb: В дальнейшем, естественно, при первой же попытке использовать, например, pUdpConn->pcb.udp->local_ip, процессор уходит в обработчик аппаратной ошибки. С чем может быть это связано? Стек задачи увеличивал - не помогло.
  10. Проверялось без FreeRTOS. SWV не включал. Тогда был J-LINK.
  11. Недавно я открыл для себя китайскую Trxcom. И, что самое приятное - низкие цены (от 60р) и наличие в российских конторах. Например, я покупал и для 100, и для гигабита в e-components.ru по 60-80р. 10/100: TRJ16664A28NL (62р) TRJ6011BBNL (94р) 1000: TRJG4806EBNL (75р)
  12. KSZ8863RLL

    Могу приложить свою схему для сравнения (самому сравнивать времени нет). Она работает с STM32F407, DHCP клиент получает адрес и т.п. С 8863 есть одна тонкость. У него нет регистра типа PHY SPECIAL CONTROL/STATUS REGISTER (0x1F) для получения текущего состояния скорости/дуплекса (как у LAN8742A, например). Думаю потому, что это свич. Если предположить, что контроллер у вас STM32 (вы не уточняли), то там стек протоколов заточен на этот регистр. Мне пришлось в Кубе поправить три значения в настройках, чтобы обмануть софт. Если у вас STM32, могу сказать какие. А ещё надо правильно задать адрес PHY. Опять же, в софте STM32 в инициализации делается программный сброс PHY, ожидание линка, получение состояния через интерфейс SMI, а в нём нужен корректный адрес PHY. Если это всё не получилось, то ничего дальше не будет.
  13. Хочу всё-таки уточнить: что именно мне было озвучено?
  14. Это всё общие слова. Здесь был конкретный трабл. Почему он возник так и осталось неизвестным.
  15. Странный вопрос... Это что-то вроде самокритики? Это к чему?