Hiehachi

Нет. Не удается. Даже при неправильной конфигурации периферии, если забыл законфигурировать CLK или обратился в несуществующей памяти, частенько бывает чтобы вывести STM32 из состояния внутрененего покоя, нужно на BOOT0 - 1 подать, чтоб злокод написаный не выполнялся. Это касательно отладки через SWD, не JTAG. Ввиду творческого порыва и смелого духа, на JTAG пинов не резервируем, только SWD.

Делал для 800x600 в палитровом режиме 8-бит цвет, фреймбуфер на внешнюю SDRAM указывает, дисплей аналогичный по интерфейсу, процессор 429 . Посмотри может Ты чего пропустил, код инициализации рабочий. void LCD_Config(void) { LTDC_InitTypeDef LTDC_InitStruct; LTDC_Layer_InitTypeDef LTDC_Layer_InitStruct; RCC_PLLSAICmd (DISABLE); RCC_PLLSAIConfig(320, 7, 2); RCC_LTDCCLKDivConfig(RCC_PLLSAIDivR_Div4); RCC_PLLSAICmd(ENABLE); while(RCC_GetFlagStatus(RCC_FLAG_PLLSAIRDY) == RESET) { } RCC_APB2PeriphClockCmd(RCC_APB2Periph_LTDC, ENABLE); InitTFTPinout(); LTDC_InitStruct.LTDC_HSPolarity = LTDC_HSPolarity_AL; LTDC_InitStruct.LTDC_VSPolarity = LTDC_VSPolarity_AL; LTDC_InitStruct.LTDC_DEPolarity = LTDC_DEPolarity_AL; LTDC_InitStruct.LTDC_PCPolarity = LTDC_PCPolarity_IPC; LTDC_InitStruct.LTDC_HorizontalSync = 40; LTDC_InitStruct.LTDC_VerticalSync = 20; LTDC_InitStruct.LTDC_AccumulatedHBP = 46; LTDC_InitStruct.LTDC_AccumulatedVBP = 23; LTDC_InitStruct.LTDC_AccumulatedActiveW = 1056; LTDC_InitStruct.LTDC_AccumulatedActiveH = 635; LTDC_InitStruct.LTDC_TotalWidth = 1058; LTDC_InitStruct.LTDC_TotalHeigh = 637; LTDC_InitStruct.LTDC_BackgroundRedValue = 0; LTDC_InitStruct.LTDC_BackgroundGreenValue = 0; LTDC_InitStruct.LTDC_BackgroundBlueValue = 0; LTDC_Init(&LTDC_InitStruct); LTDC_Layer_InitStruct.LTDC_HorizontalStart = 46; LTDC_Layer_InitStruct.LTDC_HorizontalStop = (800 + 45); LTDC_Layer_InitStruct.LTDC_VerticalStart = 23; LTDC_Layer_InitStruct.LTDC_VerticalStop = (600 + 22); LTDC_Layer_InitStruct.LTDC_PixelFormat = LTDC_Pixelformat_L8;//LTDC_Pixelformat_AL44;//LTDC_Pixelformat_ARGB4444; LTDC_Layer_InitStruct.LTDC_ConstantAlpha = 255; LTDC_Layer_InitStruct.LTDC_BlendingFactor_1 = LTDC_BlendingFactor1_CA; LTDC_Layer_InitStruct.LTDC_BlendingFactor_2 = LTDC_BlendingFactor2_CA; LTDC_Layer_InitStruct.LTDC_DefaultColorBlue = 0; LTDC_Layer_InitStruct.LTDC_DefaultColorGreen = 0; LTDC_Layer_InitStruct.LTDC_DefaultColorRed = 0; LTDC_Layer_InitStruct.LTDC_DefaultColorAlpha = 0; //LTDC_Layer_InitStruct.LTDC_CFBStartAdress = (uint32_t)&L8BIT; LTDC_Layer_InitStruct.LTDC_CFBStartAdress = VideoAdress; //FillMems (&L8BIT[0],10000,80); //FillMems (&L8BIT[10000],10000,20); //FillMems (&L8BIT[20000],10000,50); //FillMems (&L8BIT[30000],10000,70); //FillMems ((unsigned char*)VideoAdress,10000,80); //FillMems ((unsigned char*)(VideoAdress+10000),10000,20); //FillMems ((unsigned char*)(VideoAdress+20000),10000,50); //FillMems ((unsigned char*)(VideoAdress+30000),10000,70); LTDC_Layer_InitStruct.LTDC_CFBLineLength = (803); LTDC_Layer_InitStruct.LTDC_CFBPitch = (800); LTDC_Layer_InitStruct.LTDC_CFBLineNumber = 600; LTDC_LayerInit(LTDC_Layer1, &LTDC_Layer_InitStruct); LTDC_colorkeying_InitStruct.LTDC_ColorKeyBlue = 0; LTDC_colorkeying_InitStruct.LTDC_ColorKeyGreen = 0; LTDC_colorkeying_InitStruct.LTDC_ColorKeyRed = 0; TFT_CLUT_Init ((unsigned char*)resname_pal_f); LTDC_LayerCmd(LTDC_Layer1,ENABLE); LTDC_ReloadConfig (LTDC_IMReload); LTDC_Cmd (ENABLE); } Если SDRAM настроил хотя-бы на максимум - 85 Мгц, вроде, то должно работать. В любом случае по трафику програмного доступа к SDRAM у тебя остается от 5-10 мегабайт, так как 36 у тебя отнял дисплей. Память не забывай, работает 8-ми байтными пакетами, надеюсь 16-ти битная шина ?! Были полосы у меня при экспериментах пропускной способности и арбитража, когда я еще хотел на внешнюю SDRAM - с камеры грузить, она тоже 40 Мгц, тогда все сразу потухло, с полосами все было. Хотел посмотреть что будет. Если у тебя какой-нибудь периферийный модуль с DMA настроен на настроен на внешнюю SDRAM, то тогда это причины.

У меня ST-LINK/2 , отладчик отваливается при любом удобном случае, задетектировать место зависания не удается, импульс и полный сбой, что с отладчиком что без него. Даже когда отладку делаешь через ноутбук работающих от своих батарей в режиме полной гальваноразвязки, збои - реже. Разрабатываемое устройство работает с реактивными цепями накапливающими токи в свою индуктивность до одного-полутора килоампера. Поэтому E = (L * (I*I)) / 2; - (L = 5 - 20 uh) большие импульсные помехи. Слив всю энергию в емкость 10 нанофарад можем получить 67 Кволльта на нем, все зависит от добротности реактивности пораждающюю обратною ЭДС. Длина волны (скорость нарастания/спада) пораждаемая этим разрядом уже три раза превысила импульс пораждаемые гармоники рентгеновского спекта. Поэтому длина полны может быть и сантиметр и миллиметр, все зависит от магнитной проницаемости среды и формы конструкции. Главная ошибка это отсутствие гальваноразвязки, искушение использовать встроенные в ARM ADC периферию ! Схему разрабатывал не я. Неоднократно предупреждал и расчитывал возможные помехи.

Эх, хороший совет. Но схему и плату не я рисовал. Схему запретили трогать и давать какие-либо рекомендации по поводу надежности и улучшения ее работы - под страхом физической расправы с последующим увольнением с работы. Ну нет худа без добра, за это время стал специалистом по программным костылям. Специалистом изменения магнитопроницаемости физического ваккума програмным способом на расстоянии по фотографии. Хороший совет. Ведь внутренняя система PLL по любому сделана по схеме НАПРЯЖЕНИЕ-ЧАСТОТА с цифровым счетчиком и цифровым компаратором обратной связи. Любая помеха наводит на накопительную RC цепь приличную наводку или ее изменение. Спасибо. Правильно приняли - что береженного Бог бережет.

Думаю просто. Припаиваешь к цифровой земле 1 метр провода , один выход генератора цепляешь на самый отдаленный край провода земляного. Другим концом с генератора замыкаешь на тот же провод рядом, подальше от MPU естественно. Помучайте это земляной провод импульсами от генератора. Думаю эффект не заставит долго себя ждать. Если не получится, поискрите второй конец ближе к MPU. Если не получится, поставьте вместо керамики и танталов на плате MPU только электролитик индукционный какой на 3 вольтового питания . И проделайте тоже самое с землей и генератором снова. Вот меня уже направляли на путь правильный... Но понял я что по NMI я промазал.... Люблю котов !!! Не поставил обработчик по NMI :( ... The data bus width is 36 bits because 4 bits are available for parity check (1 bit per byte) in order to increase memory robustness, as required for instance by Class B or SIL norms. The parity bits are computed and stored when writing into the SRAM. Then, they are automatically checked when reading. If one bit fails, an NMI is generated. If a failure is detected on the HSE clock, the HSE oscillator is automatically disabled, a clock failure event is sent to the break input of the advanced-control timers (TIM1) and general-purpose timers (TIM15, TIM16 and TIM17) and an interrupt is generated to inform the software about the failure (Clock Security System Interrupt CSSI), allowing the MCU to perform rescue operations. The CSSI is linked to the Cortex-M0 NMI (Non-Maskable Interrupt) exception vector.

Схема плохая, с точки зрения подвода, много внешних проводов и неправильная заводка земли. Но микроконтроллер, только временами сбоит, было принято решение довести программную часть до оптимального со стороны безопастности - помехи усилили, поставили рядом провода с индукционными импульсными наводками - 12 вольтовые импульсные сигналы сблизили с межплатным обменом по SPI где уровни 3 вольта. С этого и приступили к испытаниям программы. Ну этим пока и закончили :( ... Глохнет заведенный ватчдог, Хардфаултов - нет, управление ядра - неизвестно где ходит ??? Шо делать ?

Согласен, что схемотехника не годится. Аналоговые цепи были в схеме ? Использовалась общая земля или только гальваноразвязанные линии ??? Софтовой части нет шансов вылезти из ступора - ядро не передает управления и все ватчдоги - отвалились, в софт безопастности меня STM за эти 6 лет подковал. А когда программа укатила в неизвестно куда , посторю - заинициализированный ватчдог в УЛЕТЕ ? Что посоветуете как управление вернуть, если оно ни на один вектор не приходит ? Пины не выгорают в нашем случае есть ограничители. Волновые распространение сигнала в соответствующей среде и по одному проводу, не буду дискутировать. Со всеми проблемами AVR знаком и STM уже лет 6 мучаю успешно. Вопрос открыт, что можно сделать такое, чтобы вернуть управление ядра не через внешний сброс; при полном штопоре и реально отвалившемся ватчдоге ??????

Печалит одно только существование документа... На ровной дороге такие документы не составляются, видимо как способ увести внимание что грабли из чужого огорода у ST немного получилось. Все еще надеюсь найти совет по штопору. В AVR при компиляции программ я в конце BIN файла обычно JMP 0 ставил, а тут некуда. Возможно ядро и работает, но ГДЕ-ТО там, а WATCHDOG завял. Может в оперативку в конец сгенерировать код на NVIC_Reset ???

С питание аналогично, LM1117-3.3. Помеха ЖЕСТКАЯ ! Резкое изменение потенциала земли в какую-либо сторону в момент резких выбросов ЭНЕРГИИ дальше по схеме. Ответ по поведению внутреностей ядра- имеет право, такое наблюдал, когда напряжение питания на цифровых схемах снижается до уровня работы в неопределенном гистерезисе цифр. уровней. Но тут с питанием все нормульно. Происходит сбой не изменяя вроде внутренего гистерезиса, хотя я уже склоняюсь до подобных представлений. Что посоветуете из проверенных временем "не настраиваемых программно" схем внешнего периодического сброса ?! Приятно услышать слово от закаленного трудоднями человека. :)

За бусы фаулты тоже знаем и за другие. Везде поставил NVIC_Reset. Срабатывает иногда в 90 процентах случаев - пока штопор не отлавливает. А в STM32F03 - там только HARDFAULT. Ну он только RESETом и выводится. Знаете более или менее надежные системы периодического сброса, проверенные опытом и временем, чтоб без програмной настройки были. Чтоб очень "деревянные" были, электричества не боялись :) ?!

Не школьник. По земле иногда проходит, по чистой, по GND. Поэтому гальваноразвязка только. Но ответ на вопрос "как выйти из штопора " - дороже гальваноразвязки !!! Выяснилось не по питанию идет. Идет по корпусу железному + рядом провода с индукционными наводками (убрали). Выбросы реактивных цепей, пускатели, частотные приводы. Питание сразу поставили импульсное.

Вот. Я об том же, о надежности. А если все-таки дойдет помеха, доберется ?! Потом что капитуляция или как ? Я все грешу на свою несостоятельность, мож что не так делаю :). Вернее ищу дельного совета. Да, он , не WWDG. Проверил, он работает. Но когда на него надеешься - он сливается.

Таки да, сломался. В прерывании сброс WATCHDOGA я бы додумался поставить лет 15 назад, сейчас не встает вопрос, не школьник, не ставлю.

Absolute maximum ratings ... В каждом Product Specifications pdf на соответствующий микроконтроллер.

Да в том то и дело, надо решить проблему на корню. Помехи могут добраться и до полной гальваноразвязки (не припомню когда было :) ) и бронированного корпуса. Кто-нибудь знает как вывести STM из полного штопора. Склалось впечатление о полной остановке ядра.

В общем так, при тестировании STM32 в боевых условиях с помехами и наводками, в частности: STM32F03, STM32F207 и д.р. выявилась проблема, которая на микроконтроллерах типа AVR никогда не проявлялась или очень редко проявлялась. Небольшие наводки (естественно выше допустимых по мануалу уровней) по GPIO портам у STM32 вызывают аппаратные сбои ядра, периферии и оперативной памяти. В одних случаях сбоит периферия: слетает инициализация или происходит установка ошибок, лечится банальной но частой переинициализацией по программному таймеру или переинициализацией после отработки некоторых условий. В других случаях происходит сбой ядра и передача управления на HARDFAULT_Handler или BUSFAULT_Handler, где вместо while (true) - поставили простое лечение NVIC_SYSTEM_Reset (). Иногда сбоит оперативная память, теряет данные. Но это все поправимо, если устанавливать контрольные суммы. Что делать, когда заинициализированный и проверенный WATCHDOG после наводок не сработал, а внутреннее ядро СТАЛО, симптомы именно такие ! В HARDFAUL вхождения не было !!! Проблема не в том, чтобы в оборудовании сделать ПОЛНУЮ гальваноразвязку, как устранить полное зависание и останов ядра после сбоя, если сам WATCHDOG слетает и ядро где-то шляется по адрессам ? Видел в живую некоторые реализации схемотехники для 8051 микроконтроллера. С внешней микросхемы формирователя на 555 генерился постоянный неуправляемый сброс с определенным периодом и скважностью, остается догадываться что программа организованна по SWITCH CASE программного состояния. Но это достаточно неудобно когда организовываешь протокол обмена например по MODBUS, где циклы сброса с формирователя ассинхроны к пакетам передачи ??? Кто-нибудь знает как вывести STM32 из полного штопора ??????????????????????

"Некоторые" конторы требования уже вывесили по знанию HAL. И мечты их не затемнишь ничем :). Завтра, на работу не устроишься. Будешь доказывать "желтым" лбам кто валенок, а кто нет. Причем тенденция набирает обороты. Вот ! Мало кто выкладывает полезную информацию. А что там по таймеру, что-то с прерываниями опять ?!

Очень важная тема думаю. Давайте будем озвучивать подозрения на некорректную работу HAL, у кого были какие проблемы с периферией при использовании этого "индусского" кода ? В основном интересует тесты на убой; в частности электро-помехи на UART линии выявили полную неработоспособность реализации HAL. Это не касается "ORE"! Потому-что валовая мода на HAL, приведет к хаосу качества программного обеспечения. Кто-то останется без работы :(. - - - Проблемы с UART: Некорректная обработка прерываний, приводящая к зависанию системы, конкретно: Low Noise и Frame Error . Анализ кода показал, что "писатели" не понимают принципов сброса большинства статусных состояний в регистре состояния SR (до десятка чтений регистра SR). Лишние действия по четности бит. - - - Система прерываний, вернее вызов специфических обработчиков, затормозили опять до уровня архитектуры 7DTMI, все очень медленно. Передача указателя и так в известный контекст выполнения. По видимому начало разработки HAL по времени взято с времен архитектуры 7TDMI, где подобные задержки можно было бы понять и простить.

Минус в огород Хала/Hal . На STM32F2xx - те же грабли. Только при испытаниях HAL на электрические помехи на линии UART обнаружилось некорректная обработка условий LOW NOISE, STOP BIT. В общем долго рассказывать не надо удалили весь мусор, а его там 100 %. Что делает ХАЛ , что можно было не делать или сделать лучше: 1. Включает лишние прерывания по ошибкам (LN , FE) и "индусы" запутались с обработкой этих битов. В итоге - не выходит с прерываний вообще. 2. Включает лишний код по обработке четности, когда не заказывали вообще. 3. И что незачем читать постоянно регистр SR , так как он влияет на аппаратный механизм сброса большинства условий. 4. "Индусы" не понимают что значит сократить код. Это помогает лишь в некоторых случаях. Смысла чинить ХАЛ - НЕТ !!!

Если используешь FTDI и WIN7. Бросай FTDI в топку. Бери CP2102, дешевле и работает красиво. С винды FTDI в устройство передает, а в ответ - ерунда мусорная. Почитал, оказывается FTDI легенду кинула типа их микросхемы подделывают "ИНЫЕ" китайцы, шо плохо сказывается в работе с WIN7 на драйверном уровне.

Делал на 429 . Запускал режим LUT8, дисплей 800x600. 40 мегабайт видеопотока, заметьте !!! однобайтовый, не перепутал ! Сожрал весь трафик к SDRAM. Осталось там для 3-4 мбайта в секунду, для программы (это из учета что частота SDRAM с максимально скоростной конфигурации получилась то-ли 75 то-ли 85 Мгц в 16-ти битном режиме памяти). Как по мне - это медленно. Попутно запустил камеру на OV - чипе, настроил на внутреннюю оперативку, а так как ее мало было для полного растра пришлось весь кадр перегружать за 3-4 физических кадра + еще и каждую точку с 565 режима камеры в 8бит переделывал :) . 729 - много не выправит. С такими потребностями и хваткой надо на ALLWINER-ы переходить. Но там одна только загвоздка и она ключевая, надо изучить команды MALI архитекруты :).

Это Вы только капнули в халовские недра. Советую срочно одуматься, дальше будет поздно, библиотеки с STDPERIHERIAL не дружат вместе. Будете переписывать как минимум 90 процентов "индусского" кода по прерываниям UART, если не хотите сюрпризов по вываливанию по "непонятным" причинам.

Все работает! Скомпилировал версию WINPCAP 3.0.

Здраствуйте. Очень хочу пообщатся по теме применения исходников WINPCAP. Задача состоит состыковать ETHERNET устройство с компом, запустить так сказать обмен данными. Нарыл кучу информации, в основном стоящая инфа только по теме WINPCAP. Есть много инфы по NDIS, в основном в DDK, но там полные дрова - недружелюбный подход к изложению спецификации. Поэтому для меня один выход - WINPCAP. Но тут началось: WINPCAP поставляется в исходниках, можно скачать около пяти разных версий архивов. (В архивах присутствуют папка исходников драйвера packet.sys, папка исходника packed.dll и папка с исходниками wpcap.dll) - компилированых этих файлов в архиве нет. Компилировал исходники: драйвера packet.sys через build из DDK2000 и packet.dll через VisualC5(с импортом функции проблем нет). При прогоне тестовых примеров из документации возникли ситуации : Функция PacketGetAdapterNames нормально завершается и возвращает список адаптеров, я их получаю. Проблемы возникли с запуском следующей функции PacketOpenAdapter (которая должна перезапускать(запускать) драйвер).Точнее в исходниках драйвера packet.sys. Драйвер должен был зарегистрировать символьные метки, по которым сначала можно было бы с ним работать через CreateFile. Этой функции регистрации(IoCreateSymbolicLink) в драйвере нет. Точнее этот код закоментирован. При просмотре кода, по которым формируется символьные метки в драйвере и *.dll. Я могу сказать что алгоритмы там разные. И при просмотре и компиляции этих архивов с исходниками одинаковый результат. Драйвер прописывается и стартует(когда обращаешся к paclet.dll), но когда надо с ним работать - проблема - *.dll обращается к драйверу по символьной метке, а драйвер ее не зарегистрировал. Написать подобный алгоритм в драйвере я не берусь, плохо ореинтируюсь в API KERNEL MODE функциях. Вот и вся проблема. Есть еще один выход, попробовать поработать с packet.sys не через packet.dll, а через wpcap.dll (wpcap.dll в свою очередь тоже использует packet.dll). В принципе как раз больше примеров кода по wpcap.dll. Но тогда возможны двойные неприятности, а может быть и нет. Вообще я только еще изучаю этот пакет. Хочется сделать, что-нибудь полезное, типа обмена даными по ETHERNET на MAC уровне. WINSOKET2 ( RAW) - это нормально, но для задачи не подходит. Если кто-нибудь может поделится соображениями по поводу ETHERNET на MAC(NIC) уровне , может подскажете лучший путь. Или посоветуйте рабочие исходники, или уже скомпилирование файлы packet.dll или packet.sys. Буду очень признателен.

Спасибо "Petka" . Я уже все перепробовал : и обьектник дизассемблировал, чтоб хоть убедится что ни он портачит. Мои мысленные допуски по поводу нулевых адресов на командах JMP и CALL в обьектном модуле подтвердились, ведь это дело линковщика адресса расставлять. Но проблема не в том, что линковщик их не расставляет, а в том что он их расставляет с искажением OPCODE. Попробуйте написать маленькую програмку, а потом залинковать. Примеры скрипта в этом разделе темы, наверху. Я этот же вопрос задал на AVRFREAKS , может действительно проблема, или будут смеятся. Вчера написал утилиту автоматической шлифовки ассемблерного, листинга c avr-gcc -S на удобовоспринимаемый ассемблером из AVR STUDIO с которым я уже долго работаю. Из WINAVRа буду использовать только avr-gcc с опцией -S для выдачи ассемблерного файла и все (линковать не прийдется :w00t: ) . А ассемблировать avrasm32.exe из AVR STUDIO. Так сказать нерешенных проблем нет. Програмы шлифовки как доработаю то выложу на Моя веб-страница