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

manul78

Участник
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

Информация о manul78

  • Звание
    Местный
  • День рождения 22.03.1978

Информация

  • Город
    Россия, г.Пенза
  1. Добрый день ! Спасибо всем за ответы, шутки, стёб, серьёзные советы. Но тему честно говоря я поднимал ради совсем других вещей. И пример с устройством приведён просто как пример, а не тема для обсуждения. А вопрос-то изначально был простой, но со сложными ответами. Попытка собрать в один список алгоритм действий для разработчика, у которого нет дикого бюджета, из аппаратуры только пара хороших компов, ноутбук, ST-Link, J-Link, цифровой осциллограф и простой недорогой логический анализатор. Устройство которое он делает не серийное, их может быть от силы пару штук, и оно заточено под конкретные цели - штучный товар. Дельные ответы изо всей "воды" здесь вылитой я всё-же получил: 1. Делать как минимум два экземпляра, дабы исключить глюки с железом из-за некачественной пайки, компонентов и пр. Также это пригодиться в процессе отладки, когда один экземпляр работает "в поле" а с другим можно заниматься в лаборатории на столе. 2. Сразу-же вести записи и документацию. Эдакий "бортовой журнал". Всё записывать и документировать. 3. В процессе разработки сразу предусмотреть как минимум один порт и интерфейс (UART,SPI,I2C) для отладки. Если нет места и ног - брать более функциональный чип из серии МК. 4. В процессе написания программы предусмотреть контрольные точки и индикацию происходящих в МК процессов, чтобы поиск неисправности не превратился в заглядывание под капот мчащегося на скорости 200 км/ч автомобиля - "всё шумит, всё крутится, ничего не понятно..." 5. ...... Далее прошу продолжить участникам данной темы, если не лень конечно...
  2. Цитата(jcxz @ Apr 24 2018, 18:40) А какой смысл отлаживать чьё-то гумно, на которое даже смотреть противно? Пишите своё. Я уже отвечал выше. "Это не моя война..." (с) Меня интересуют методы. Данный девайс и его глюки приведены как пример. Моя цель собрать воедино все советы и написать для себя и других базовый алгоритм действий при поиске неисправностей в железе и софте, дабы не метаться из угла в угол тратя время на "авось заработает" а действовать в четком направлении. Цитата(twix @ Apr 24 2018, 18:46) Поймать баг несложно на самом деле. Надо сделать всего три вещи. 1. Повесить на шину питания отдельный осциллограф и направить на экран обычную Web камеру с компа. И писать всю неделю видео. Как вариант взять четырехканальный и писать 4 канала. По видео точно найдете соответствие сбоя и питания. Стоит это копейки по любому. 2. Повесить отдельный канал логов на RS232 скажем и выдавать в него лог входа выхода во все подпрограммы, плюс тестовую информацию. Точно также писать неделю с временем входа, выхода в каждую подгрограмму. Сюда же загонять копию всех входных данных, которые поступают на модуль. Ну это и так будет видно если загонять в лог входные параметры подпрограмм. 3. Вместо реальных данных с датчиков, модулей протоколов, загнать шумовые цифровые данные по всем каналам с максимальной загрузкой. Все. Если сбой по питанию, это будет видно. Если методы неверно обрабатывают данные, имя метода который сбоит вылезет. Если входные данные валят программу, это вылезет не через неделю, а через час. Извините, но очень смешно... По питанию проблем нет и быть не может. Автомобильный аккумулятор и два линейных регулятора на 5 и 3.3 Вольта. Никаких импульсников и пр. Цитата(AlexandrY @ Apr 24 2018, 22:38) Учащение сбоев при увеличении трафика почти однозначно говорит о ситуации называемой "race condition" Если нет RTOS, то надо досконально перетрясти все прерывания на предмет использования глобальных переменных. Проще всего автору взять и искусственно увеличить частоту прерываний относящихся к интерфейсам. Особенно хорошо бывает когда частоты прерываний очень близки. Либо близки частоты главного цикла и прерываний. Тогда точки прерываний плавно проходят абсолютно по всему рабочему коду не оставляя белых пятен с возможными гонками. Вот здесь уже теплее... Человек, который давно уже бьётся с данным устройством связывает сбои именно с этим. Дело в том, что пакеты отправляемые "мастеру" фиксированной величины. Этим спокойно занимается DMA. А вот пакеты поступающие от "мастера" разной величины, поэтому разработчик сделал прием на прерываниях. Так как "мастеров" несколько, я также думаю что проблема в одновременном получении пакетов от нескольких "мастеров" сразу. Арбитраж видимо был не предусмотрен... Немножко об отладочной системе CoreSight... Кто-то тут писал про Segger-овский ULINK 2, так вот, у STM32 урезаная версия CoreSight, которая не поддерживает ETM Так что с трассировкой прерываний через крутой ULINK 2 пролёт...
  3. Цитата(iosifk @ Apr 24 2018, 15:33) Есть сокращение DFT. Там много чего написано, но это надо изучать ДО ТОГО КАК аппаратура сделана... https://www.google.ru/search?q=Design+For+T...ameter}ie=UTF-8 "Знали-бы где упасть - соломку подстелили-бы..." (с) Тут я полностью согласен. Быдлокодерство не подразумевает ни ведение грамотной документации, ни специальных программных вставок-решений для отладки. Слепили из "говна и палок" - заработало кое-как и ладно... А там хоть не рассветай... Цитата(HardEgor @ Apr 24 2018, 15:36) Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема. Второе грамотное предложение. Действительно, надо было сделать хотя-бы пару идентичных устройств, дабы в процессе тестирования и работы отсечь аппаратные неисправности, как-то битый МК, обвязка, комплектующие и пр. То есть чётко отделить железо от софта ЦитатаЕсли время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер. Время - есть. Денег - нет....
  4. Цитата(jcxz @ Apr 24 2018, 16:03) Внимательное ревью кода и обработка исключений творят чудеса даже при самых спонтанных багах Если честно - "Это не моя война..." (с) Софт писали какие-то студенты на Cube-HAL-е... Потом они уволились, допиливали другие... и т.д. Я привёл данный случай как пример. Но если софт писали дилетанты - это не значит, что не глючит софт написанный профессионалами, по всем канонам и со всеми ритуалами. Я запустил эту тему для себя, чтобы попробовать выжать экстракт из общего опыта поиска неисправностей. Универсального решения разумеется нет, но поределённые базовые шаги и грабли думаю будут интересны всем. Цитата(AlanDrakes @ Apr 24 2018, 16:03) А вообще - хороший вариант - внутренняя же трассировка проблемного события. Это когда код вместо резкой перезагрузки сохраняет состояние системы и пишет в консоль (или файл, а лучше в два) сообщение о том что произошло, когда, почему и дампы, дампы, дампы... Построить "своречник" вокруг столба с "девайсом", поставить там ноутбук и жить там-же... круглосуточно... Это устройство не в процессе разработки и не на стадии тестирования. Оно уже в сети, и на нем завязано производство. Я понимаю Вас. Меня интересуют "методы", пусть даже нестандартные. Возможно даже кто-то здесь имеет в своём распоряжении самопальные компактные супервазеры для STM32, я-же не прошу схему, код и готовые решения на халяву. Я ищу ВЕКТОР направления в котором двигаться.
  5. Цитата(HardEgor @ Apr 24 2018, 15:36) Сделать 10 одинаковых устройств, функционал распределить между ними. Там где сломается - там проблема. Вообще тема тестирования бесконечна. Если время=деньги, тогда надо брать крутой отладчик типа ULINKpro и через него писать лог в компьютер. Я уже писал в начале. С крутым отладчиком, в тёплой лаборатории и при достаточном бюджете... Девайс работает на отшибе на территории завода. К нему лишний раз не набегаешься, и лабораторию измерительную не соорудить вокруг. Глюки спонтанны, но как заметили связаны с увеличением траффика передаваемых данных.
  6. Цитата(Kabdim @ Apr 24 2018, 15:25) Постараться делить неопределенность на малые куски. Есть такая мысль. Решил слизать с промышленных контроллеров. Там один 8-ми битный порт отдают на real-time bug catcher. его подключают к прозрачному регистру-защёлке типа 74HC573 а выходы на 7 светодиодов. 7-бит "красный", 6-й "зелёный", остальные "жёлтые" Суть такая: Присваиваются номера. Процедурам на вход и на выход и нее, и прерываниям на вход и на выход. Например: Процедура A (0x01 -IN, 0x02 - OUT) , Процедура B (0x03-IN, 0x04 - OUT)..... и т.д. Прерывание A (0x41 -IN, 0x42 - OUT) , Пррерывание B (0x43-IN, 0x44 - OUT)..... и т.д. При прирывании по WWDT перед сбросом в информационном байте устанавливается 7-й бит в 1, это чтобы после сброса при начальных установках не скинуло содержимое регимтра-защёлки подключенной к bug-catcher порту. Процедуры и прерывания пишут свои номера при входе и выходе в порт. Регистр-защёлка их запоминает. В случае ступора или сброса, на светодиодах видно - где споткнулся МК. ЦитатаА эта темпа предметная или пофлудить об абстракте? 50/50... Есть проект "маршрутизатор-переводчик" промышленный. По 485-му "мастер" разговаривает с 232-ми "слейвами". Протоколы разные. они известны, но изменить их нельзя. Данный девайс получает пакеты, переводит их в нужный формат и отдаёт "слейвам", получает от них ответ, опять переводит в другой протокол и отправляет "мастеру". Вот такая штука из "говна и палок", работает... Но с глюками. Спонтанными. Может долго работать без сбоев. Но иногда частит. Суть в том, что глюки начинают вылазить при оживленном траффике по сети, если запросов-ответов мало может неделями работать без проблем. А вообще - то, мне тема интересная. Я большой любитель ловли "багов", и пофлудить не прочь. В любом случае это - ОПЫТ.
  7. Как поймать "Баг" на скорости 72 МГц ? (тема для обсуждения и поиска решения) Задача: Есть условное устройство на базе STM32F103C8 (Cortex-3M) которое работает на максимально разрешенной частоте в режиме максимальной нагрузки, то есть активно работает ядро АРМ, периферия, порты ввода-вывода, DMA, таймеры. В процессе длительной работы (неделя) систематически происходит сбой. Зацикливание, спонтанный неконтролируемый сброс МК и т.д. Всё это возможно по ряду причин: Сбой по питанию, переполнение стека или "кучи", кривой арбитраж шин или прерываний, неисправность МК. Причин масса. Вопрос: Как поймать сбой происходящий в периоде довольно длительного отрезка времени? У простого разработчика разумеется нет тех аппаратных возможностей которыми оперируют крупные лаборатории и производители серийных устройств, нет возможности обвешать "девайс" супервайзерами, логическими анализаторами и неделями круглосуточно гонять устройство, писать Log-и, а потом отрядом в 50 человек анализировать их. Стало быть нам придётся думать самим. Что у нас есть? Есть отладочная система CoreSight. Есть две "собаки" WatchDog таймера. Внутренний, зависимый от периферии и независимый автономный. Внутренний оконный WWDT, перед командой Сброса МК может сгенерировать прерывание. Данная опция специально разработана инженерами из STM для того, чтобы иметь возможность сделать дамп данных (память, состояние регистров, состояние периферии и т.д) перед сбросом системы МК. Что может быть проще? Написали в обработчике прерывания от "собаки" процедуру инициализации SPI,UART или I2C и выплюнули в внешнюю Флэш-память дамп всей оперативной памяти + состояние регистров. Далее считал с флэши и сиди анализируй - где споткнулся или завис МК. Бинго ! Это я описал самое очевидное и "тепличное" развитие событий. ТАК бывает... Но редко... А если контроллер прерываний "упал" или зациклился в одной точке? Если вообще ядро АРМ "упало" или зациклилось? А может вообще - стек налетел на "кучу" и управляющая программа рандомно пошла вразнос и остановила генераторы шин или периферии? В данном случае "собака" WWDT бессильна. Она мертва. Есть конечно ещё независимый IWWDT - но он не генерит прерываний - тупо сбрасывает контроллер. Есть отладочное CoreSight - до которого тоже ещё надо уметь достучаться. Так что Давайте высказываться, Уважаемые участники сообщества. У кого какие есть на это мысли и решения?
  8. STM32 и USB

    Цитата(x893 @ Feb 17 2018, 00:25) Любой вывод на выход, с него резистор 1.5К на D+ Ставите его в 0, пауза, в 1. Начинается нумерация. Попробовал - не помогло. Полазив по буржуйским форумам нашел кучу решений, но все из них зависят от конкретной "борды" и МК. Причём в одних случаях через транзистор и резистор в 1.5К одни сажают D+ на "землю" - другие на шину питания Сочленил вот такую схему: Теперь заработало. Видимо не хватало "мощщи" дабы посадить канал D+ на землю как следует. Но это зависит от Хоста или от конкретной входной схемы платы МК. Ваше решение вполне может работать на конкретно вашей плате. Покопавшись еще в сети нашел еще один "метод", в котором даже лишний пин использовать не надо и вообще никакой обвязки... ЦитатаCurrently when the STM32 is reset, its USB peripheral doesn't re-enumerate. According to this GitHub project, we could do this using some GPIO tricks : On "generic" boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode. This system to reset the USB was written by @Victor_pv. Note. It is not guaranteed to work on all "generic" STM32 boards, and relies on PA12 having a pull-up resistor of around 1.5k - however most "generic" boards seem to have this. Its unclear if this method to reset the USB bus conforms precisely to the USB standard, but it seems to work fine on all PC's and Mac's (and Linux boxes) on which its been tested - and seems usable for hobby / non commericial / non-critical systems. И его попробовал. Всё работает. Программно переключаем пин порта PA12 на ВЫХОД с Открытым стоком и сажаем USB D+ тупо на землю на 500 мс. Но я данный метод считаю варварским ибо тупо сажать канал на землю, по типу КЗ не есть гуд. Тем не менее он имеет место и им пользуются... Всем спасибо за помощь ! Если кому-то знакомы более цивилизованные методы (как пишут выше, используя свой USB стек) прошу поделиться. Заранее благодарен. P.S. Сижу ржу... В первом случае зачем-то повесил резистор на 1.5К, если в случае конфигурации порта как выход с открытым стоком - в случае А) Выход в Hi-Z состоянии, а в случае Б) линия USB D+ (PA12) тупо стекает накоротко на землю. Резистор нужен тут как собаке пятая нога... От него только лишняя помеха на линии... P.P.S. Цитата(x893 @ Feb 17 2018, 00:25) Любой вывод на выход, с него резистор 1.5К на D+ Уменьшил резистор до 500 Ом - заработало...
  9. STM32 и USB

    День добрый всем ! Работать с STM32 я начал недавно, поэтому сильно не пинайте. Суть такая: Есть МК stm32f103c8t6. В процессе настройки программы я использовал UART и переходник-мост USB-COM. Но ведь на борту имеется USB модуль. Взял шаблон из библиотеки и организовал в контроллере CDC устройство, то бишь Виртуальный COM порт. Всё работает, всё нормально. Единственная загвоздка, что каждый раз после сброса МК он перегружается, а вот хост на компе нет. Поэтому приходиться тупо выключать и обратно включать тем самым проводить повторную энумерацию и т.д. Физически. Мне это надоело, постоянно вынимать и опять вставлять штекер разъёма. На Мегах АВР с USB всё было много проще. Функции Attach() и Detach(). С библиотеками для STM32 всё сложнее. Никак не могу организовать программно со стороны МК подключение к компу заново. Нашёл в библиотеках STM32 функции Код@brief  Connect the USB device   * @param  hpcd: PCD handle   * @retval HAL status   */ HAL_StatusTypeDef HAL_PCD_DevConnect(PCD_HandleTypeDef *hpcd) {   __HAL_LOCK(hpcd);   HAL_PCDEx_SetConnectionState (hpcd, 1);   USB_DevConnect(hpcd->Instance);   __HAL_UNLOCK(hpcd);   return HAL_OK; } /**   * @brief  Disconnect the USB device   * @param  hpcd: PCD handle   * @retval HAL status   */ HAL_StatusTypeDef HAL_PCD_DevDisconnect(PCD_HandleTypeDef *hpcd) Вроде как аналоги Attach() и Detach(). В мануале сказано, что HAL_PCD_DevDisconnect() даёт команду хосту на отключение, затем надо сделать паузу не менне 5 мс, далее вызываем HAL_PCD_DevConnect() и хотст проводит новую процедуру энумерации, как было-бы если я тупо вынул и вставил по новой штекер USB устройства в Хост. Но что-то никак не получается... "Люди добрые ! Поможите чем можете ! (с) Может я чего не понимаю, или криво делаю. Если есть примеры кода - напишите пожалуйста. Без разницы, хоть в прямом доступе к регистрам, хоть SPL, HAL или LL... Мне главное суть присходящего понять, и вообще возможно-лт это ? Заранее благодарен за ответы.
  10. STM32F103C8+USART+LL

    Цитата(manul78 @ Jan 26 2018, 10:49) Видимо какие-то глюки в программных настройках порта. Кривая библиотека что-ли ? UPD: Разобрался, но не совсем... При помощи "говна и палок" запустил таки. Пришлось использовать для инициализации портов столь ненавистный мне HAL... Его драйвер рабочий. Кодstatic void MX_GPIO_Init(void) {   GPIO_InitTypeDef GPIO_InitStruct;   /* GPIO Ports Clock Enable */   __HAL_RCC_GPIOD_CLK_ENABLE();   __HAL_RCC_GPIOA_CLK_ENABLE();   /*Configure GPIO pin Output Level */   HAL_GPIO_WritePin(GPIOA, GPIO_PIN_9, GPIO_PIN_RESET);   /*Configure GPIO pin : PA11 */   GPIO_InitStruct.Pin = GPIO_PIN_9;   GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;   GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;   HAL_GPIO_Init(GPIOA, &GPIO_InitStruct); } Ну а потом закомментировать в инициализации USART1 настройки порта при помощи LL драйвера. Код/* USART1 init function */ static void MX_USART1_UART_Init(void) {   LL_USART_InitTypeDef USART_InitStruct;   //LL_GPIO_InitTypeDef GPIO_InitStruct;   /* Peripheral clock enable */   LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_USART1);      /**USART1 GPIO Configuration     PA9   ------> USART1_TX   PA10   ------> USART1_RX   */        //GPIO_InitStruct.Pin = LL_GPIO_PIN_9;   //GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;   //GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;   //GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;   //LL_GPIO_Init(GPIOA, &GPIO_InitStruct);   //GPIO_InitStruct.Pin = LL_GPIO_PIN_10;   //GPIO_InitStruct.Mode = LL_GPIO_MODE_FLOATING;   //LL_GPIO_Init(GPIOA, &GPIO_InitStruct);   USART_InitStruct.BaudRate = 115200;   USART_InitStruct.DataWidth = LL_USART_DATAWIDTH_8B;   USART_InitStruct.StopBits = LL_USART_STOPBITS_1;   USART_InitStruct.Parity = LL_USART_PARITY_NONE;   USART_InitStruct.TransferDirection = LL_USART_DIRECTION_TX_RX;   USART_InitStruct.HardwareFlowControl = LL_USART_HWCONTROL_NONE;   LL_USART_Init(USART1, &USART_InitStruct);   LL_USART_ConfigAsyncMode(USART1);   LL_USART_Enable(USART1); } Вот ТАКОЙ гибрид получился. Унылый. Но работает. Виноват кривой LL драйвер портов GPIO. Где конкретно грабли в stm32f1xx_ll_gpio.c или в stm32f1xx_ll_gpio.h пока не знаю. Знаю только что библиотека кривая. Пол года уже. author MCD Application Team version V1.1.1 date 12-May-2017 GPIO LL module driver. Привет компании STM и MCD Application Team... Тему не закрываю. Постараюсь найти где именно ошибка. Если кто-то уже налетал на эти грабли - пишите, чтобы другие не наступали. P.S. Кто-то разумеется спросит: "Зачем мне это нужно ? ". Отвечаю. Почти год писал для STM32F030F4 исключительно используя библиотеку LL, привык, код компактный, всё понятно. Никаких нареканий не было. Честно, говоря она мне даже нравится.
  11. STM32F103C8+USART+LL

    День добрый всем ! Для быстрого старта использую CubeMX. При генерации кода использую исключительно библиотеку Low Layer (LL) Работал с STM32 F0, а конкретно с простейшим STM32F030F4 - всё работало как часы. Никаких проблем. Для МК STM32F103 библиотеки LL не было, поэтому обходился шаблонами SPL и не парился. Но вот в январе этого года вышло обновление для CubeMX, куда добавили генерацию кода LL и для STM32F103 Решил попробовать и никак. Какие-то видимо проблемы с установкой регистров GPIO при настройке USART1 Смотрю дебаггером - в установках порта не меняются биты регистра CRH порта GPIOA. В битах MODE9 и CNF9 0x00 и 0x01 соответственно, то есть 9-я нога порта GPIOA (USART TX) сконфигурирована на ВХОД с Открытым стоком. Процедура инициализации в LL: Кодstatic void MX_USART1_UART_Init(void) {   LL_USART_InitTypeDef USART_InitStruct;   LL_GPIO_InitTypeDef GPIO_InitStruct;   /* Peripheral clock enable */   LL_APB2_GRP1_EnableClock(LL_APB2_GRP1_PERIPH_USART1);      /**USART1 GPIO Configuration     PA9   ------> USART1_TX   PA10   ------> USART1_RX   */   GPIO_InitStruct.Pin = LL_GPIO_PIN_9;   GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;   GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;   GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;   LL_GPIO_Init(GPIOA, &GPIO_InitStruct);   GPIO_InitStruct.Pin = LL_GPIO_PIN_10;   GPIO_InitStruct.Mode = LL_GPIO_MODE_FLOATING;   LL_GPIO_Init(GPIOA, &GPIO_InitStruct);   USART_InitStruct.BaudRate = 115200;   USART_InitStruct.DataWidth = LL_USART_DATAWIDTH_8B;   USART_InitStruct.StopBits = LL_USART_STOPBITS_1;   USART_InitStruct.Parity = LL_USART_PARITY_NONE;   USART_InitStruct.TransferDirection = LL_USART_DIRECTION_TX_RX;   USART_InitStruct.HardwareFlowControl = LL_USART_HWCONTROL_NONE;   LL_USART_Init(USART1, &USART_InitStruct);   LL_USART_ConfigAsyncMode(USART1);   LL_USART_Enable(USART1); } После инициализации USART - регистры USART настраиваются как надо. A вот пин 9 (TX) порта GPIOA остаётся в том-же состоянии. На ВХОД с открытым стоком. Хотя должно быть в битах MODE9 и CNF9 0x01 и 0x02 то есть Порт А на ВЫХОД 10 Мгц и АЛЬТЕРНАТИВНЫЙ ВЫХОД Push-Pull Что такое - не понимаю. Ради интереса открыл старый проект на STM32 F030F4 и посмотрел процедуру инициализации - она немного другая. И всё работает. Полез посмотреть драйвер для stm32f1xx_ll_gpio.c разумеется он отличается. Сильно упрощен. Для примера привожу код процедуры инициализации USART для библиотеки LL и STM32 F0, он 100% рабочий. Код/* USART1 init function */ static void MX_USART1_UART_Init(void) {   LL_USART_InitTypeDef USART_InitStruct;   LL_GPIO_InitTypeDef GPIO_InitStruct;   /* Peripheral clock enable */   LL_APB1_GRP2_EnableClock(LL_APB1_GRP2_PERIPH_USART1);      /**USART1 GPIO Configuration     PA9   ------> USART1_TX   PA10   ------> USART1_RX   */   GPIO_InitStruct.Pin = LL_GPIO_PIN_9;   GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;   GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;   GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;   GPIO_InitStruct.Pull = LL_GPIO_PULL_UP;   GPIO_InitStruct.Alternate = LL_GPIO_AF_1;   LL_GPIO_Init(GPIOA, &GPIO_InitStruct);   GPIO_InitStruct.Pin = LL_GPIO_PIN_10;   GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;   GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;   GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;   GPIO_InitStruct.Pull = LL_GPIO_PULL_UP;   GPIO_InitStruct.Alternate = LL_GPIO_AF_1;   LL_GPIO_Init(GPIOA, &GPIO_InitStruct);   /* USART1 interrupt Init */   NVIC_SetPriority(USART1_IRQn, 0);   NVIC_EnableIRQ(USART1_IRQn);   USART_InitStruct.BaudRate = 115200;   USART_InitStruct.DataWidth = LL_USART_DATAWIDTH_8B;   USART_InitStruct.StopBits = LL_USART_STOPBITS_1;   USART_InitStruct.Parity = LL_USART_PARITY_NONE;   USART_InitStruct.TransferDirection = LL_USART_DIRECTION_TX_RX;   USART_InitStruct.HardwareFlowControl = LL_USART_HWCONTROL_NONE;   USART_InitStruct.OverSampling = LL_USART_OVERSAMPLING_16;   LL_USART_Init(USART1, &USART_InitStruct);   LL_USART_DisableIT_CTS(USART1);   LL_USART_EnableOverrunDetect(USART1);   LL_USART_EnableDMADeactOnRxErr(USART1);   LL_USART_ConfigAsyncMode(USART1);   LL_USART_Enable(USART1); } Но он более насыщенный чем для F103. Где грабли ? Всю башку сломал.... Заранее благодарен за ответы. UPD. Меняю в дебаггере биты настройки порта вручную - всё заработало... Видимо какие-то глюки в программных настройках порта. Кривая библиотека что-ли ?
  12. ATmega8515 + SRAM

    Пользуясь случаем, дабы не создавать новый топик, хочу спросить у тех кто много работал/работает с AVR Studio У меня стоит студия "Семёрка". Но в ней нет симуляции 8515... Считается древним камнем. В AVR Studio 4.19 разумеется есть симулятор. Вопрос: Можно заставить в настройках видеть в окнах Memory помимо Data,I/O,EEPROM,Reg видеть внешнюю память ? По умолчанию доступна только внутренняя. Настройки Linker-а на студию как я понял не действуют. То есть я распределяю "кучу", стек, и пр. Всё как надо. Upd: Нашел... Debug --> AVR Simulation options (Alt + O) --> Device selection --> галочка Use External memory.
  13. ATmega8515 + SRAM

    Цитата(zombi @ Apr 19 2017, 14:24) Еще в #9 сообщении я спросил меняли ли мегу. Но ТС с шутками, прибаутками и анекдотами упорно продолжал тулить какие-то триггера и делать странные умозаключения. Адрес буржуйского форума держите в секрете? Да что-то за 20 лет практики (промышленное оборудование) не сталкивался в полудохлыми МК, обычно на МК думаешь в самую последнюю очередь. Ну бывало порты выгорали, прошивка слетала, крыша съезжала у МК тоже встречал, но вот чтобы "то работает то нет" это первый случай. Обычно в промышленности используются довольно надёжные крепкие и толерантные к помехам схемы. Да и менять то было не на что. https://wiki.mcselec.com/bavr/Adding_XRAM_w...emory_Interface
  14. ATmega8515 + SRAM

    Цитата(Baser @ Apr 19 2017, 12:53) Для записи вам нужно, чтобы на входах памяти данные были заранее перед стробом записи. И держаться после строба тоже еще определенное время. Иначе будут сбои как у вас. Вот вы все картинки показываете, а они то типовые, всем хорошо известны. Важны именно цифры. После того как я заменил 62256-10 на 6264-70 - к записи данных претензий не было. Проблема была с чтением. Да и как я мог оперировать временными параметрами, если использовал аппаратный интерфейс микроконтроллера 8515 для работы с внешней памятью ? Там всего 4 бита управления задействованы. SRW - вкл/выкл интерфейс. SRW10 и SRW11 - выбор числа тактов ожидания (4 варианта соответственно) XMBK - Bus Keeper вкл/выкл. Про биты разрядности старшего байта XMM0, XMM1, XMM2 и биты определения секторов внешней памяти SRL0, SRL1, SRL2 я молчу, они роли не играют.
  15. ATmega8515 + SRAM

    Всем доброго дня ! Когда сегодня 19 апреля 2017-го года я утром выглянул в окно и увидел, что выпало 15 см снега я подумал, что теперь меня уже ничем не удивишь, тем более глюками с МК... Но это так... лирическое отступление. Значится так. Первым делом сегодня я проверил сохраненные фьюзы родной заводской прошивки. И таки да. 4 МГц внутреннего генератора. Вероятно поляки посадили кварц на 7.3728 МГц и вывели RS-232 для каких-то своих отладочных целей, или это просто базовая плата МК с памятью, универсальная для разных применений. Вот что и изначально сбило меня. До 10 утра гонял тесты с моей доработкой в виде D-триггера. Ошибок нет от слова ВООБЩЕ. Так как родная прошивка работает на 4 МГц и надо проверить работу памяти на этой частоте - спаял приблуду на К176ИД2 и семисегментном индикаторе дабы видеть результаты тестов без использования USART. Прогнал тесты на 4 МГц-ах - ошибок нет. Залил заводскую прошивку и поставил на оборудование. В тестовом режиме разумеется... Всё работает. В 11 часов привозят новую АТмегу8515 в DIP40... Время есть. Решил проверить ВСЁ. Подцепил новую АТмегу. Залил тесты. Всё работает. Ошибок нет. Отцепил свой триггер и вернул всё в назад как было изначально. И... Всё работает. Ошибок нет. Переключился на внешний кварц 7.3728 - всё работает. Ошибок нет. Решил добить всю схему до конца и поставил старую родную память HM62256-120, защёлку оставил 74ALS573, не стал менять на НС. Прогнал тест. На 7.3728 - более 10% ошибок, то есть более 800 на 8Кб. На 4 МГц - менее 0.1% ошибок, то есть 1-2 на 8Кб. Ставил дополнительные циклы - изменения незначительные. На 7.3728МГц - куча ошибок, на 4 МГц - 1-2... Исходя из этого, вернул UT6264, залил заводскую прошивку, выставил 4 Мгц внутреннего генератора и поставил на оборудование. Всё работает. Считаю, что проблема была комплексная. Старая АТмега8515 с поплывшими мозгами/портами + сдохшая не известно по какой причине защёлка + тупая 120нс память 88-го года выпуска. Прошу всех извинить меня за резкости и кривую постановку задачи и её обсуждение. Торопился, злился, писал с телефона и пр... Тему можно считать закрытой. Всем огромное спасибо за помощь и сотрудничество ! P.s. Для тех кому интересно, оборудование - австрийский термопластавтомат ENGEL, доработанный поляками и проданный в Россию 15 лет назад.