MX_Master

Ethernet MAC имеет доступ не ко всем доменам ОЗУ. Могу ошибаться, но, возможно, RX/TX буферы находятся в недоступном домене. ЗЫ рабочий пример (создан на скорую руку) - https://gitlab.com/MX_Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP

Вот и я не увидел, а в структуру таки массив не внесли Я лентяй ещё тот. Собсна, как и многие другие. Однако, все согласятся с тем, что изучать доки гораздо приятнее, когда рядом есть хотя б какой-то пример. Пример может быть хорошим или плохим. Но благодаря ему понимание логики работы устройств приходит быстрее Второй плюс кода из под кубика - готовый набор макросов для правки регистров. Ими я пользуюсь с удовольствием. А вот тяжеловесных кубовых функций я стараюсь избегать. Единственное, место, где они остаются - в начальной инициализации. Ибо скорость старта устройства не так важна, как скорость в работе. Но иногда, даже в простых кубовых функциях бывают ошибки. На одну из них я и попался Причём, ошибка неявная, пока глыбже в код не нырнёшь, непонятно /** * @brief ETH Init Structure definition */ typedef struct { uint32_t AutoNegotiation; uint32_t Speed; uint32_t DuplexMode; uint16_t PhyAddress; uint8_t *MACAddr; uint32_t RxMode; uint32_t ChecksumMode; uint32_t MediaInterface; } ETH_InitTypeDef;

Разобрался. Оказыцца, в новый кубик за 2 года завезли новых багов 2 года назад кубик делал так /* ETH init function */ static void MX_ETH_Init(void) { uint8_t MACAddr[6] ; heth.Instance = ETH; heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; heth.Init.PhyAddress = PHY_USER_NAME_PHY_ADDRESS; MACAddr[0] = 0x00; MACAddr[1] = 0x80; MACAddr[2] = 0xE1; MACAddr[3] = 0x00; MACAddr[4] = 0x00; MACAddr[5] = 0x00; heth.Init.MACAddr = &MACAddr[0]; heth.Init.RxMode = ETH_RXINTERRUPT_MODE; heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; /* USER CODE BEGIN MACADDRESS */ /* USER CODE END MACADDRESS */ if (HAL_ETH_Init(&heth) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); } } А сейчас вот так static void MX_ETH_Init(void) { /* USER CODE BEGIN ETH_Init 0 */ /* USER CODE END ETH_Init 0 */ /* USER CODE BEGIN ETH_Init 1 */ /* USER CODE END ETH_Init 1 */ heth.Instance = ETH; heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE; heth.Init.PhyAddress = DP83848_PHY_ADDRESS; heth.Init.MACAddr[0] = 0x00; heth.Init.MACAddr[1] = 0x80; heth.Init.MACAddr[2] = 0xE1; heth.Init.MACAddr[3] = 0x00; heth.Init.MACAddr[4] = 0x00; heth.Init.MACAddr[5] = 0x00; heth.Init.RxMode = ETH_RXINTERRUPT_MODE; heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE; heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_RMII; /* USER CODE BEGIN MACADDRESS */ /* USER CODE END MACADDRESS */ if (HAL_ETH_Init(&heth) != HAL_OK) { Error_Handler(); } /* USER CODE BEGIN ETH_Init 2 */ /* USER CODE END ETH_Init 2 */ } Ошибку видно?

Года 2 назад экспериментировал с голыми (raw) Ethernet фреймами собственного типа (ethertype=0x80AB) на связке STM32F407VET6 + LAN8720. Всё работало как часы. Портировал недавно тот же код на связку STM32F207VCT6 + DP83848. На этой связке те же самые фреймы теперь отбрасываются в мусор. Очевидно, что их отбрасывает какой-то фильтр. Не могу понять только какой именно. Сквозь фильтр прекрасно просачиваются ARP, UDP, TCP пакеты с любым MAC (destination) адресом. Broadcast тоже пролетают на ура. А вот фреймы неизвестных типов (ethertype=0x80AB), даже с точным МАС адресом STM'ки, отбрасываются. Стессна, если в MAC регистрах включить PromiscuousMode или ReceiveAll , все фреймы приходят на ура. Можно, канеш, фреймы фильтровать и в коде, но интересно разобраться какой именно фильтр мешает. Если кто-то сталкивался с подобным поведением, дайте, пожалуйста, в нужную сторону пинка Попробую завтра что-нибудь ещё. Но было бы интересно выслушать пару советов.

Вариант с подменой адреса reset вектора гениален Спасибо, друзья. Бум пробовать... ЗЫ помониторить правку флэша из оригинала тоже не помешает

В контексте задачи можно оригинал разместить и с 0x08000000, а загрузчик в другом месте. Главное, чтобы первым стартовал именно загрузчик (:

Никогда ещё не дизассемблировал бинарники от STM32, с чего можно начать?

Название темы, канеш, непонятное. Не знаю как точно назвать. ДАНО: есть готовый бинарник прошивки под STM32F207VCT6, исходников нет. По таблице векторов прерываний видно, что базовый адрес флэхи = 0x08000000. ЗАДАЧА: хочу разместить в начале флэхи (0x08000000) свой загрузчик, а следом за ним разместить 2 прошивки - оригинал и свою версию. В зависимости от настроек, загрузчик должен передавать управление одной из них. Свой проект можно собрать, указав линкеру смещенный адрес флэхи. А как быть с уже собранным оригиналом? Есть ли какой-то способ найти в бинарнике все адреса с флэхи и махнуть их на другие?

Всё придумано до меня, для настольных ПК. Я лишь пытаюсь запустить сие на мобильных процессорах, вынося всякие ногодрыги в аппаратную часть МК. Получается, канеш, с горем пополам. Но, на мой взгляд, это лучше чем телебонькать пины обычным процессором. Если делать полностью своё ЧПУ (что займёт не один год), можно смело юзать и MP1. Его ресурсов, при грамотном подходе, более чем достаточно.

Там кроме собственно LinuxCNC ещё и обычная ОС, типа Ubuntu/Debian, давит на проц. Большинство интерфейсов у LinuxCNC - OpenGL'евые. А этого добра в MP1 нет (OpenGLES не в счёт), так что графика тоже падает на проц. Ну и частенько используются Python скрипты, чему процессор никак не рад. Всё переписывать и оптимизировать - дело неблагодарное. В данный момент использую алвинеры H3 + внешнюю F429. Присматриваюсь постепенно к RK3399. Там внутре 2 многоядрёных проца, один из которых можно в теории заточить под bare metal.

Всякие 4-х вёдерные алвинеры H3 при работе на схожих частотах (650мгц) могут спокойно остывать через плату. Вангую, эти MP1 будут ещё холодней. Эх, если б не ограничение в 650мгц, я б с удовольствием применил эти MP1 в своём ЧПУ проекте (на основе LinuxCNC). Но, к сожалению, ниже гигагерца никак низя. Кстати, насчёт HDMI в ЧПУ.. Мой будущий 3Д принтерный проект будет как раз с HDMI дисплеем (с тачем) + orange pi. Банально удобно

Раз пошла такая пьянка, есть для экспериментов ещё пара модулей. Опционально можно выбрать размер ОЗУ (256mb - 1gb) и размер флэшки (4-16gb) https://item.taobao.com/item.htm?id=602435481019 https://item.taobao.com/item.htm?id=598786390664 https://www.openembed.com/products/53.html http://snailboard.com

Глаза боятся, а пальцы тыкают (: http://wiki.i2som.com/plugins/servlet/mobile?contentId=19923153#content/view/19923153

Возможно, кому-то пригодится. Недавно наткнулся на недорогую китайскую макетку с STM32MP157 на борту. Для ЧПУ (CNC) применений и прочих опытов вполне себе подойдёт. цены: https://item.taobao.com/item.htm?id=599303130310 https://item.taobao.com/item.htm?id=592121183085 инфа: http://wiki.i2som.com/pages/viewpage.action?pageId=19922956

Для разделения есть STM32MP1xx (: Там под линями можно с веб-серверами и прочим gui развернуться намного шире. В то время как вся RT часть будет крутится на М4.