Comments 32
а вы как-либо сумели с производителем связаться и сообщить о таких ошибках? ну хоть в errata добавят (нет).
У меня такой печальный опыт общения с первыми линиями разных техподдержек, что я без нужды к ним не обращаюсь больше. Обычно никому это не надо у производителя. А если кому-то и надо, то пока до него прорвёшься... А смысл?
Конечным пользователям будет полезно - я задокументировал. Заказчик в Штатах тоже в курсе теперь. Возможно, он с производителем свяжется.
Уровень MAC там настолько продвинутый, что аппаратно парсит IPv4 заголовки и проверяет их чексуммы?
В полном соответствии с логикой STM32, с которым эти контроллеры функционально совместимы. Причём настолько совместимы, что вот у STM32F10X MAC намного проще, чем у STM32F4.... Поэтому у GD32F107 MAC похож на STM32F107, а у GD32F450 - на STM32F4. У первой парочки, скажем, нет расширенных дескрипторов.
А так - там на уровне MAC ещё и аппаратная поддержка PTP имеется. У всех выше перечисленных. И опять же, парочка STM/GD32F107 имеет логику PTP попроще, А которые F4 - покруче. Всё совместимо.
Тогда я думаю проблема очень проста. чексум в IP-протоколах считается как one's complement sum и в нём не различаются 0000 и FFFF. Конкретнее, в заголовках и TCP не различаются, а в UDP (чексум тела пакета) 0000 означает что чексум не вычислялся и проверять нечего, а FFFF -- валидный чексум.
Ну STM32 примерно так и работает. А вот GD32, если видит в этом поле входящего пакета ноль, то игнорирует такой пакет. При этом не выявлено каких-либо флагов ошибки. По крайней мере, мы ставили точки останова на участки, где в дескрипторе вернулся признак ошибки. Ни разу не сработали. И те счётчики ошибок в портах, что мы мониторили - не увеличивались. А пакеты именно с таким признаком именно GD32 - теряли.
Что касается флагов ошибок - может не то смотрели, может где-то что-то и отмечалось. Но что настоящий STM32 в тех же ситуациях ничего не терял - факт. Отключение проверки контрольных сумм заголовков решает проблему - тоже факт.
Не вот на эти грабельки наступили китайцы с контрольной суммой? https://blog.not-a-kernel-guy.com/2020/04/11/udp-checksum/
Я переводил их карту в режим LoopBack, вставлял на передачу пакеты из статьи, но КС добавлял чип сам. Да. На приём приходило вместо нуля FFFF. Скорее всего, на эти.
Удручает это. Вроде, всем хороши контроллеры, но только на бумаге. А на поверку оказались "китайскими" в не самом лучше смысле этого слова. Пытались заказать контроллеры GD другой серии, так выяснилось, что они вовсе их не производят. Рекламируют, но не производят. Лично я Гигадевайсом несколько огорчён. Могу лишь понадеяться на дальнейшее развитие.
Это что. Мне однажды свалился баннер - купите отечественный RISC-V контроллер. Ну я зашёл. Ага! Не купите, а запишитесь на покупку. И когда он будет доступен, то у него будет 8 килобайт флэша... При том, что по моим ощущениям, RISC-V с Compressed командами требует в среднем вдвое больше памяти для кода, чем Cortex M. А самая базовая голубая пилюля 64К флэша на борту имеет...
В общем, всё познаёмся в сравнении. Тут - пойманные проблемы неприятны, но пока не смертельны.
Согласен, раз на раз не приходится. Тот же М3 от российской фирмы до некоторых событий приобрёл вместе с отладкой легко и просто, и совсем недорого. Да и нынче в, так сказать, ручном режиме обещают отгрузить небольшую партию контроллеров по более-менее адекватной цене. Честно говоря, не ожидал ни тогда, ни сейчас, что вообще можно вот так просто взять и купить.
Да ладно! Errata'ми на десятки листов блещут нынче не только лишь все.
Ну тут проблема непосредственно у GD только одна, как я понял (нулевой CRC считает плохим), остальные две - кривая демо-плата (плохой клок, неправильная настройка буффера). Я с Microchip PIC32MZ работаю, там и не такое встречалось... По сравнению с китайцами у нормальных фирм было то преимущество, что нормальная техподдержка и документация была доступна. Но вот недавно вот обратился в их ТП по поводу очередной проблемы, мне сказали: гуляйте лесом, товарищ, ваша страна больше не рукопожата. А доки теперь скачивать только через VPN. Отличий от китайцев становится всё меньше...
Документация на GD32 весьма толковая и написана явно с нуля (ну, то есть, пересказана, а не просто переведена на китайский и потом обратно на английский). Хотя, разумеется, и близка к оригиналу. Но по крайней мере, ни разу не пришлось кричать: "Да что же там такое?" и открывать оригинал. Только GDшную штудируем в рамках этого проекта, а раньше с блоком Ethernet я не сталкивался для STM32.
И надо отметить, что библиотеки у них написаны даже красивее, чем у STшников. Кто-кто, а программисты у STшников странно пишут. У китайцев стиль, конечно, интересный, но оптимальность у библиотек для доступа к железу - на высоте. Я не со всеми решениями согласен, но то, что в рамках проекта более, чем в 50% случаев работаю через их библиотеки - это о многом говорит. Кто их писал, тот молодец.
Там путаницы в коде много. Как они тактовую частоту настраивают - это эталон путаницы. Там всё пришлось выкинуть и написать заново. Но доступ к железу, да на втором уровне оптимизации, да со включённой оптимизацией во время компоновки... Конфетка! По крайней мере, по сравнению с оригинальными STшными решениями.
с Microchip PIC32MZ работаю, там и не такое встречалось...
А что там такого чего нет в errata?
У меня больше проблем было с библиотеками, когда примеры из Harmony не работали, но говорят там уже стало получше. Помогло использование самого нижнего уровня абстракции, с тех пор я так ими и пользуюсь, т.к. код написан уже почти на все случаи жизни.
Хорошее описание поиска и анализа проблемы, спасибо! Но.
в большой плате – всё веселей. Там PHY тактируется от порта A8 контроллера:
на серийных устройствах с STMF4 была та же самая проблема , на большинстве устройств (но не всех) были потери при прямом соединении с пк. Так что вам повезло с платой ST. Она же в единичном экземпляре была.
Джиттер PLL в ST порядка 0.5-1нс ( на выходе MCO а не значения из даташита! ),
, замерял осцилом в рамках системы DPLL, построенной на этих мк (на входе таймера импульс 1гц асинхронный, на выходе точные частота и фаза кварца, что управляется этим мк, и его же тактирует ).
Требования по джиттеру у входного сигнала микросхемы физики повыше (см страницу 77 дш dp83848 , мы использовали micrel, там все тоже самое)
лучше даже вот тут смотреть, все микросхемы езернета весьма чувствительны к качеству клока.
https://www.ti.com/lit/an/snla091b/snla091b.pdf?ts=1660652493295
Так что только лишь из этого утверждать что PLL в GD хуже нельзя
и вероятно не DP83448 а DP83848 ?
Проблемы большого джиттера на выходе MCO не только у STMF4, на моем опыте это проявлялось на STMF107. Так же пытались тактовать от PLL микроконтроллера связь по RMII и в итоге пришли к схеме внешнего генератора.
Cпасибо, маркировку поправил.
Про то, что STM32 тоже может дурить - понятно. У нас две NUCLEO просто работали, на том и остановились. Но в целом, вывод в тексте всё равно универсальный, так что его править не нужно.
В общем, если у вас проблемы, проверьте, не PLL ли их создаёт. Возможно, стоит потратиться на внешний генератор именно для PHY.
А про то, что это не только у GD32 бывает - пусть в комментариях будет.
А там нет возможности после PLL добавить в цепочку делитель на 2? Если причина в дробном делителе может помочь, наверно.
Конкретно у GD32 с делителем всё хорошо. В отличие от STM32, она поддерживает частоты до 200 МГц. Само собой, в проекте установлена именно эта частота. Так что для получения 50 МГц, деление целое.
/* choose DIV2 to get 50MHz from 200MHz on CKOUT0 pin (PA8) to clock the PHY */
rcu_ckout0_config(RCU_CKOUT0SRC_PLLP, RCU_CKOUT0_DIV4);
syscfg_enet_phy_interface_config(SYSCFG_ENET_PHY_RMII);
В свою очередь, на той конкретной плате 200 делается из кварца на 25 МГц.
Но спасибо за технологию. В будущем может пригодиться где-нибудь.
Боюсь спросить! А поменять алгоритм расчета CRC заголовка, чтобы возвращал не ноль при любом значении, нельзя? Просто вы шлете корректные пакеты, а микроконтроллер их отбрасывает считая некорректными. Кто то явно неправ!
1) CRC (он же контрольный циклический код) - у всего пакета. А у заголовка - арифметическая контрольная сумма, она же CS
2) Заголовок формируется на уровне Операционной Системы. В обычной ситуации, мы на него не можем повлиять . Для исследований, можно слать пакеты через PCAP драйвер, как я описывал тут. В обычной же ситуации, мы открыли сокеты, и шлём данные. А оборачивает в пакеты их ОС. Как я показал, посылая абсолютно идентичные данные, мы получали потерю каждого 65536-го пакета, потому что одно из полей в каждом следующем пакете увеличивает именно ОС. Прочие поля (и их тоже заполняет ОС) не меняются. Поэтому плохая КС получается раз в 65536 посылок (поле, которое увеличивается - 16 битное, КС - тоже).
3) К счастью, контроль CRC всего пакета и CS заголовка - разные операции. Поэтому на уровне контроллера, мы отключили проверку CS заголовка, но оставили контроль CRC пакета. Поэтому если данные исказились при передаче, с очень большой вероятностью, такой пакет будет отброшен.
Для пакетов с одинаковым набором данных проблема контрольной суммы будет явно существовать. Но если в данные вы добавите пару случайных чисел, то... Опять, же, если дублируется пакет с разной солью, то вы чисто теоретически 100% избавляетесь от данного бага.
У вас ещё поле 2E меняется. Возможно, контрольная сумма от него зависит. Имеет смысл проверить
Какая соль? Это контрольная сумма заголовка. Заголовок формирует операционная система. Мы туда только IPшники и порты передаём. Остальное (включая MAC адреса и даже наш IPшник) заполняет ОС. Мало того. Если я ничего не путаю, при прохождении через маршрутизаторы, порт и даже наш адрес могут поменяться. Правда, это я просто нутром чую. В рамках нашего проекта такое не проверялось.
Одинаковые данные получались, так как мы слали всегда на один адрес и один порт.
А в целом - довольно удивительно подстраивать протокол под ошибки конкретного контроллера. Сколько этих контроллеров в мире? Вот мы сейчас по указанию. Заказчика переходим от опытов с GD32 к CH32. Если там найдётся какая-то ошибка, учитывать и её?
Мы просто нашли, как устранить проблему на уровне прошивки и успокоились. А как ответственный человек, я поделился знаниями со всеми.
Хабр — торт!
Как же не хватало таких вот статей, однако. Спасибо.
Как же не хватало таких вот статей, однако. Спасибо.
У GD флеш память состоит из двух областей, одна - быстрая, вторая - медленная. Конкретно в datasheet на GD32F450 эти области именуются как code area и data area. Например, для GD32F450ZI - это 256к и 1792к соответственно. Так вот, в момент обращения к этой "медленной" памяти в контроллере происходят какие-то непонятные паузы, даже самые высокоприоритеные прерывания при этом тормозятся (на форуме электроникса есть пример на GD32F103). Возможно, что и частота PLL нестабильна именно в эти моменты.
Спасибо за информацию.
В целом, у нас программа простенькая
text data bss dec hex
20252 1112 48400 69764 11084
Но информация пригодится! Спасибо!
у GD флэш - отдельный кристалл подключенный через SPI. при ребуте 256кб (или сколько там - у других семейств размер отличается) вычитывается в SRAM, с остальным - идет работа по SPI (который мееедленный)... ессно, пока слово по SPI не вычитается - ядро висит на выборке команды/данных не реагируя на прерывания (т.к. не может бросить выполнение команды на половине).
Сразу три причины, из-за которых контроллер GD32F450 теряет UDP пакеты