Polaris

Очень смешно, прям ха-ха-ха. При этом другой софт чудесно справляется как без RESET, так и без SWO. Вы вообще какой-то опыт с EmBitz имеете и его скриптами, или просто чувство юмора хорошее?

В 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 тоже ничего вразумительного не нашел. Что удивительно, но в логе он пишет, что все прошил, хотя и не проверил. Если прошивка внутри уже есть - отлаживает на ура. Может быть, кто-то сталкивался с подобными странностями, было бы интересно послушать идеи.

Нет, не поможет, EmBitz не поддерживает кластеры в svd, так что результат будет тот же самый. Хорошая оболочка, но, к сожалению, автор ее не развивает... Да, мультиплексирование я включил, проблема не в этом.

Я в EmBitz работаю, а он не понимает атмеловских svd с их кластерированием :(

да я тоже уже неделю курю, правда, с отладчиком не так просто, у меня нет svd под этот контроллер, так что руками только по адресам. Но в целом ситуация такова, что никто пока не смог победить захват от входов: https://www.avrfreaks.net/forum/samc21-cannot-use-tc-capture-inputs-ppw-or-pw-modes Я точно такого же результата добился, от входа запускается только захват текущего значения, все более продвинутые режимы не работают. А с захватом от Event system вроде бы вышло вот с этим руководством: https://microchipsupport.force.com/articles/en_US/FAQ/SAM-D-L-C---TC-Capture-Example-using-Atmel-START?retURL=%2Fapex%2FNewCase&popup=true То есть, только с лайтовой версией драйвера TC и только с прерываниями. Мне кажется, что даже в AVR все было на порядок продвинутее, в сравнении с армами других производителей это, конечно, полное фиаско. Как-то я себе иначе представлял банальный захват PWM. Столько телодвижений (таймер, внешнее прерывание, EVSYS, все это связать) для того, чтобы потом в прерывании получить желаемое значение.

Да, видел уже эту доку, свалили в кучу все процессоры, что есть, а на деле тот же D20 имеет совсем другую структуру регистров в плане TC. И в родной доке от C21/C21 WO стоят на схеме модуля как входы-выходы, а тут только как входы. Кому верить вообще - непонятно.

Доброго всем дня! В данный момент пытаюсь запустить захват по фронту на контроллере ATSAMC21N18A. Во-первых, натолкнулся на странное. Документация по ASF4 гласит, что: Но нигде больше никакого упоминания драйвера 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, работает реально быстрее с графикой.

Речь не о контроллерах, они в целом очень даже неплохие, речь об экосистеме - нет ни нормальных отладчиков, ни нормальных средств разработки, и эта проблема никуда не девается уже второе десятилетие. А на ассемблере можно писать разве что мелочь какую-то, когда проекты вырастают до размеров десятков тысяч строк - не думаю, что у Вас с ассемблером получится совладать.

Ну все, Атмелу теперь точно крышка :)

Вопрос закрыт. Достигнутый уровень потребления в Stop Mode - 15 мкА, что соответствует заявленным в даташите 14 мкА. С отключенным на время сна АЦП потребление снизилось до 70 мкА. SysTick на потребление никак не влияет, разве что упрощает отладку, с ним и подключенным отладчиком войти в режим сна не выходит. Еще 55 мкА потреблял вроде бы неиспользуемый LDO, видимо, через резистивный делитель, используемый в обратной связи: Всем спасибо!

С AVRISP mkII проблем такого рода нет, но это же не отладчик, видимо, Atmel пустил его уже на самотек.

Не по теме, но все-таки не сдержусь. Приобрел Dragon с целью отладки на XMega, цензурных слов нет просто никаких, ничего с ним достичь не получилось вообще, седьмая студия его видит, но не подсоединяет, шестая подсоединяет, но не может сбросить контроллер. После нескольких вечеров копания на форумах решил избавиться от него и больше с Atmel дела не иметь. И да, по поводу студии добавлю и родного Atmel-ICE. Стоит новейшая седьмая студия, отладчик родной и стоит не копейки, при подключении его к компьютеру он виден в списке устройств, студия же его не видит в упор. Проверил у коллеги - та же картина. Проверили на другом компьютере - видит. В чем отличие? Наличие Интернета! Все остальное идентично (Win10, версия студии). Видимо, этим гопникам-погромистам недостаточно денег, в охоте за китайскими копиями они даже готовы запретить полностью работу с их родным отладчиком без наличия возможности проверить серийники через Интернет. А у нас на работе сложная политика, рабочие машины в Интернет принципиально не пускаются, так что ой. Короче, Atmel - это живой труп, лучше его уже закопать.

Прерывания были отключены, регистры не используются в тексте существенным образом. Проблема была все-таки в логике программы, так что с процессором все в порядке.

Добрый день, пришлось заняться написанием загрузчика для 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 мА. Пока что буду думать, как все это хозяйство действительно выключить на время сна.

Убрал его совсем. Показания вообще не поменялись.

Почему? Схема может быть запитана как от USB через разъем CN3 и преобразователь U1, так и напрямую от 3.3В через разъем CN4.

Да, перемычки нет, так что померять ток будет сложно, проще выпаять его совсем :) Так нагрузки никакой нет, преобразователь только для питания от USB, а я его напрямую запитываю 3.3В от лабораторного источника питания. Так что в данный момент он никакой функции не несет, вопрос только в том, не гадит ли он при этом... Да, кнопка не нажата, светодиод на 3.3В отпаян, по идее ничего ток не ест, проблема может быть только внутри самого контроллера или с этим преобразователем.

Светодиод отключен, конечно, он же не 1мА ест, а 2,5. 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мкА, и вроде бы у людей это получалось, причем без настолько существенных мероприятий. Заранее спасибо!

После выключения консоли перестает отображать лого из ядра, так что секунд 5-6 при старте вообще ничего не показывается. Это еще хуже, чем кратковременное мигание.

С убутом это никак не связано, там стоит пауза 1 секунда, и я ее не беру во внимание. Иксы полноценные, это так. По поводу задачки, рисующей в FB - я так и делаю, но иксы на время инициализации перебивают эту задачу. По поводу инициализации консоли - я не знаю, как это можно изменить. И да, вся система стартует достаточно быстро, в районе 20 секунд, потому как подсоединяется журналируемый винт и запускаются сервера HTTP/MariaDB, без них и без иксов тоже уложились бы в 7-8 секунд.