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

ivainc1789

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Профессионал
    Профессионал
  • День рождения 15.03.1972

Контакты

  • Сайт
    Array
  • ICQ
    Array

Посетители профиля

5 072 просмотра профиля
  1. Появилось немного времени для экспериментов. Изготовил тестовую плату на LM25116. В целом топология как выше на фото. Рискнул. Плата заработала сразу, осциллограммы чистые и мне удалось ее нагрузить до 5А. Больше мой блок питания не дает! Порадовало то, что транзисторы и индуктивность вообще не греются на 5A! Но есть особенности: 1. Пин DEMB заземлен. Примерно после 4А LM25116 сбрасывает частоту переключения с 210kHz на 105kHz и продолжает нормально работать. Осциллограммы чистые. Такое поведение вроде бы не описано в даташите. Должно ли так быть? 2. Пин DEMB заземлен через 10k. Нагрузка лампа 26V 90mA, VCCX заземлен. При VIN до 12V все работает нормально. При увеличении VIN с 12V и далее переключение транзисторов нарушается, как бы становится хаотичным, катушки начинают свистеть, на выходе пульсации до 3V. Не разобрался с этим режимом эмуляции диода... 3. С четырьмя RCR-1616 сделать адекватную топологию как в даташите сложно. Все упирается в конструкцию/размеры катушки. Цены на Ali не радуют - стоимость "правильной" катушки что-то около 1тр за штуку. Плата на NCP1034. Тут все плохо. Подключение снаббера и "игры" с ним помогают увеличить выходной ток лишь на +1А, но далее с ростом нагрузки колебания на фронтах транзисторов в точке VS появляются снова и срабатывает защита. Кардинально ситуация улучшается только с понижением частоты до 50kHz и тогда опять же удается нагрузить до 5A даже с такой неудачной компоновкой.. Да, но в двуслойной плате типа HomeMade еще важно что расположено под трассой. Слава Богу, мне вроде бы удалось это проконтролировать. ))) Вот и на плате LM25116 я примерно так и поступил. Можно бы было еще улучшить компоновку, но тогда трассы с токоизмерительного резистора значительно увеличиваются. Побоялся так делать в двух слоях...
  2. Спасибо за конструктивную критику. Попытался все исправить, правда для LM25116, но не суть. Топология силовых цепей все равно похожа, только LM25116 имеет sense resistor, к которому привязывается вся схема управления. Но: 1. Трасса до затвора верхнего получается длинноватой. 2. Индуктивность составлена из четырех RCR-1616(SUMIDA). Расчетное значение 3uH. Хочу взять с них ток 15A. Других подходящих SMD пока нет. Правда есть кольца T130,T106,T80 из материала 52, но что-то ручномоточные изделия не хочется использовать. Недостаток вижу в том, что трасса SW опять же длинновата, индуктивность, излучение, но все четыре катушки более коротко видимо не соединить. 3. Все пока в рамках домашнего изготовления с соотв ограничениями... 4. Пока без полигонов и прочего. 5. Нужно правильно предусмотреть RC снаббер. Подскажите как расположить?
  3. да, но экселевском файле есть полевики с соразмерными емкостями... таких под рукой нет, но... скоро будут ))) После долгих мучительных раздумий появилась зацепка. При плавном увеличении нагрузки на выходе при окрытии верхнего транзистора появляется "звон" 50MHz на фронте, который удалось поймать в макс амплитуде прямо перед срабатыванием защиты. Вот осциллограмма в точке VS в данный момент: Как видно, амплитуда превышает 20V входного напряжения. Думаю, срабатывает защита от pozitive current нижнего ключа. Зная частоту звона и предположив, что в данной колебательной системе емкость - это вых емкость транзистора, можно рассчитать RC снаббер для подавления звона. Но меня смущает, что с ростом нагрузки этот звон увеличивается не плавно, а очень резко перед самым отключением. Не могу понять, почему...
  4. Индуктивность на основе двух CDRH127-12uH в параллель. Отключение происходит при 1.8A.
  5. Хорошо, в качестве индуктора все же предлагаю использовать кольцо T80-52B. 9 витков 1.6мм. Производитель: Juncan (Китай). Индуктивность 6.5uH. С таким дросселем схема с указанными номиналами стартует уверенно, нагружена на лампу 26V 90mA. К лампе добавочно одключена китайская электронная нагрузка. Отключение выхода происходит примерно при 1.2A. В аттаче текущие расчеты. NCP1034xls.rar
  6. Собрал тестовую плату для проверки работоспособности контроллера NCP1034. В сети много информации о проблемах при запуске синхронных преобразователей, поэтому решено было ознакомиться с демо платой от ONsemi (все материалы прилагаются в архиве) и стараться максимально придерживаться трассировки на ней. К сожалению, схема сразу не заработала в полном диапазоне нагрузок, а именно работает только до 200mA и далее отключается (возможно, срабатывает защита по току). Пока выходной ток менее 200mA все осциллограммы "чистые" на затворах полевиков и выводах ИС. Что опробовано: 1. Попытка уменьшать R7 для увеличения уставки срабатывания по току ни к чему не приводит - отрубается при тех же 200mA. 2. Попытки изменять конструктив и величину индуктивности L1 приводят к интересной зависимости: при увеличении L1 до 22uH и более переводит контроллер в hiccup mode ("икающий режим"). С уменьшением индуктивности L1 до 6uH срабатывание защиты наступает позже. Так, с двумя CDRH127-12uH включенными в параллель удалось довести вых ток до 4A, после чего сработала защита. Думаю, именно защита ибо дроссели еще не успели войти в состояние насыщения. 3. Замены транзисторов на другой тип в большинстве случаев приводят к невозможности старта или икающему режиму. Вообще поразительно, насколько все тут зависимо... Лучшие результаты удалось получить с IRF3205 (куплены все там же, в общеизвестном чудесном магазине). 4. Пробовал снижать частоту с 240kHz до 50kHz, стало несколько лучше все работать после соотв перерасчета цепи компенсации, но до желанных 10А на выходе дело не дошло... 5. Интересен конденсатор С9. При его установке значением 4n7 контроллер всегда запускается. Для чего он предусмотрен, не понятно. Возможно, помогает определить медленное открытие нижнего транзистора... Мысли закончились. Уже думал попробовать LM25116, но жалко потраченного времени на изготовление тестовой платы да и хотелось бы все же разобраться в чем проблема. Сначала думал о неправильной разводке платы, но по симптомам похоже на ложное срабатывание защиты по выводу OCin. Если кто-нибудь разбирался с NCP1034, прошу помочь... Если потребуются осциллограммы в конкретных режимах - нет проблем снять. NCP1034 data.rar
  7. Добрый день! В одном из топиков прочитал, что вы имеете некоторый опыт перехода с STM32F103 на AT32. Не могли бы вы поделиться им? Я решаю такую же проблему после того, как уперся в нехватку RAM и FLASH на F103. Как лучше поступить: 1. Переделать проект с F103 (Cortex-M3) на какой-либо ближайший к AT32F403AVGT7 STM32F405VGT6, а затем с F405 переходить в AT32 Studio. Или можно как-то сразу готовый проект модернизировать до Cortex-M4 и опять же интегрировать его в AT32 Studio? Я просто не могу оценить риск смены ядра MCU при таком переходе.

    Исходный проект написан к сожалению в CubeMX, поэтому падать до AT32 библиотек очень бы не хотелось по кр мере в этом проекте. Максимум что я надеюсь придется переписать - это систему тактирования. Вообщем, буду признателен за любую помощь...

    1. my504

      my504

      Я практически не использую библиотеки, поэтому переход с STM32F407 на AT32F407 произошел совершенно легко. Функции (в том числе и драйверы) пишу сам. Иногда смотрю реализацию аналогичных в библиотеках вендоров, но чисто из соображений рационального подхода - чтобы минимизировать вероятность ошибок.

      Все проекты для ARM делаю в Кейле. Ну и поскольку Кейл поддерживают и ST и Artery, а библиотеки Standart Peripherals Library (SPL) у ST и Board Support Package (BSP) у Artery функционально идентичны с учетом особенностей периферии каждого производителя, то переход не вызывает никаких трудностей. Подавляющая часть всх проектов написана на CMSIS и вообще не отличается. Правится только синтаксис битовых структур, которые в АТ описаны несколько иначе. Дефайны констант легко находятся в файлах производителя простым поиском по проекту.

    2. ivainc1789

      ivainc1789

      Попробовал использовать Artery библиотеки с их сайта, но быстро остыл - модуль для I2C попросту недописан, там есть даже ссылка на внешний отсутствующий файл с намеком на то, что реализацию типа делайте сами. Так что пришлось все же полностью использовать проект из Куба от F103. К моему удивлению все получилось и проект заработал, были мелкие проблемы, но в целом задача перехода решена. Однако же есть сложность - модуль I2C нормально работавший на STM32F103 периодически вешает шину в состояние SDA=0 SCL=1. Выходом является только отключение питания (то есть мастер не может решить это программно или мне попросту не удалось). Эта ситуация появляется редко и как бы случайно, но эксплуатировать устройство в таком виде невозможно без переписывания кода. К тому же еррата в AT32 уже другая. Отловить ошибку я так и не смог, просто встает флаг потери арбитража и все...

  8. Итак, продолжим... Тонкость в том, что 50mA показалась мне слишком большой величиной для начала работы в "нормальном" режиме регулирования. Т.е. ток кажется слишком великим для минимального времени накопления. Если его нельзя устранить принципиально, то хотелось бы этот порог несколько уменьшить. Увеличивая сопротивление R4 мы можем настроить порог ограничения для макс нагрузки, но как оказалось, это также может привести к голоданию контроллера по питанию на малых нагрузках. В этом случае срабатывает схема UVLO и контроллер уменьшает потребление (выкл). Это неизбежно приводит к новому повышению Vdd и повторному старту... и так далее. То есть на выводе Vdd на малых нагрузках мы видим пилу от 8V до например 12V, что сопровождается сериями переключений мосфета. Подозрение в том, что на малых нагрузках мы до настоящего birst режима еще не дошли и имеем просто проблемы по питанию Vdd. К сожалению, эта ситуация приводит к необходимости отказа от двойной петли регулирования, как это красочно описано в даташите. Все из-за того, что с увеличением нагрузки напряжение Vdd ОЧЕНЬ значительно изменяется и простой намоткой доп обмотки транса ее не решить. Я пришел к выводу, что ограничение 15V по выводу Vdd только мешает при использовании оптопары, а мои попытки получить приемлемое регулирование по первичной стороне (т. е. без оптопары) не увенчались успехом. Так, у источника 12V3A с увеличением нагрузки до 600mA напряжение выхода просаживалось до 9V, что кажется совсем неприемлемым для большинства проектов. Дальше больше. По даташиту старт контроллера происходит при 12.8V, а ограничение уже на 15V. Это окно слишком мало для большого диапазона выходных мощностей. Что говорить о Viper100, где ограничение уже на 13V! Короче, все сходится к тому, что Vdd нужно стабилизировать на приемлемом уровне, например 13V для Viper53, резистор R4 исключить за ненадобностью, чтобы при малых нагрузках контроллер мог питаться напрямую от обмотки. Расчет самой обмотки теперь более прост ибо нам не надо подстраиваться по какой либо уровень! Два способа это сделать: 1. Стабилизатор на транзисторе (см рис). 2. Вообще использовать доп обмотку на прямом ходе для постоянного питания випера. Теперь ограничение по выходу устанавливается VT3. Насколько это будет работать - время покажет, но стоит ли Випер всех этих ухищрений? Цена его значительно выше TOPов, а STM явно забросила эту серию и на мои мольбы о поддержке по старому ПО (Viper1.exe) ответили, что решайте их сами и ищите для этого комп с Windows XP. Есть конечно Viper53E, но там порог отсечки по перенапряжению на выводе Vdd 17V. Т.е. все почти также. Проблема не в том, что обвеса прибавилось, а в том, что он применяется для обхода внутренних "особенностей" контроллера. Щас в пути ICE2A265 с Ali - посмотрим как там дела...
  9. Пришлось несколько поэкспериментировать с Viper53DIP (схема стандартная с оптопарой). Сложности возникли с режимом "без нагрузки" или "небольшая нагрузка". Никак не удалось настроить более менее приемлемый выход при таких условиях. Если без нагрузки пульсации на выходе можно назвать допустимыми (около 100mV p-p), то в диапазоне до 50mA наблюдаем на выходе "пилу" 1.7v p-p. При дальнейшем увеличении тока нагрузки контроллер входит в нормальный режим регулирования (напряжение пина Vcomp выше 0.5V) и вплоть до максимального тока на выходе, когда Vdd упирается в 15V наступает режим ограничения. Есть еще связь описанной ситуации с резистором R4 (по схеме из даташита), который установлен последовательно с диодом доп обмотки трансформатора. Им настраивается момент ограничения мощности на основной вторичке. Так вот, если его сопротивление уменьшать, то ситуацию с пульсациями можно улучшить, но тогда ограничение наступит при меньшем токе, что естественно недопустимо. Если R4 увеличивать то получим нормальный момент ограничения на выходе, но при мелких нагрузках контроллер перейдет в этот birst режим. Короче, ясное дело, в контроллерах с токовым регулированием присутствуют явные проблемы на мелких нагрузках. Причина видимо в том, что при таких нагрузках ток ключа мал, его сложно измерить да еще blanking time необходимо ждать... Имхо, единственное решение - ставить на выходе постоянный нагрузочный резистор под ток около 30-50mA. Но мне такие решения совсем не по нраву ))). А вот с ТОРами у мну проблем меньше... Единственное при желании/необходимости контролировать ток потребления нужно модифицировать схему обратной связи, добавив токовый резистор и его контроль.
  10. Да, не работает вывод текста именно в режимах GUI_SetTextMode(GUI_TM_NORMAL) и GUI_SetTextMode(GUI_TM_REV). Скорее это не связано с "поддержкой" нового контроллера, я проверил какие команды посылает библиотека в контроллер при выводе текста в этих режимах. Оказалось, что ничего особенного - те же команды 2A,2B,2C. Пробовал увеличивать тайминги по FSMC - не помогло. Удивительно, что не работают только два режима вывода из пяти. Особенно жаль NORMAL, поле EDIT использует для своей инициализации именно этот режим... Что же делать?... Попробую еще поиграться с инициализацией самого контроллера, если не поможет, значит все дело в библиотеке, будем как-то жить с урезанным текстовым выводом...
  11. Отвечу сам себе (. Судя по мануалу, NT35510 не поддерживается. Тем не менее, я попробовал это оспорить. Система команд очень похожа, для ввода/вывода используются [в основном] команды ILI9486 0x36,2A,2B,2C,2E. NT35510 должен получить: 0x3600,0x2A00 и так далее. Причем параметры всегда однобайтовые и перед ними должна всегда выводится "инкрементированная" команда. Короче, вот функции LCDConf_FlexColor.c, которые я переписал: /******************************************************************** * * LcdWriteReg * * Function description: * Sets display register */ uint16_t cmd; // текущая команда uint8_t i; // текущий параметр команды static void LcdWriteReg(U16 Data) { // ... TBD by user Data <<= 8;cmd = Data;i=0; *(uint16_t *)ADR_CMD = Data; } /******************************************************************** * * LcdWriteData * * Function description: * Writes a value to a display register */ static void LcdWriteData(U16 Data) { // ... TBD by user if (i == 0){// первый параметр команды *(uint16_t *)ADR_DAT = Data; }else{// команда и последующий параметр команды *(uint16_t *)ADR_CMD = cmd+i;*(uint16_t *)ADR_DAT = Data; } i++; } /******************************************************************** И это работает!!! Дисплей: http://www.lcdwiki.com/3.97inch_16BIT_Module_NT35510_SKU:MRB3973 Подключение: STM32F103VET6, FSMC. Но счастье длилось недолго ибо обнаружил странный глюк при выводе текста. Взял кусок кода из UM01003 v6.18 стр 215: // пример вывода текста из UM03001_v6.18.pdf стр. 215 // вывод должен соответствовать картинке в UM03001_v6.18.pdf GUI_SetFont(&GUI_Font8x16); GUI_SetBkColor(GUI_BLUE); GUI_Clear(); GUI_SetPenSize(10); GUI_SetColor(GUI_RED); GUI_DrawLine(80, 10, 240, 90); GUI_DrawLine(80, 90, 240, 10); GUI_SetBkColor(GUI_BLACK); GUI_SetColor(GUI_WHITE); GUI_SetTextMode(GUI_TM_NORMAL); GUI_DispStringHCenterAt("GUI_TM_NORMAL", 160, 20); GUI_SetTextMode(GUI_TM_REV); GUI_DispStringHCenterAt("GUI_TM_REV", 160, 36); GUI_SetTextMode(GUI_TM_TRANS); GUI_DispStringHCenterAt("GUI_TM_TRANS", 160, 52); GUI_SetTextMode(GUI_TM_XOR); GUI_DispStringHCenterAt("GUI_TM_XOR", 160, 68); GUI_SetTextMode(GUI_TM_TRANS | GUI_TM_REV); GUI_DispStringHCenterAt("GUI_TM_TRANS | GUI_TM_REV", 160, 84); К сожалению, через функции GUI_ текст выводится иногда с ошибками и пока нельзя сказать, что это из-за криво поддержанного контроллера NT35510. Текст внутри виджетов всегда выводится корректно.
  12. Сначала у меня был дисплей на ILI9486 и мне удалось довольно быстро его настроить в STemWin, видимо потому, что он поддерживается библиотекой. Но при подключении было обнаружено, что кристаллы "потекли" (с момента покупки не проверялся и не подключался) и в конечном устройстве использовать его невозможно. Вскоре получил дисплей на NT35510, который довольно быстро удалось инициализировать и проверить на тестовых программах до подключения STemWin. Все работает без замечаний. Однако после подключения STemWin дисплей не работает, при этом инициализация его проходит нормально. Наверное, дело в том что команды NT35510 хотя в целом и похожи на ILI9486 имеют отличие - 16битный формат. Например, сброс дисплея для ILI9486: TFT_WriteCmd(01); а для NT35510: TFT_WriteCmd(0100); Возможно, дело именно в этом, но моих знаний STemWin пока не хватает, чтобы что-то поправить в библиотеке. Скорее всего, ошибка в этой функции: void LCD_X_Config(void) { GUI_DEVICE * pDevice; CONFIG_FLEXCOLOR Config = {0}; GUI_PORT_API PortAPI = {0}; // Set display driver and color conversion pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_FLEXCOLOR,GUICC_565,0,0); // Orientation //Config.Orientation = GUI_SWAP_XY | GUI_MIRROR_Y; Config.Orientation = GUI_SWAP_XY; //Config.Orientation = GUI_ROTATION_CW; //Config.RegEntryMode = 0x6E30; LCD_SetSizeEx(0, YSIZE_PHYS, XSIZE_PHYS); GUIDRV_FlexColor_Config(pDevice,&Config); // Set controller and operation mode PortAPI.pfWrite16_A0 = LcdWriteReg; PortAPI.pfWrite16_A1 = LcdWriteData; PortAPI.pfWriteM16_A1 = LcdWriteDataMultiple; PortAPI.pfReadM16_A1 = LcdReadDataMultiple; GUIDRV_FlexColor_SetFunc(pDevice,&PortAPI,GUIDRV_FLEXCOLOR_F66709,GUIDRV_FLEXCOLOR_M16C0B16); } Я ее не изменял с момента использования ILI9486. Подскажите, что не так...
  13. Именно так и сделано, по рисунку же видно... Проверил состояние битов, все верно указано, куб нагенерил именно так! А вот этот битик был в 1, т. е. NSS менеджмент разрешен. Я его скинул так #define BITCLR(REG,BIT) ((REG) &= ~(BIT)) BITCLR(SPI1->CR1,SPI_CR1_SSM); Проверил в CubeIDE - состояние сбросилось. Но все эти меры не привели состояние пина 77 к возможности переключаться. Помогает только если отменить ремап SPI1... P.S. Попробовал сконфигурировать SPI1 в режим master с пином NSS в режиме hardware выхода. Передача байтов по линиям MOSI и SCK проходит как нужно, но NSS все время в низком уровне. Поведение одинаково и с ремапом SPI1 и без оного...
  14. Нарвался совершенно случайно на очередные грабли. Вот простая конфигурация для STM32F103VET6. Как видим, ремап сделан и для SPI1 и для TIM2CH1. В данной конфигурации был важен именно таймер, т. к. я планировал звук выводить на пищалку именно через него (пин 77). Куб ничего подозрительного не выдал, я естественно тоже никакого криминала не заметил, короче, плата была успешно сделана. Приступил к программированию и тут все порушилось: пин 77 не хотел делать НИЧЕГО! Висит в Hi-Z и все. Разбор полетов показал, что SPI1 не имеет частичного ремапа и переносятся не только пины SCK,MISO,MOSI но и NSS! И насколько показывают мои эксперименты, для данной конфигурации платы пин 77 потерян - нужно выбирать что-то одно, но нужен и SPI1 и таймер (звук). Была надежда, что пином будет управлять та периферия, которая инициализирует его последней. На практике вроде такое не подтвердилось... Вот решил посоветоваться, может что не так понимаю или есть еще варианты? TIM2CH1asA15.rar
  15. Точно! В голову как-то не пришло насчет конденсаторов. Сверил проекции - действительно, они родимые! Причем именно кондеры, если кондер не установлен (то есть не запаян) то и его "залипа" по проекции нет. Большое спасибо за помощь. Принесли проц с памятью и... плата-то заработала!
×
×
  • Создать...