Polaris
-
Постов
299 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Polaris
-
-
41 minutes ago, jcxz said:
Думаю, что достаточно будет не забыть завести сигнал RESET в J-Link и выбрать подходящий тип сброса. ... и можно оставаться атеистом
Ну а если RESET не завели, то тут остаётся пенять только на себя.
В J-Link OB отсутствует RESET
-
Доброго всем времени суток!
Возникла необходимость запустить проект на EFM32G222F128, довольно интересный контроллер с хорошей аналоговой частью, но столкнулся с очень странной проблемой. Я пользуюсь EmBitz по причине очень простого и эффективного интерфейса (жаль, что автор не развивает проект, конечно), начинал с разных STM32, были и M3, и M4, и M7, разбирался с nrf51822 от Нордика, недавно реализовывал проект на ATSAMC21, то есть, в принципе, работал с широким спектром контроллеров в связке с китайским J-Link OB, и всегда все получалось. Из претензий ну разве что баги EmBitz при работе с SVD-файлами от Atmel.
Но вот создал проект с EFM32, подключил их библиотеки для периферии, и понеслось - какие-то странные адреса при отладке, только методом проб и ошибок выяснил, что J-Link ничего не шьет в контроллер. Но отлаживает, если запустить J-Link Flash и прошить там. Проект, собранный в Keil, работает, шьется и отлаживается, то есть, дело в настройках J-Link. Почитал мануалы, думал, что это может быть связано с различными режимами входа в программирование, но нет, ни один не сработал. Скорость даже ниже, чем в Keil. Особых настроек в EmBitz нет, в мануале к J-Link тоже ничего вразумительного не нашел. Что удивительно, но в логе он пишет, что все прошил, хотя и не проверил. Если прошивка внутри уже есть - отлаживает на ура.
Может быть, кто-то сталкивался с подобными странностями, было бы интересно послушать идеи.
-
On 11/9/2018 at 11:07 PM, Obam said:
Ну, тогда остаётся последовать совету из https://www.embitz.org/forum/thread-829.html : "just register w. ARM and you can have as many svd as you like"; впрочем, первоисточником всё равно будет atmel.
Нет, не поможет, EmBitz не поддерживает кластеры в svd, так что результат будет тот же самый. Хорошая оболочка, но, к сожалению, автор ее не развивает...
2 hours ago, Obam said:Это указано направление сигнала в TC.
Нет нужно. WO это периферийная функция E или F, в настройках для нужных выводов в IO-контроллере должно быть настроено, что это не GPIO, а соответствующая периферия, вход (из ваших постов этого не видно).
Ну, вообще-то: NOTE на стр. 713 DS60001479B.pdf
PS: живьём проца у меня, увы, нет; а жаль - занятная балалайка.
Да, мультиплексирование я включил, проблема не в этом.
-
On 11/6/2018 at 8:43 PM, Obam said:
В гугле: atsamc21n.svd. У меня 3-м результатом "Microchip pacs repository": http://packs.download.atmel.com/ и там море разливанное... ;)
В http://packs.download.atmel.com/Atmel.SAMC21_DFP.1.1.144.atpack будет и svd.
Я в EmBitz работаю, а он не понимает атмеловских svd с их кластерированием :(
-
45 minutes ago, Obam said:
Я в таких случаях медленно и вдумчиво "курю" свежий даташит и под отладчиком (в ИАРе), бывало даже вручную, режимы\флаги проверяю-устанавливаю-сбрасываю: ядро стоит, а периферия работает ;)
Помогло раз сравнение хидер-файла на периферию с её описанием в даташите (у ацп в SAM4S забыли канал термодатчика).
да я тоже уже неделю курю, правда, с отладчиком не так просто, у меня нет svd под этот контроллер, так что руками только по адресам. Но в целом ситуация такова, что никто пока не смог победить захват от входов:
https://www.avrfreaks.net/forum/samc21-cannot-use-tc-capture-inputs-ppw-or-pw-modes
Я точно такого же результата добился, от входа запускается только захват текущего значения, все более продвинутые режимы не работают.
А с захватом от Event system вроде бы вышло вот с этим руководством:
То есть, только с лайтовой версией драйвера TC и только с прерываниями. Мне кажется, что даже в AVR все было на порядок продвинутее, в сравнении с армами других производителей это, конечно, полное фиаско. Как-то я себе иначе представлял банальный захват PWM.
Столько телодвижений (таймер, внешнее прерывание, EVSYS, все это связать) для того, чтобы потом в прерывании получить желаемое значение.
-
Да, видел уже эту доку, свалили в кучу все процессоры, что есть, а на деле тот же D20 имеет совсем другую структуру регистров в плане TC.
И в родной доке от C21/C21 WO стоят на схеме модуля как входы-выходы, а тут только как входы. Кому верить вообще - непонятно.
-
Доброго всем дня!
В данный момент пытаюсь запустить захват по фронту на контроллере ATSAMC21N18A. Во-первых, натолкнулся на странное. Документация по ASF4 гласит, что:
QuoteFor example, instead of one timer-counter driver, the ASF4 has drivers for PWM, timer, and input-capture.
Но нигде больше никакого упоминания драйвера input-capture нет, ни в ASF4, ни на онлайн-версии Atmel START, драйвер PWM есть, а этого нет. Баг в документации? А как тогда с ним работать?
Второе. Попробовал настроить сам, минуя функции ASF4, потому что, судя по коду, там в драйвере Timer можно выставить только четкие периоды, которые ставятся через регистр CC, который мне нужен как раз для захвата.
Обнаружил в документации, что можно использовать либо систему событий, либо входы-выходы таймера TC WO[0]/WO[1]. Вроде как достаточно выставить в регистре CTRLA функцию захвата:
TC0->COUNT16.CTRLA.bit.CPTEN0 = 1;и настроить WO[0] как вход:
TC3->COUNT16.CTRLC.bit.COPEN0 = 1;Все, больше ничего не нужно. Вопрос только в том, каким образом он должен понять, какой режим работы выбран? Это документация скромно обходит стороной. Я пробовал все возможные настройки, обнуляс счетчик в прерывании по MC0, но ничего не помогает, максимум, что я смог достичь - это расчет длины периода, то есть, расстояние между двумя восходящими фронтами PWM-сигнала, который я подаю на вход WO[0]. При этом та же документация на процессор вообще лишь раз упоминает, что WO[0] может работать как вход, сильно подозреваю, что ей вообще нельзя доверять, потому что настройка режима работы захвата (PPW/PWP/PW) предусмотрено только в режиме работы от ивентов, а не от входов.
Ок, потратил кучу времени, бросил эту затею и решил перейти на ивенты. настроил в Start событие от внешнего прерывания, оба фронта, потребителем поставил таймер TC0, выставил режим PW - не работает вообще. Выставил PWP или PPW - работает, но криво, CC1 вообще никогда не обновляется, СС0 содержит расстояние между двумя фронтами. Ага, когда повезет - верное (между положительным и отрицательным), когда нет - то, что между отрицательным и положительным. То есть, если период PWM 1000 единиц, а длительность импульса - 300, получаем то 300, то 700.
Вот мой код:
hri_mclk_set_APBCMASK_TC0_bit(MCLK); hri_gclk_write_PCHCTRL_reg(GCLK, TC0_GCLK_ID, CONF_GCLK_TC0_SRC | (1 << GCLK_PCHCTRL_CHEN_Pos)); //timer_init(&TIMER_0, TC0, _tc_get_timer()); TC0->COUNT16.CTRLA.bit.ENABLE = 0; while (TC0->COUNT16.SYNCBUSY.bit.STATUS); TC0->COUNT16.CTRLA.bit.PRESCALER = 3; TC0->COUNT16.CTRLA.bit.PRESCSYNC = TC_CTRLA_PRESCSYNC_GCLK_Val; TC0->COUNT16.CTRLA.bit.MODE = TC_CTRLA_MODE_COUNT16; while (TC0->COUNT16.SYNCBUSY.bit.STATUS); TC0->COUNT16.CTRLA.bit.CAPTEN0 = 1; TC0->COUNT16.CTRLA.bit.CAPTEN1 = 0; while (TC0->COUNT16.SYNCBUSY.bit.STATUS); while (TC0->COUNT16.SYNCBUSY.bit.STATUS); TC0->COUNT16.EVCTRL.bit.TCEI = 1; TC0->COUNT16.EVCTRL.bit.EVACT = TC_EVCTRL_EVACT_PPW_Val; while (TC0->COUNT16.SYNCBUSY.bit.STATUS); TC0->COUNT16.CTRLA.bit.ENABLE = 1; while (TC0->COUNT16.SYNCBUSY.bit.STATUS);Инициализацию таймера через ASF4 отключил по причине ее неприспособленности к работе в режиме захвата. Внешнее прерывание точно работает, проверял вызовом обработчика. Генерация событий тоже точно работает, в противном случае ничего бы таймер вообще не ловил. Проблема, как мне кажется, в работе самого таймера.
Это вообще как? Кто-то вообще смог настроить этот бред? Такое впечатление, что у некрочипа документацию вообще негры пишут уже за еду, методом копипасты.
-
Посмотрите в сторону RT1052, работает реально быстрее с графикой.
-
На хмегах сейчас работает около 17 тыс изделий!
Многие годами в режиме 7/24!
Нареканий нет!
А все эти студии и прочие хрюндии никогда не использовал!
Пишите на ассемблере, и не ишите чужих ошибок в СИ компиляторах!
Речь не о контроллерах, они в целом очень даже неплохие, речь об экосистеме - нет ни нормальных отладчиков, ни нормальных средств разработки, и эта проблема никуда не девается уже второе десятилетие. А на ассемблере можно писать разве что мелочь какую-то, когда проекты вырастают до размеров десятков тысяч строк - не думаю, что у Вас с ассемблером получится совладать.
-
Кстати, microchip уже начал дудеть AFS в платную сторону.
Ну все, Атмелу теперь точно крышка :)
-
Вопрос закрыт. Достигнутый уровень потребления в Stop Mode - 15 мкА, что соответствует заявленным в даташите 14 мкА.
С отключенным на время сна АЦП потребление снизилось до 70 мкА. SysTick на потребление никак не влияет, разве что упрощает отладку, с ним и подключенным отладчиком войти в режим сна не выходит.
Еще 55 мкА потреблял вроде бы неиспользуемый LDO, видимо, через резистивный делитель, используемый в обратной связи:
Всем спасибо!
-
Новейшая это какая? У меня 7.0.1645, честно говоря, эта версия более менее упорядочила работу с драйверами.
Десятка x64. Драйвера впервые стали в предусмотренную ветку "Aтмеl" в списке устройств - в отличии от всех предыдущих. Даже танцы с zadig-ом не понадобились. Самопальный клон AVRISP mkII работает вполне нормально. Ради интереса отключал сетевое соединение - разницы в работе программатора не заметил.
С AVRISP mkII проблем такого рода нет, но это же не отладчик, видимо, Atmel пустил его уже на самотек.
-
Добрый день. Так и не смог разобраться в приведённом выше вопросе. :wacko: Потому обращаюсь за помощью рассеять мою "тупость". По случаю приобрёл AVR DRAGON, и пришлось снова вернуться к освоению Atmel Studio. :1111493779:
Не по теме, но все-таки не сдержусь. Приобрел Dragon с целью отладки на XMega, цензурных слов нет просто никаких, ничего с ним достичь не получилось вообще, седьмая студия его видит, но не подсоединяет, шестая подсоединяет, но не может сбросить контроллер. После нескольких вечеров копания на форумах решил избавиться от него и больше с Atmel дела не иметь.
И да, по поводу студии добавлю и родного Atmel-ICE. Стоит новейшая седьмая студия, отладчик родной и стоит не копейки, при подключении его к компьютеру он виден в списке устройств, студия же его не видит в упор. Проверил у коллеги - та же картина. Проверили на другом компьютере - видит. В чем отличие? Наличие Интернета! Все остальное идентично (Win10, версия студии). Видимо, этим гопникам-погромистам недостаточно денег, в охоте за китайскими копиями они даже готовы запретить полностью работу с их родным отладчиком без наличия возможности проверить серийники через Интернет. А у нас на работе сложная политика, рабочие машины в Интернет принципиально не пускаются, так что ой.
Короче, Atmel - это живой труп, лучше его уже закопать.
-
Прерывания запретить в asm вставке, регистры сохранить в стеке?
Прерывания были отключены, регистры не используются в тексте существенным образом.
Проблема была все-таки в логике программы, так что с процессором все в порядке.
-
Добрый день,
пришлось заняться написанием загрузчика для Tiny45, с которым не работал уже тысячу лет, и возникла проблема с записью флэш при помощи SPM.
Во внутренний буфер все пишется замечательно, а вот со стиранием/записью страницы есть вопросы.
Код стирания, например выглядит вот так:
LED_PIN_Set; #asm movw R30, R10 ldi R22, 0x03 out 0x37, R22 spm #endasm LED_PIN_Clear; while (SPMCSR & (1 << SPMEN));
Адрес страницы лежит в R10, это железно, так как страница пишется/стирается. Но вот выхода из SPM не происходит, так как светодиод загорается (LED_PIN_Set), но уже не гаснет, то есть до команды LED_PIN_Clear выполнение не доходит.
Фьюз SELFPRGEN включен.
Есть ли у кого-нибудь идеи, почему это может происходить? Потому как наполнение буфера для страницы работает, хотя там тоже используется SPM, хотя и не происходит изменений во флэш. Сама страница тоже пишется, но один раз - из пишущего страницу SPM выхода не происходит.
Заранее спасибо!
-
Почему же невозможно?
Делал такое как на AVR - шил из одной меги другую, причем прошивка была частью прошивки ведущего устройства (мега128 и мега32, так что памяти хватало).
Делал подобное и примерно так, как Вы описали в варианте 1 - LPC4088 читал с карточки прошивки и шил через CAN ведомые STM32Fxxx.
Что конкретно Вас интересует?
-
Удалось определить виновника утечки. Плата тут не при чем, ток потребляет АЦП, хотя я его вроде бы отключаю вот так:
ADC_Cmd(ADC1, DISABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, DISABLE);
Без АЦП потребление порядка 20 мкА, с включенным АЦП - 800 мкА, с дополнительно включенной внутренней опорой (я хочу использовать ее для измерения напряжения питания) потребляет 1,2 мА.
Пока что буду думать, как все это хозяйство действительно выключить на время сна.
-
Дак проблема-то ни о чем, откинуть 4 и 5 ногу ЛДОшки и проверить...
Убрал его совсем. Показания вообще не поменялись.
-
я так понял что приведённая принципиальная схема не соответствует действительности, причём совсем .
Почему? Схема может быть запитана как от USB через разъем CN3 и преобразователь U1, так и напрямую от 3.3В через разъем CN4.
-
Ясно дело, да и ток замерить после LDO перед МК, как по правилам. В дискавери для этого спец. перемычка была, ну а китайцы наверно ее нафиг убрали :biggrin:
Да, перемычки нет, так что померять ток будет сложно, проще выпаять его совсем :)
..100 мка он без нагрузки потребляет, а сколько под нагрузкой неизвестно, потом я ориентировался на ваше пожелание получить всего 100 мка .Потом у вас в схеме кнопка на землю , нажата она или нет? Подключена ли куда ваша схема когда вы ток замеряете, к программатору или к юсб?
Так нагрузки никакой нет, преобразователь только для питания от USB, а я его напрямую запитываю 3.3В от лабораторного источника питания. Так что в данный момент он никакой функции не несет, вопрос только в том, не гадит ли он при этом...
Да, кнопка не нажата, светодиод на 3.3В отпаян, по идее ничего ток не ест, проблема может быть только внутри самого контроллера или с этим преобразователем.
-
Красный светодиод отключить.
Схему нормальную приложить, а то слишком мелкая.
Светодиод отключен, конечно, он же не 1мА ест, а 2,5.
в пдф-е на ваш LDO сказано, что он во включённом режиме , без нагрузки потребляет 100 мка.100 мкА и 1мА - это все-таки разного порядка величины, нет?
-
Доброго всем дня!
В данный момент времени пытаюсь добиться минимального потребления у микроконтроллера STM32F103C8T6 с дешевой китайской платы, вот этой:
Перевожу в STOP mode по руководству из SPL, оживляю по RTC, вроде бы все работает. В режиме обычного потребления имею где-то 8 мА, строго по руководству (я снизил частоту до 8 МГц, больше мне не надо). А вот в режиме остановки получаю больше 1мА, хотя по документам должно быть в районе 20 мкА, что как бы совсем не очень. Прочитал кучу документов, выполнил следующие действия:
1) отключаю перед уходом в сон АЦП
2) отключаю тактирование всех пинов и перевожу их в Analog Input, чтобы не тратить энергию на триггеры Шмитта
3) обнаружил на форумах указание на то, что может течь ток в случае неподключенного пина Vbat, подсоединил его к 3.3V
Уже прозвонил все резисторы на плате, нигде нет напряжения, существенного тока течь не может.
Схема платы вот такая:
Вроде бы ничего предосудительного нет, встречал намеки на потребеление через ненагруженный LDO-регулятор, но вроде бы товарищи писали, что существенный ток там не течет. Он обозначен на схеме как rt8183-b, но опять же форумы утверждают, что на деле это RT9193 от Richtek.
В какую сторону еще можно посмотреть, что подправить, хотелось бы потребление максимум 100мкА, и вроде бы у людей это получалось, причем без настолько существенных мероприятий.
Заранее спасибо!
-
Можно включить оверлейный FB, сделать его непрозрачным через IPU, в драйвере есть соотв. IOCTL, нарисовать там что нужно, а после загрузки приложения выключить.
Или в драйверах это сделать, или скриптами при инициализации.
Чтобы выключить консоль нужно ядро пересобрать. Она выключается в графических драйверах.
И UART консоль вырубить можно, быстрее будет.
У меня приложение на QUAD через 11-12 сек стартует.
После выключения консоли перестает отображать лого из ядра, так что секунд 5-6 при старте вообще ничего не показывается. Это еще хуже, чем кратковременное мигание.
-
- Ядро "грузится медленно" по причине таймаута UBOOT, по умочанию вроде как 3 сек. Поставить таймаут=0, логотип увидите практически мгновенно, по включению питания.
- Не обязательно гасить логотип при инициализации консоли.
- Что за Х-ы? Если tinyX, то инициализация проходит практически мгновенно. Если полноценный Х-клиент + Х-сервер, то вопрос: а нафига такое на встраиваемой системе?
Не знаю, что вы там "наворотили", но на подобных МК iMX5; iMX6 у меня все полностью ( включая приложение использующее Х ) загружается за 5-6 сек. Причем за это же время успевает получить IP от DHCP...
Да и ничто не мешает написать простенькую задачку, которая будет стартовать самой первой и с какой либо частотой что-то будет рисовать напрямую в FB ( как вариант ). Конфликтов при этом не возникнет. В основной задаче, после полноценного старта всего, выставить флаг/мьютекс посредством механизмов IPC или SHM, сигнализирующей задачке-картинке прекратить работу.
С убутом это никак не связано, там стоит пауза 1 секунда, и я ее не беру во внимание.
Иксы полноценные, это так.
По поводу задачки, рисующей в FB - я так и делаю, но иксы на время инициализации перебивают эту задачу.
По поводу инициализации консоли - я не знаю, как это можно изменить.
И да, вся система стартует достаточно быстро, в районе 20 секунд, потому как подсоединяется журналируемый винт и запускаются сервера HTTP/MariaDB, без них и без иксов тоже уложились бы в 7-8 секунд.
Странное поведение J-Link при прошивке EFM32
в ARM
Опубликовано · Пожаловаться
Очень смешно, прям ха-ха-ха. При этом другой софт чудесно справляется как без RESET, так и без SWO. Вы вообще какой-то опыт с EmBitz имеете и его скриптами, или просто чувство юмора хорошее?