amiller

На входе у вас 6 аналоговых каналов. На выходе тоже 6 каналов разностей и сумм. А почему бы не сделать предварительные вычисления разностей и сумм аналоговых сигналов на ОУ? Тогда нет особых требований к синхронизации работы АЦП. Считывайте себе с нужной скоростью, с помощью ДМА укладывайте в память. Задача простая.

Ну если вы всегда лочили свои устройства на уровень 2, то наверное для вас проблем особых и нет. Я до сегодняшнего дня считал достаточным уровень 1. И при наличии тысяч уже работающих устройств, это может представлять проблему. А глубина проблемы зависит от работоспособности этого метода взлома. Я, честно говоря, о взломе левел 1 не слышал, пока не прочитал этот пост. На а если предположить, что механизм взлома работает для всех STM32, то и уровень 2 уже не выглядит таким уж безупречным. К сожалению вопрос выходит на уровень доверия как к STМ32, так и ко всем клонам этой архитектуры...

А я скорее огорчён. Раньше всегда использовал, уровень 1 для защиты от взлома. Если кто-то пробовал описанный механизм, прошу отписаться. Если работает, то по сути это означает конец этого механизма защиты. Только уровень 2, а значит невозможность повторного использования кристаллов. Или уже есть механизмы разлочивания с второго уровня? Не удивлюсь...

Нет, именно 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 градусах. Это сильно выходит из допустимого диапазона. Частота самого кристалла, напряжение питания (оно же опорное для АЦП), частота АЦП и время измерения для датчика, - всё в пределах нормы. Все напряжения на аналоговых входах тоже в разрешенном диапазоне. Та же прошивка в контроллере из старой партии дает вполне адекватные показания по температуре. Контроллеры приобретались у известного Российского поставщика в обоих случаях. Каких либо проблем в маркировке не обнаружено. Кто нибудь сталкивался с подобным поведением?

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

Использую IAR 7.80.4. При работе с новым проектом решил использовать несколько исходников от старого проекта. Соответственно включил их в новый проект. Но физически файлы остались в каталогах старого проекта. В этих файлах есть строки типа: #include "define.h", где настраивается функционал. Соответственно нужные хидеры в новом проекте лежат в каталоге, который прописан в путях проекта в опциях "include". И я предполагал, что они будут взяты именно оттуда. Но выяснилось, что в каталоге, где находится подключаемый "*.c", лежит хидер с таким же именем. При компиляции был подключен файл из старого проекта, а не из нового (молча). Когда доступный хидер из старого проекта был переименован, то также молча был найден и подключен хидер уже из нового проекта. Естественно, что каталог, где находится подключаемый "*.c", в новом проекте нигде не упоминается. Вышел из положения, скопировав нужные файлы в новый проект, но это вроде как не совсем правильно. Что скажете, так и должно быть?

Нет такого понятия, как полигон питания, и соответственно требований к нему. И редко когда на плате одно питание, обычно есть 5В, 3,3В, отдельно аналоговое питание, опорное напряжение. При многослойной разводке выделили один слой под землю, - хорошо. По остальным слоям максимальное количество площади под землю. Один слой выделяйте под линии питания. Питание ведете достаточно широкими, но отдельными проводниками. В полигонах здесь нужды нет. Если линия связи не имеет переходных отверстий, то проводите её сверху или снизу, если позволяет площадь платы. Если переходные отверстия есть, то уводите линию на внутренний слой (питания). Земляные полигоны в разных слоях часто сшивайте переходными отверстиями. При большом количестве пересечений, используйте географический принцип: в одном слое линии по горизонтали, в другом - по вертикали. А вообще есть на форуме специализированный раздел по разводке, почитайте. Разводка АРМов принципиально ничем не отличается. Если на плате есть силовые компоненты и управление, полезно деление полигонов земли на чистую землю и грязную, с соединением в одной точке. Это сильно помогает уменьшить помехи и шумы.

Можно примерно так: Формируется набор флагов. Каждый флаг устанавливается отдельно в своем критичном таске или прерывании. С определенным интервалом происходит проверка флагов. Если хотя бы один флаг не установлен, то сброса WDT не происходит. А после успешного сброса WDT все флаги сбрасываются и снова всё по кругу. И неважно при этом задействован внешний таймер или внутренний.

У меня кстати наоборот, не получается стереть залоченый STM8 через IAR. А через STVP пожалуйста: Открываю STVP, перехожу на вкладку Option Byte. По умолчанию там всё в дефолте. И нажимаю кнопку "Program current tab". В итоге получаю чистый кристалл, со всеми настройками по умолчанию. P.S.: Работаю через ST-LINK V2.

Судя по всему в этой прошивке используется память в диапазоне 0x0000 - 0x3F80. Так как адресация 16 битная, то подразумевается, что базовый адрес равен нулю. А бутлоадер должен находится в примерном диапазоне 0xF000 - 0xFFFF. Такими адресами здесь и не пахнет. Вывод: Это прошивка пользовательской программы. Таким простым способом бутлоадер не достать. Советую посмотреть на программу, с помощью которой Вы читаете кристалл. Если микросхема не залочена, то где то в конфигах надо явно указать диапазон, который Вы хотите прочитать. И ещё: Есть уверенность, что секция бутлоадера , это flash, и её в принципе можно писать? Может это ОТР? Я никогда с такими микросхемами не работал. Но точно существует документация на семейство, где всё это подробно расписано.

Похоже, что не совсем правильно Первая строка: 10 - количество байт = 16. 0FD0 - смещение относительно базы. 00 - признак данных Далее 16 байт, на каждый байт по 2 символа. Последние 2 символа в строке = BF, это CRC. Ещё где то ранее должна быть служебная строка, которая задает базовый адрес (старшие байты). И в самом конце массива должна быть строка, конец файла.

Излишнее усложнение. Компоненты D1, U1, R4, R5, C3 можно заменить просто транзистором. А на стороне приемника достаточно входа АЦП контроллера. Но это всё хорошо, когда передаваемая мощность меньше 1Вт и допустимы пульсации 1В. А если надо по цепи питания передавать 100Вт и пульсации более 50мВ недопустимы? В этом случае понадобятся более сложные решения. я бы в таком случае не стал заморачиваться и выделил ещё один провод для связи между модулями.