Доброго времени суток!
Начал потихоньку осваивать SAM3U4C, сделал темку, так как возникают различные вопросы, которые хотелось бы обсудить.

В этом камне, не смотря на два банка, RAM можно использовать как единый блок по адресам 0x20078000 - 0x20083FFF.

Можно ли такую же методику применить к флеш?
В комплекте с ИАРом идёт флешлоадер, который шьёт сразу два банка по адресам 0x000E0000 - 0x0011FFFF.

Сделал в .icf файле также, посмотрим, как получится на практике, если вместо 0x00080000 везде в программе использовать 0x000E0000.

Ещё хотел спросить про встроенный RTC, если кто им пользовался.

Я так понял, что модифицировать время тут не так просто - надо сначала остановить часы, записать новые значения, запустить их, и подождать около 1 секунды, пока можно будет проводить следующую модификацию.
Вот что интересно - после записи и запуска часов сбрасывается ли прескалер секунд? То есть переход на следующую секунду наступит ровно через секунду после запуска, или раньше, в зависимости от значения прескалера?

Теоретически ничего не мешает.


Это так принципиально? Я бы думал, что сбрасывается, а вообще - проверьте.

Привык пользоваться отдельными ИС для RTC, в частности DS3231 позволяет совершенно не заморачиваться с записью, там всё реализовано прозрачно.
Теперь же придётся вводить ограничения в интерфейсе при установке времени, то есть городить некий огород...

Да, придётся испытывать, плохо, если при установке, допустим, минут, будут сбрасываться секунды, ну да ладно.

Ещё интересно, сможет ли RTC сэма хоть как то приблизиться к точности в +- 2 ppm DS3231?

Огород там совсем небольшой, написать один раз и забыть.


Конечно будут - они же в одном регистре


Не знаю. Мне вообще откровенно не понравилось поведение батарейного блока 3U.

Ну я же сначала вычитаю содержимое всех регистров времени\даты, прежде чем их модифицировать
Но внесение погрешности даже в пределах одной секунды не есть хорошо, хотелось бы такого избежать.


А можно подробнее?
Вы часто сначала обмолвитесь про что-либо интересное, но потом таинственно замолкаете...

Жаль, что Атмел не встроили два диода для переключения питания с VDD на VBAT при исчезновении первого, как в тех же STM32...

ИМХО, это уже излишний перфекционизм.


Могу сказать только, что я как минимум трижды наблюдал зависание этого блока - дважды на атмеловском EK и один раз на своей железке.
EK зависал оба раза после прогулки по морозу (сразу оговорюсь, что питание RTC при этом точно не страдало, а температура платы не снижалась ниже 0).

Да, в даташите довольно много ошибок\опечаток и неточностей

Например, сказано, что чип имеет восемь General Purpose Backup Registers (GPBR), то есть восемь 32 битных регистров с батарейным питанием.
Однако адреса приводятся только для четырёх: 0x400E1290 [0], 0x400E1294 [1], 0x400E1298 [2], 0x400E129C [3]

Надеюсь, что их всё же восемь - то есть 32 байта.
Поменьше, конечно, чем в STM32 High Density Devices, но всё же более менее

Увы, атмеловцы этим грешат. Скажем, описание HSMCI иначе как куцым назвать нельзя. Приходится заниматься исследовательской работой.

Да уж. Я некоторое время не мог понять, каким боком работа батарейного блока (в частности контроллера сброса) может зависеть от напряжения VDDUTMI (это USB) ??? Только спустя некоторое время дошло, что имеет место банальная путаница.
Теперь уже не считаю такой даташит как истину в последней инстанции.

Но сейчас этим грешат многие, и ST, и даже NXP.

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

Кстати, тоже буду ковырять HSMCI в плане сопряжения с SD картой.
Надеюсь на Вашу помощь, если что
Там, к слову, в режиме с DMA, можно ли считывать сектора в память, задав один большой буфер? По доке вроде показалось что нет, и надо кроить linked list дескрипторов для каждого сектора...

Это пожалуйста


Можно, хотя я не пользовался. Для каждого сектора никакого linked list не нужно, только для группы.

Спасибо!


Вот для группы я и имел ввиду.
Показалось, что набор регистров управления MCI весьма внушительный, можно задать и кол-во секторов, и их размер, так зачем ещё и нарезать дескрипторы для DMA?

Можно было бы задать ему задание, к примеру, в виде считывания 16 секторов по 512 байт в линейный буфер размером 8к, и пусть себе занимается.
Зачем для линейного буфера задавать кучу дескрипторов и списков?

На самом деле, никто не мешает сделать один большой буфер - со стороны DMA разницы никакой не будет. А пример они просто привели более универсальный.
Скажем, в моем случае при записи linked list нужен, так как из-за особенностей построения буферизации сектора могут располагаться в памяти произвольно.

А, ну тогда это другое дело, тогда это гораздо веселее

ЗЫ: чёрт, привык уже к STM32, что под ресетом у них пины подтягиваются вниз, к земле, а на сэме наоборот - вверх, к VDD, а это у меня активный уровень
Вот бы вендоры сделали не поленились в будущих чипах конфигурирование подтягивающих резисторов к любому плечу по выбору

Их уже ругали за SAM7, где толерантные к 5V IO тоже были подтянуты к VDD, что приводило к проблемам при старте. Здесь их несколько оправдывает то обстоятельство, что пины более не толерантны.

Из мануала не совсем понятно, в режиме Sleep Mode будет ли работать DMA и RAM?

Написано, что в этом режиме снимается клок с ядра, но периферия может тактироваться.
Но оперативка, как я понимаю, относится к ядру, и, если она не тактируется, то и DMA не сможет её читать\записывать...

Не относится. Шины работать будут:

Что-же, тогда замечательно.

ЗЫ: а на практике Вы пробовали?
Вот эта табличка тоже говорит, что память перестаёт тактироваться:
Нажмите для просмотра прикрепленного файла

Нет, не пробовал. К табличкам нужно относится осторожнее, как мы знаем
В Sleep Mode отключается HCLK, память и шины тактируются от MCK.

Отлично, тогда отправлять CPU в сон, загрузив DMA по самые гланды, ничего не помешает


Это верно!
Блин, чем больше читаю мануал, тем больше кажется, что американцы не далеко ушли от русских в плане раздолбайства (в основном, правда, при написании документации).
Вот ещё один момент:
Нажмите для просмотра прикрепленного файла
и цитата из текста:

Каким образом клок процессора может быть не то что быстрее, а вообще хоть как то отличаться от мастер клока, не понятно

Скопипастили откуда-нибудь, это сплошь и рядом.

Провозился вчера весь день с блоком таймеров, реализовывая свою задумку сформировать путём соединения цепочкой один 32 битный таймер с разрешением в 1 микросекунду.

Сделал так: TC0->TC1->TC2, выход TC0 (TIOA0) завожу на вход TC1, а выход TC1 (TIOA1) завожу на вход TC2.

TC0: играет роль прескалера с входной частотой MCK\2, равной 48 МГц, по событию RA Compare (RA = 24) выход TIOA0 устанавливается в 1, по событию RC Compare (RC = 47) счётчик сбрасывается и выход TIOA0 сбрасывается в 0, получаем меандр с частотой 1 МГц.

TC1: младшая половинка 32 битного счётчика, по событию RA Compare (RA = 0xFFFF) выход TIOA1 устанавливается в 1, по событию RC Compare (RC = 0) счётчик сбрасывается и выход TIOA1 устанавливается в 0, получаем импульсы с частотой 1/65536 МГц.

Но тут оказалась первая непонятка - такая конфигурация давала инкремент старшей половины 32 битного счётчика сразу по достижении 0xFFFF младшей, что есть переход выглядел так: 0x0000FFFE->0x0001FFFF->0x00010000.
Чего я как то не ожидал, поэтому угрохал на вычисление проблемы целый день

Пришлось задать настройки для компараторов вот так:
TC1: младшая половинка 32 битного счётчика, по событию RA Compare (RA = 0) выход TIOA1 устанавливается в 1, по событию RC Compare (RC = 0x8000) счётчик сбрасывается и выход TIOA1 устанавливается в 0, получаем меандр с частотой 1/65536 МГц.

Ну а последний счётчик TC2 является старшей половинкой получившегося 32 битного регистра и просто тупо инкрементируется 0->0xFFFF безо всяких компараторов.

По мере тестов теперь возникла ещё одна проблема - таймер немного "бежит", за час на минуту-другую.
Оценка грубая, но видно это хорошо.

Отсюда возникли вопросы к "прескалеру" на базе TC0, который должен считать от 0 до 47 и снова с 0 до 47, но, вероятно, считает от 0 до 46, а на 47 происходит сброс сразу на 0, отсюда получаем "бегущий" таймер.
Пока что это предположение, надо будет проверить его на практике.

В мануале, жать, не приводятся точные цифры по различным режимам счётчиков...

На самом деле, достаточно было бы просто отинвертировать входной клок для TC2 (бит CLKI).


А здесь все же был бы уместен программный счетчик. Но хозяин - барин.


Нет, он обязан считать до 47.


Не понял, какие цифры?

Все же не понимаю вашу систему. Зачем такое сумасшедшее разрешение? А еще ведь при чтении счетчика придется проверять граничные условия с запретом прерываний и корректировать при необходимости старшее слово.

Цифры значений счетчика, потактово,чтобы было понятно на 100%, когда происходит инкремент/сброс и т.п, иначе лично у меня возникли неясности...

Что касается разрешения - мне так удобно на стадии отладки и разных тестов.
Считывать половинки действительно приходится несколько раз (старшую половину), но запрещать прерывания не нужно.

Так из картинок и текста все в общем-то понятно, они его давно уже копипастят


Если прерывания гарантированно укладываются в 65мс, то не нужно.

Кстати, ещё одна фишка по поводу странной работы счётчика в режиме upcounter со сбросом по Compare C.

При вот таких параметрах TC0: RA = 0, RC = 47, совпадение по RC устанавливает TIOA0, совпадение по RA его сбрасывает - инкремента TC1 не происходит вообще.
Если в RA записать 1 - всё работает.
Странно...

Всё законно :

В вашем случае это условие нарушается - импульс слишком короткий.

Понятно, спасибо
Что-то не подумал, что это "внешний" сигнал...

Теперь осталось только выяснить, почему счётчик "бежит" вперёд на две минуты в час.
Хз, может быть, косячу при замере, а может дебаггер как то влияет (через него смотрю состояние переменных/регистров)...

А вот и нет!
На практике оказалось не так!

Уже был уверен, после Ваших слов, что глюк с "убеганием" таймера вносит мой софт, но всё же когда пришёл с работы решил прогнать простенький цикл и сохранить значения счётчика TC0 на протяжении его цикла так:

то есть считав все его значения на протяжении относительно большого времени.
Напомню, конфигурация счётчика была такая:

то есть upcounter со сбросом по RC compare, RC = 48(!).
И что же получил:

то есть прекрасно видно, что значением 48 - 0x30 - и не пахнет!
Сброс идёт мгновенно и после 0х2f сразу получается 0!
Теперь понятно, почему была такая погрешность.

К слову, весьма необычная особенность аппаратуры, первый раз сталкиваюсь с таким поведением

А Вы говорите, что всё понятно в мануале. Вот если бы была диаграмма с растактовкой переполнения\сброса\установки (что встречается довольно часто), тогда действительно многих вопросов бы не возникало, и не приходилось бы прибегать к практическим исследованиям, с чём Вы сами соглашаетесь


Хм, да хоть прерывания будут длиться 650 миллисекунд - что изменится?
Код считывания таймера такой:

Переполнение 32 битного счётчика возможно за период равный 71 минуте.
Всё, что меньше этого периода, внести ошибку не в состоянии, по моему...

Странно действительно, так как прямо противоречит описанию 36.5.6 Trigger Посмотрю на досуге.


Да, все правильно. С прерываниями я погорячился.

Наверное, это бага. Но в еррате про неё ничего нет.
Впрочем, легко обходится

Надо будет сравнить с SAM7. Описания у них не отличаются.
Впрочем, не припоминаю, чтобы мне приходилось использовать UP_RC с малым значением этого самого RC, а 0.01% мог и не заметить, конечно.

Да я бы тоже не заметил, в других чипах (от AVR до C-M3 разных производителей) никогда не сверял получаемые клоки, так как не использую их для точных измерений.
Только тут, раз уж взялся ковырять модуль и с наскоку заставить заработать как хотелось не удалось, стал проверять всё досконально...

Однако в моём случае ошибка в 2% через всего лишь час дала погрешность, легко заметную на глаз

Процессор, кстати, нормально прожорливый - на 96 МГц кушает почти 60 миллиампер, из периферии включены только TC0-TC2 и PIOA-PIOB.
Если включить всю остальную периферию (без её конфигурирования) - получается красивая циферка 100 ма

Проверил на SAM7: таки да, не доходит до RC, что совсем не вяжется ни с описанием, ни с картинками
Такое ощущение, что таймер сбрасывается по сравнению асинхронно (что можно было бы предположить, глядя на картинку), однако точно известно, что SWTRG таймер без клока не сбрасывает, а на картинке эти источники объединены. Ну и в тексте явно написано, что для любого источника сброс срабатывает на следующем клоке.

UPD:
Поэкспериментировал еще с внешним клоком.
В режиме WAVESEL_UP_AUTO сброс таймера происходит моментально по достижении им значения RC, т.е. первой ассемблерной командой даю последний фронт при CV = RC - 1, следующей считываю CV уже равным 0. Зато при установке дополнительно бита CPCSTOP таймер останавливается со значением CV = RC.
SWTRIG честно срабатывает только на следующем фронте. То есть врут мануалы уже десять лет.

И с I2C, как Вы говорили, проблемы есть, и вроде седьмыми сэмами пользуется прорва народу - почему нет прогресса, интересно?

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

Я вот пользуюсь отчасти по привычке, так как начинал с них тогда, когда никаких контроллеров у NXP, ST и прочих еще в помине не было. И далеко не всегда мой выбор бывает оправдан. Хотя есть огромное количество задач, где все равно какой контроллер поставить.

Начал разбираться с SDIO (MCI) контроллером.

У него есть фичи по предотвращению переполнения внутренних FIFO при чтении\записи, написано, что при заполнении фифо просто отключается клок контроллера.

Но если при чтении это понятно - приостановится обмен с картой памяти, то при записи?
Как вообще может возникнуть переполнение фифо при записи? Если только тупо кидать в него байты процессором, не глядя на флаг готовности?

Что-то не понял этот момент

При записи может возникнуть только underrun, если в FIFO нет данных. Тут мы видим очередной copy-paste.

P.S. Я, если честно, не забивал себе голову столь подробным разбирательством: назначение битов понятно? - устанавливаем и работаем.
На самом деле, вопрос, зачем надо было вообще выносить подобную опцию в конфигурацию - если биты установлены, то возможно снижение производительности при сильно занятой шине; если нет - получим ошибку на ровном месте. И зачем оно надо?

Понятно, тогда устанавливаю их и забываю про это

Дальше вопрос по регистру таймаутов (HSMCI_DTOR) между двумя блоками данных.

Максимальное значение таймаута получается равным (1048576 * 15) тактов мастер клока, который в моём случае равен 96 МГц.
Получается 163 миллисекунды, тогда как по спецификации допускается пауза до 250 мс (при записи).

Что-то не сходится. Может быть, мастер клок имеется ввиду MCCK (уже поделённый клок), а не MCK?

ЗЫ: при инициализации SD карты ширина шины данных устанавливается как один бит.
После инициализации надо бы включить четыре бита.
Можно ли это делать "на лету", при включенном интерфейсе (но при этом никакого обмена данными нет)?

Или необходимо отключать интерфейс битом MCIDIS?

А вот фиг их знает, что тут имелось в виду. У меня установлен максимум, а на деле таймауты отрабатывает софт.


Я запрещал, а вот есть ли в этом необходимость - не помню

Понятно, спасибо!

Млин, во всех этих упрощённых спецификациях нет растактовки, бит MAXLAT: Max Latency for Command to Response, наверное, тоже стоит установить в макс. значение - 64 такта?
ЗЫ: ага, вроде нашёл - 5 тактов для ACMD41, в остальных случаях - 64

Перед началом инициализации спецификация требует выдать 74 такта на карту.
Это может обеспечить поле SPCMD регистра HSMCI_CMDR, равное 1.

То есть выдать команду CMD0 с единичкой в SPCMD, получим 74 такта, а затем CMD0?

И CMD2.


Да, только у меня поле команды содержит все "1". Опять-таки не помню, принципиально ли это, или сделано просто для отделение кода инициализации от кодов других команд.

Прикольно, надо бы посмотреть осциллографом, как именно поведёт себя контроллер в этом случае

Я вводил поддержку SD за пару дней в страшной спешке, поэтому многих моментов не помню, к сожалению.
А документацию, думаю, Вы сами успели оценить по достоинству.

За пару дней - это мощно, конечно

В доке мне больше всего не нравятся грубые ошибки типа капи-пэйст где попало и откровенное враньё во многих местах - чего стоят только 9 таймеров
В точной технической документации такого быть не должно.

Ну да ладно, с Вашей помощью дело потихоньку идёт, спасибо!

Как то странно организован регистр статуса HSMCI_SR - многие биты ошибок сбрасываются после чтения этого регистра.
А если я жду завершения операции поллингом другого бита? К примеру, жду завершения мультисекторного чтения поллингом XFRDONE, а в это время может выставиться DCRCE: Data CRC Error, который я тогда благополучно проморгаю...
Мне что, после каждого чтения регистра статуса выдёргивать и сохранять биты ошибок?


В конечном итоге всё будет работать через DMA и прерывания, конечно, но осадочек остался...

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


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

А например? Какие подозрительно себя ведут?

Посмотрел осциллографом на MCCK - он идёт на карту постоянно, то есть не гейтится вообще, активируется сразу после включения MCI.
Хм, смысл тогда выдавать команду с 74 тактами? Достаточно просто подождать немножко

Попробовать включить Power Save Mode?

Ну, например, очень интересно было бы узнать расположение событий BLKE, DTIP и DCRCE во времени. Тот же DTOE тоже интересен.
Да что тут говорить, если большинство битов регистра SR упоминаются лишь в паре строчек его описания?


Можно и подождать, но выдать команду просто удобнее.

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

Ситуация такая - имеется плата от стартеркита SK-MATSAM3U4, к ней я подпаял батарею CR2032 через стандартную схему с двумя диодами, запитав таким образом блок RTC от батареи при отключении питания (перемычку J7 снял).

Устанавливаю правильное время в регистр времени (регистр даты не трогаю) и отключаю питание.
Хочу таким образом увидеть, насколько велика будет погрешность часов с течением времени.

В таком виде плата работает около недели нормально - время от времени подаю питание и смотрю, сколько натикало в RTC.

Включаю на след. день - контроллер не реагирует вообще ни на что! Программа не выполняется, даже J-Link подключится не может, сыпет ошибками.
При этом потребление тока контроллером идёт на полную - около 70 ма.
Напряжение на батарее при этом 3050 мв.

Всё начинает нормально функционировать только после сброса по RSTB, то есть флеш не слетает, а происходит какое-то залочивание контроллера при включении...
Плата лежит дома, при комнатной температуре...

Непонятно это всё, это что-же, мне теперь каждую неделю батарейку передёргивать и переустанавливать часы?
Мог ли я что-то напортачить в коде стартапа? Но эта проблема возникает только после простоя платы без питания несколько дней...

я года 4 сидел с "неправильным" тактом из-за этой "особенности", правда в моем случае ошибка была
практически ничтожна 1/24000, но все же я ее случайно поймал и после пятого прочтения даташита
я нашел нужные слова:
When WAVSEL = 10, the value of TC_CV is incremented from 0 to the value of RC, then automatically
reset on a RC Compare.

автоматически это видимо именно значит в тот же момент не зависимо от прескейлера
и выяснилось это все при программировании PWM контроллера когда у меня банально
не совпали частоты...


ну и да, я включился в ряды SAM3водил,
так что по мере освоения могу тоже давать ответы и задавать вопросы,
и если топикстартер не против(?) то буду делать это в этой теме...

Добро пожаловать!
Конечно, я не против
Только вот запропастился куда-то наш гуру, в отпуске, наверное