amiller

Нет, именно TCIF.

Столкнулся с интересной штукой. Если разрешаю transfer complete interrupt, то сразу после разрешения канала DMA улетаю в прерывание. Какие бы флаги не сбрасывал и задержки не вставлял. А если сначала разрешаю прерывание по половине буфера, а потом до конца, то всё ок. Кто нибудь сталкивался и как объехать? Код прерывания сейчас такой: void DMA1_Stream0_IRQHandler(void) { int32u temp; temp = DMA1->LISR; DMA1->LIFCR = 0x0000003D; // Clear Flags for Stream if (temp & DMA_LISR_HTIF0) { setmask(DMA1_Stream0->CR, DMA_SxCR_TCIE); clrmask(DMA1_Stream0->CR, DMA_SxCR_HTIE); } else { clrmask(DMA1_Stream0->CR, DMA_SxCR_TCIE); setmask(DMA1_Stream0->CR, DMA_SxCR_HTIE); Prn.dma_reset = true; } } А перезапуск происходит так: clrmask(DMA1_Stream0->CR, DMA_SxCR_EN); DMA1_Stream0->NDTR = Prn.size; DMA1_Stream0->M0AR = (int32u)Prn.ptr_x; DMA1->LIFCR = 0x0000003D; // Clear Flags for Stream setmask(DMA1_Stream0->CR, DMA_SxCR_EN);

Спасибо, всегда забываю про эту часть документации... Действительно в Errata есть такой пункт: "ARP offload function not effective" Только в качестве причины указана другая проблема, до которой я ещё не дошёл. А проблема с записью в регистр ETH->MACARPAR никак не поясняется. Тем не менее вопрос потерял смысл, надо ARP запросы парсить программно.

В процессе оптимизации софта обнаружил в регистре ETH->MACCR интересный бит ARPEN (STM32H743ZIT6). Описание достаточно краткое, но судя по всему этот бит включает автоматический ответ на ARP запросы на уровне MAC ETH модуля. Если я правильно понял описание, если IP адрес из ARP запроса совпадает с регистром ETH->MACARPAR, то контроллер автоматически отвечает, подставляя в ответ MAC адрес из регистра ETH->MACA3R. Проблема возникла в записи любого числа в регистр ETH->MACARPAR. Не могу это сделать и программно и в отладчике. Гугл находит только один вопрос на эту тему, но без ответа. https://community.st.com/s/question/0D50X0000BAEwqMSQT/enable-arp-offload-on-stm32h753 Кто нибудь пробовал запустить этот сервис? Получилось?

Да всё достаточно просто. Посчитал, что освоение Etрernet периферии с нуля достаточно сложный процесс. Предполагал, что сгенерирую пример Кубом, разберусь и адаптирую под себя. Но ни одна из нескольких попыток использования Куба для формирования модуля связи не увенчалась успехом. Потом пробовал несколько "рабочих" примеров из интернета, настраивал ноги физики под себя и пытался запустить. Один простой пример заработал криво-косо. Далее долго вычищал из него кубовский мусор, поженил со своим софтом. Сейчас всё работает. Понятно, что lwip избыточен для моих задач, да и вносит свою долю неопределенности в надежность. Поэтому следующий шаг - постепенно перейти на свою понятную реализацию стека. Мне нужно то от стека очень немного.

Спасибо, именно в эту сторону я двигаюсь. Предыдущая версия устройства у меня была с внешним контроллером W5100. Там необходимые элементы стека были реализованы ручками. По крайней мере UDP передача и DHCP клиент. Лишние копирования информации уже исключил. Сейчас планирую изучить взаимодействие lwip с ethernet периферией и вернуться к самостоятельной реализации стека.

Приветствую! Получилось вернуться к этому проекту. Мне нужно через Ethernet посылать данные по UDP. Вроде удалось завести это дело. Насколько я понял, минимальная последовательность для отправки одного UDP пакета такая: p_udp = pbuf_alloc(PBUF_TRANSPORT, size, PBUF_POOL); err = pbuf_take(p_udp, &buff, size); err = udp_sendto(pcb, p_udp, &client, udp_d_port); Исходя из этого два вопроса: 1. Пересылаются без ошибок UDP пакеты, длина которых не превышает 1136 байт с учётом заголовка. Пакеты большей длины обрезаются, а UDP CRC становится равной нулю. Мне для совместимости с предыдущей версией нужен пакет длиной 1480. Можно в lwip увеличить максимальную длину пакета? И какой параметр за это отвечает? 2. Мне нужен поток данных 25-30 Мбит в секунду. Достижимо ли это с lwip? Как оптимизировать процесс передачи данных? Насколько я понял, функция pbuf_take просто копирует (программно) данные из моего буфера в промежуточный буфер, снабженный заголовками UDP, IP и Ethernet. Если сформировать эти заголовки самостоятельно, то может при простой отправке UDP можно и без LWIP обойтись? Оставить ему ARP и DHCP? Заранее спасибо за любую инфу по этой теме. Похоже на второй вопрос частично сам могу ответить. По крайней мере это легко проверить. Очень вероятно, что можно выделить статический буфер с учётом длины заголовков. А udp_sendto сформирует заголовки и отправит пакет прямо из моего буфера. Только надо разобраться, как определить, что текущая операция передачи пакета завершена.

Состояние boot не должно влиять на то, видит St-link, или не видит девайс. Работал с STM32H743ZI. Семейство вроде бы одно. VCAP - это выводы, которые подключены к напряжению Vcore. В зависимости от параметров настройки (после инициализации) встроенный LDO должен выдавать от 1,0 до 1,4В. У вас существенно меньше. Скорее всего в этом и есть причина (где то КЗ или ошибка в подключении выводов питания). А так девайс вполне видится и программируется через ST-Link V2. Если не подключена батарейка, то вывод Vbat нужно подключить к VDD. Но это опять же не должно влиять на работу с отладкой. ST-Link может работать в разных режимах. Рекомендую режим с аппаратным управлением reset.

Приветствую! Прошу помочь с гарантированно рабочим примером, который хоть что-то делает. Пробовал разные примеры из сети, с сайта STM,а также сгенерированные кубом. Мне надо сделать UDP-клиент, но сдвигов нет. Всё остальное на процессоре уже работает, только с ETH заминка вышла. Активности нет, на пинги не реагирует. Только светодиоды мигают, но это я так понимаю функция PHY. Или подскажите последовательность шагов, что и в каком порядке запускать, чтобы оживить функционал.

Нет, согласен. Я уже вложил деньги в разработку продукта, отбил затраты и теперь могу ставить цену меньше чем конкурент, которому для захвата рынка нужно разработать самому или украсть продукт. Если рынок премиальный, то это выгодно и конкуренты будут лезть в эту нишу. А если рентабельность не позволяет быстро отбить затраты, то и желающих будет мало. Плюс налаженные отношения с основными клиентами. В общем это уже мало имеет отношения к технике, в частности к защите кода.

Даже если аппаратная защита, это всего лишь фикция, это не повод ею пренебрегать. Работал и с AVR, сейчас работаю с STM и с Texas. Из нашего производства все изделия выходят залочеными. А механизм смены ПО организован через свой загрузчик, поток данных шифруется. Если производитель чипов предлагает встроенные механизмы защиты, то почему ими не пользоваться?

Питание 3,29В. Температура конечно отличается от 25, так как сейчас лето, но не более 40. Перегрева практически нет, так как частота равна половине от максимальной для этого чипа. На холодную, сразу после включения всё то же самое. Ещё на этом датчике напряжение уменьшается при увеличении температуры. Соответственно напряжению 1,86В соответствует примерно -75 градусов.

На картинке из документации видно, что 1,86В всё же далеко за допустимым диапазоном для этого кристалла. Т.е. отличие от номинала на 430мВ. Если это перевести в градусы, то будет примерно 100 градусов отклонения от нормы. Явно некоторая неадекватность показаний. Сделать калибровку несложно, но может быть это уже совсем нерабочий вариант.

В одном из устройств применяю встроенный датчик температуры для приблизительной оценки температуры и для защиты по перегреву. В течение достаточно длительного времени всё было нормально. Но в какой то момент (новая партия контроллеров), напряжение на выходе датчика при комнатной температуре стало существенно больше номинального. На выходе примерно 1,86В или 2300 попугаев при номинале 1,43В при 25 градусах. Это сильно выходит из допустимого диапазона. Частота самого кристалла, напряжение питания (оно же опорное для АЦП), частота АЦП и время измерения для датчика, - всё в пределах нормы. Все напряжения на аналоговых входах тоже в разрешенном диапазоне. Та же прошивка в контроллере из старой партии дает вполне адекватные показания по температуре. Контроллеры приобретались у известного Российского поставщика в обоих случаях. Каких либо проблем в маркировке не обнаружено. Кто нибудь сталкивался с подобным поведением?

Спасибо всем. Я всегда думал, что <> означают поиск в системных каталогах. Но если это позволяет исключить каталог, где находится текущий файл, то это как раз то, что мне нужно.