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/
Удручает это. Вроде, всем хороши контроллеры, но только на бумаге. А на поверку оказались "китайскими" в не самом лучше смысле этого слова. Пытались заказать контроллеры 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 пакеты