Перейти к содержанию
    

Сергей Борщ

Модератор
  • Постов

    10 921
  • Зарегистрирован

  • Посещение

  • Победитель дней

    31

Весь контент Сергей Борщ


  1. Подводя итог: что-то непропаяно было во второй плате, хотя прозванивал несколько раз. Сейчас на второй плате все летает как USB high-speed c настройками скорости ног ULPI и HIGH и VERY_HIGH и MEDIUM, на первой так и не работает, но это цель дальнейших исследований. Чтобы USB334x определялся как high-speed нужно в регистре DCFG выставить в 1 бит XCVRDLY. Без этого оно определяется как full-speed (причина описана в errata USB3340, решение найдено на буржуйских форумах). Для F2xx, F4xx, F7xx все то же самое, причем этот бит в заголовочном файле CMSIS не описан, хотя в руководстве пользователя F7xx, H7xx он есть. И еще: Это тоже работает в H725. Вдруг кому-то пригодится диагностировать...
  2. Я ставлю массив размером 0. Тогда предупреждений нет.
  3. Простите, что со своим самоваром встреваю, но в первой странице-двух располагаю загрузчик, позволяющий передавать заказчику зашифрованный образ обновленной прошивки и заливать его через имеющийся интерфейс (а не тот, который решили использовать ST), далее еще один маленький сектор на настройки и все остальное под рабочую программу, ей уже все равно, какого размера сектора.
  4. Я не знаком с этим контроллером, но может ему надо периодически ставить в очередь команду вроде Get_status?
  5. Ну кто бы мог подумать, что выводам ULPI надо настраивать скорость не VERY_HIGH, а HIGH... Теперь мой код тоже определяется компом как неотвечающее low-speed устройство. Ну хоть какой-то прогресс...
  6. Такс, стоило написать на форум и есть подвижка - код куба, естественно, не трогает ногу RESET физики. Дописал ее отпускание после настройки MCO2 и появилась какая-то жизнь. Код больше не виснет на сбросе, доходит до главного цикла в main(). Тот неописанный регистр ведет себя так же, как в моей программе, видимо в нем что-то поменяли. Но хоть какая-то жизнь есть - комп находит low-speed устройство, из которого ничего не может вычитать. Буду копать свой код дальше...
  7. Отладил макет на лежавшей в тумбочке Nucleo-F767 и USB3340 "на проводах". Все запустилось на самописном стеке USB, который плавно мигрировал с F407 на F207, F107, теперь вот и на встроенной физике F767 взлетел, а потом и на внешней. Пришло время делать рабочую конструкцию, посмотрел доступность F767 - прослезился в том числе и от цен. Решил поставить H725 - "модно, стильно молодежно", дешевле вдвое и USB, на первый взгляд, такой же. Получил платы, распаял, переписал тактирование - а фиг, реакции на втыкание кабеля USB никакой. Нашел в интернете упоминание файла из примеров куба, в котором используется обращение к недокументированному регистру F4xx, F7xx для доступа к регистрам физики. Проверил на F767 - да, Vendor ID из физики вычитывается. Попробовал на своей плате с H725 - фиг, в регистре взводится флаг BUSY и все, а должен потом упасть и взвестись DONE. Уже дня четыре бьюсь -- схему проверил, дорожки прозвонил, микросхему физики менял местами с рабочей, которая к Nucleo-F767 подпаяна была, вторую такую же плату собрал - она ведет себя точно так же. Наблюдаю только 60 МГц на ULPI_CK, постоянные уровни на D0-D7, низкие на ULPI_DIR, ULPI_NXT и пачки импульсов на ULPI_STP. Проверил правильность включения ключей на PC2_C, PC3_C, настройку ног. Уже не знаю, куда копать дальше. От отчаяния скачал/поставил куб, создал а нем проект с одним USB DEVICE CDC_ACM, настроил MCO2 на выдачу необходимых физике 12 МГц, прошил - этот проект валится на USB_CoreReset() - выставляет CSRST и не может дождаться его сброса. В errata про USB ни слова. Встречал упоминания, что у людей работает внешняя физика на H740, подумал купить его - так у него ноги не совпадают, на каждой стороне все нужные ноги включая питание туда-сюда на одну смещены... Собственно вопрос - кто-то запускал H725 с внешней ULPI-физикой? Может я зря трачу время и оно в принципе неработоспособно?
  8. Вставлял. Но когда оборачивал в сворачиваемую форму оно потерялось. Исправил.
  9. у меня в lwipopts.h стоит такое: Дальше ищите в исходниках "CHECKSUM_GEN" и "CHECKSUM_CHECK". И не забывайте, что может работать или одно, или другое. То есть если вы включаете программный подсчет, то аппаратный обязаны выключить и наоборот.
  10. То это "случайно, при невыясненных обстоятельствах в недокументированной области Option Bytes сбросился битик-рудимент от STM32WL55". В эррате этого (пока?) нет. Вдруг кому-то пригодится... https://community.st.com/t5/stm32-mcus/stm32wl55-and-stm32wle5-radio-timeout-issues-a-technical-faq-on/ta-p/615640 Кого не пускают - это бит SUBGHZSPISD из документации на STM32WL55 (бит 31 по адресу 0x1FFF7870)
  11. Не знаю, как насчет светодиодов, но две лампы накаливания по 50 Вт светят тусклее, чем одна на 100 Вт, потому что у них ниже температура спирали.
  12. Это я писал из головы и не успел исправить (отвлекли). struct sTxMsgCommand { u32 cmd, crc; }; using sTxMsgRequest = sTxMsgCommand;
  13. using тут не нужен. Он немного для другого: struct { u32 cmd, crc; } sTxMsgCommand; using sTxMsgRequest sTxMsgCommand;
  14. Тогда что вы предлагаете сравнивать? Зазоры у вас другие, ширина дорожек другая, диаметр отверстий другой, количество другое, плюс за кадром осталась некая неозвученая "оговоренная стоимость подготовки".
  15. Магическое слово "Повтор" на цену не влияет случайно?
  16. Следите за руками: Пусть регистр для простоты будет 4-битным и этот ваш бит для простоты будет нулевым, то есть TIMER_INTF_CH0IF будет равно 0b0001. Вот программа добралась до вашего &= и INTF в этот момент равен 0b0001. read считает из него куда-то внутрь процессора 0b0001 в этот момент взвелся еще один флаг и INTF стал равен 0b0101 ~TIMER_INTF_CH0IF будет 0b1110 в процессе modify считанное куда-то внутрь процессора 0b0001 & 0b1110 дадут 0b0000. далее write это полученный 0 запишет в INTF и это сбросит все биты в INTF, то есть в нем получится 0b0000. Теперь понятно, что этот макрос сбросит все биты и выделенный бит вы потеряли? Перед Струструпом надо двоичную арифметику освоить до вычислений в уме. С этого обычно начинают.
  17. GD32, как известно, при включении питания переписывает информацию из последовательной флешки в теневое ОЗУ. Вроде бы это примерно 150 мс и занимает. Но тут речь идет о секундах, а "это другое".
  18. Да, они там такие и есть. Это же очевидно: &= - операция типа "чтение-модификация-запись", если между чтением и записью в этом регистре установится еще какой-то флаг (флаги) - они будут сброшены и вы их потеряете. И, вдобавок, совершенно ненужное чтение регистра. Если вам что-то непонятно в ответах - всегда можно задать уточняющий вопрос "почему". Хамить - последнее, дело. Прощайте.
  19. Похоже, даже нужное место выложенное прямо сюда в виде картинки прочитать не удосужился 😡 Хотя утверждает, что код исправил. Но виноваты все остальные.
  20. Модератор: Почему-то опять раздел "предлагаю работу" начинает превращаться в балаган. Пока просто почистил, но считайте это первым и последним устным предупреждением.
  21. "Мыши плакали, кололись, но продолжали жрать кактус" А отладчика нет, чтобы отправку по шагам пройти?
  22. В первом сообщении Ксения сообщает, что когда проблемы начинаются - виснет все. И вместо того, чтобы разобраться в коде куба, найти и исправить там ошибку (при правильной работе через регистры без куба там ничего не виснет, я уверяю), она с упорством, достойном лучшего применения, решила кубовый код обвешать костылями. Мы можем ей только посочувствовать - мешать не вправе.
×
×
  • Создать...