At91SAM7S256 с буквой С Опции

[SpiritDance]

Только что получил следующее:

В новой версии исправлены ошибки в АЦП, ШИМ, интерфейсах SPI, SSC, TWI, USART и регуляторе напряжения. Увеличено время доступа к Flash-памяти, что может потребовать перепрограммирования количества циклов ожидания. Количество циклов перезаписи энергонезависимой памяти улучшено. Полный перечень изменений имеется в data sheet на серию AT91SAM7S ревизии 6175K (раздел 40, Errata).

Ну и как водится старую ревизию снимают, будет только новая. Всем кто на них делал что-либо большой привет! Если не хватит производительности или переделывайте или снимайте прибор с производства. Какая неожиданная радость!! Ну и цена 7 баксов теперь будет.

Когда этих дол...ов уже купит микрочип?

[kovigor]

Увеличено время доступа ...

Это не ошибка переводчика ? Что в англоязычном оригинале-то написано ?

[aaarrr]

Это не ошибка переводчика ? Что в англоязычном оригинале-то написано ?

Нет, не ошибка. На частотах выше 20MHz теперь нужно ставить 1 WS, выше 48.1 - два. Но это касается только S128C и S256C.

[SpiritDance]

40.9.1Embedded Flash Controller (EFC)

40.9.1.1EFC: Embedded Flash Access Time 1

The embedded Flash maximum access time is 20 MHz (instead of 30 MHz) at zero Wait State
(FWS = 0).
The maximum operating frequency with one Wait State (FWS = 1) is 48.1 MHz (instead of
55MHz). Above 48.1 MHz and up to 55 MHz, two Wait States (FWS = 2) are required.

Problem Fix/Workaround
Set the number of Wait States (FWS) according to the frequency requirements described in this
errata.

Молодцы.

[kovigor]

Молодцы.

Может быть, ваш проект позволяет разместить часть кода в ОЗУ ?

[SpiritDance]

Может быть, ваш проект позволяет разместить часть кода в ОЗУ ?

Да вроде бы должно все прокатить без изменений. Осталось только впаять семплы и молиться. Выкрутиться, если не прокатит, тоже как-нибудь можно будет, я думаю.

Проблема в том, что у меня и без этого работы полно, а править что-то в уже написанном когда-то и работающем коде почему то не хочется. Зачем надо что-то изменять в процессоре, которому 8 лет? То есть большинство проектов под него уже сделано и тупо клепается на конвеере. Матерных эпитетов не хватает.

[prottoss]

Да вроде бы должно все прокатить без изменений...

Можно не надеяться на "вроде бы" а проверять ревизию МК при запуске программы.
Но то что они те, кем Вы их назвали я согласен.

[Xenia]

Зато в новой ревизии "C" огромную кучу прочих эррат исправили! Причем так, что тех практически не осталось. А что предел флеша с 30 до 20 МГц понизили, то, думаю, лишь для пущей гарантии надежности. Т.е. они не флешь хуже поставили, а по прежним образцам статистически обнаружили (или жаловались клиенты), что какие-то экземпляры на пределе частоты сбоят. Вот они в даташите и понизили на треть гарантированный порог, типа перестраховались.

Ставить новый экземпляр вместо старого и не брать в голову!

[aaarrr]

Зато в новой ревизии "C" огромную кучу прочих эррат исправили! Причем так, что тех практически не осталось.

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

А что предел флеша с 30 до 20 МГц понизили, то, думаю, лишь для пущей гарантии надежности. Т.е. они не флешь хуже поставили, а по прежним образцам статистически обнаружили (или жаловались клиенты), что какие-то экземпляры на пределе частоты сбоят. Вот они в даташите и понизили на треть гарантированный порог, типа перестраховались.

Угу, а для SAM7S64 решили что и так сгодится.

Ставить новый экземпляр вместо старого и не брать в голову!

Ну-ну.

А что предел флеша с 30 до 20 МГц понизили, то, думаю, лишь для пущей гарантии надежности.

Кстати, цифра 48.1МГц для предела 3WS тоже вызывает сомнения: 20 * 2 = 40МГц. Но если бы они написали в еррате такое, клиенты бы с говном съели совсем не поняли.
Так что вполне может оказаться, что истинные масштабы проблемы скрываются.

[Xenia]

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

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

А с другой стороны, у Atmel как раз и был затык с производством, т.к. он фактически на новое место с производством переехал. С понедельника заново жить начал . Поговаривают, что на новом месте даже технология стала на сколько-то нанометров меньше, оттого и пришлось чипы по-новому "разводить". А раз так, то самое время всякие прогрессивные изменения в конструктив вносить, т.к. потом в процессе тиражирования будет поздно. И в AVR-ок это тоже коснулось - там с буквой "A" серии появились, а так же новые чипы на замену старым.

Угу, а для SAM7S64 решили что и так сгодится.

А про этот фиг его знает . Может быть у них flash блоками по 64К или того меньше? Делают, скажем, все под одну гребенку как SAM7S256, испытывают на высокой частоте, и если не тянет, то кастрируют тормозные блоки, оставляя самый быстрый. Т.е. почти так же, как Intel свои процессоры под Селерон маркировал, когда кэш оказывался с брачком.

_____________________

Хотя по правде сказать, я на Atmel тоже маленько обижена за медленный flаsh. Похоже на то, что 25-33 МГц ему предел, а дальше приходится по частоте прореживать, добавляя лишние такты ожидания. Видимо по этой же причине AVR тоже выше 20 Мгц не работают, поскольку такт пропускать не умеют. И с AVR32 та же история, что с SAM7S. Т.е похоже, что независимо от архитектуры (ARM, AVR или AVR32), flash они тачают по одной и той же технологии, которая еще быстрее работать не может.

По началу я думала, что так и быть должно - мол, физический предел флешу в этом месте положен. Но когда узнала, что серия RX600 от Renesas работает на своем флеше без дополнительных тактов ожидания аж до 100 МГц, расстроилась за Atmel. Ведь фактически только скорость flаsh не дает их контроллерам работать быстрее. И тут 100 МГц не надо, было бы достаточно 55-60, чтобы стали не нужны такты ожидания практически на всех моделях выпускаемых контроллеров. Ведь время идет вперед, и одного только повышения энергосбережения маловато будет, хотелось бы, чтобы и в скорости была прибавка.

И хотя эта тема находится в разделе ARM и формально посвящена одному из МК этой архитектуры, тем не менее, обсуждаемый вопрос касается исключительно скорости flash. А стало быть, данная проблема простирается на только на SAM7S, но и на всю продукцию компании Atmel. Что они там написали в даташите - лишь частности, а суть же в том, что, начиная с 20 Мгц начинается у них зона неустойчивой работы flash. Завестись такой МК заведется, но сколько протянет на этой частоте без единой ошибки? - Вот в чем вопрос! А нормы очень жесткие - контроллер годами должен работать, не допуская сбоя по внутренним причинам. Отсюда и тот лимит скорости, который закладывает производитель в даташит своего изделия.

Полагаю, что не будет для этой темы флеймом, если кто-нибудь знающий поделится здесь информацией о том, до каких частот может работать flash в роли ПЗУ. А то вдруг уже проявилась flash-память "нового поколения", которая может работать в несколько раз быстрее, чем та, с которой начинал и продолжает использоваться Atmel?

[aaarrr]

В SAM3 флеш исправили, снабдив её 128-битной шиной с ускорителем. Хорошие, кстати, процессоры получились. Еще бы побольше RAM, поменьше глюков и приличную документацию - цены бы им не было.

[SpiritDance]

Можно не надеяться на "вроде бы" а проверять ревизию МК при запуске программы.

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

Ставить новый экземпляр вместо старого и не брать в голову!

Да-да.

Снимешь изделие с производства - народ ругается,

Не народ, а производители, кто на это изделие заложился с перспективой на годы.

и оставишь - тоже ругается.

Вы, Ксения, что-то путаете.

[_Pasha]

Что лучше - заложиться на годы горбатым по определению камешком или резко сменить приоритеты и заложиться на другой горбатый мк.? ATMEL и STM - вроде бы разные, а ненавижу их одинаково

[SpiritDance]

STM - вроде бы разные, а ненавижу их одинаково

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

[model25]

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

вот официальные заявления разных производителей электр. компонентов на события в Японии....как я понял из офиц письма у ST там только офисы продаж .)))

http://www.ebv.com/en/press-print/earthqua...ref=u1264-c7237

вот выдержка оттуда
"ST does not have any manufacturing operations in Japan.Our office operations in Japan continue both in Tokyo and Osaka, while distribution in Japan of our finished products is encountering temporary difficulties for obvious reasons. We are collaborating very closely with our Japanese customer and supplier base."

Сообщение отредактировал model25 - Mar 22 2011, 05:27

[SpiritDance]

"ST does not have any ...

Ну вот и отличненько.


Сейчас напаяли несколько образцов из серии С. На одном приборе почти все получилось: прибор воспроизводит звук с частотой 12КГц - различимы подергивания - очевидно работает процессор чуть помедленнее, думаю это можно победить, главное что USB запустилось и прочее.

На втором приборе (другом) вылез затык: не работает нормально ADXL345 - атмеловские индусы улучшили SPI. Придется ковыряться в этом, искать повидло.

И возможно это еще не все.

[model25]

На втором приборе (другом) вылез затык: не работает нормально ADXL345 - атмеловские индусы улучшили SPI.

я в своем проекте тоже сначала хотел заюзать ADXL345 , но приобрел аксель MMA7455 (Freescale), ..вот именно Фрискейловцы пострадали от землятресения в Японии (у них там оказывается есть производство и не одно )
..хотел спросить как Ваши впечатления от ADXL345 ???
.. и почему бы не использовать i2c в таком случае???
у меня сразу все заработало по i2c (правда мануал к MMa7455 ужасно написан, в противовес adxl345 )))))

[SpiritDance]

я в своем проекте тоже сначала хотел заюзать ADXL345 , но приобрел аксель MMA7455 (Freescale), ..вот именно Фрискейловцы пострадали от землятресения в Японии (у них там оказывается есть производство и не одно )

Я насколько понял они взаимозаменяемы pin-to-pin, хотя freescale не пробовал.

..хотел спросить как Ваши впечатления от ADXL345 ???

Сугубо положительные.

Правда на шкале 16G, на которой я работаю есть шумы измерения ускорения свободного падения. Также весьма подвержен наводкам от GSM - нужно убирать от модема подальше.

.. и почему бы не использовать i2c в таком случае???
у меня сразу все заработало по i2c (правда мануал к MMa7455 ужасно написан, в противовес adxl345 )))))

Поздно уже. Да и ног нет.

[SpiritDance]

Волосатые руки наконец дотянулись до SPI. Оказалось теперь не срабатывает бит LASTXFER и CS1 после окончания передачи лежит в нуле и не дышит. И это на двух платах, сигналы все в норме.

Код инициализации вот такой:

CODE

/* SPI reset */
//* Disable all interrupts
AT91C_BASE_SPI->SPI_IDR = 0xFFFFFFFF;

//* Reset all the Chip Select register
AT91C_BASE_SPI->SPI_CSR[0] = 0;
AT91C_BASE_SPI->SPI_CSR[1] = 0;
AT91C_BASE_SPI->SPI_CSR[2] = 0;
AT91C_BASE_SPI->SPI_CSR[3] = 0;

//* Reset the SPI mode
AT91C_BASE_SPI->SPI_MR = 0 ;

//* Disable the RX and TX PDC transfer requests
AT91C_BASE_SPI->SPI_PTCR = AT91C_PDC_RXTDIS | AT91C_PDC_TXTDIS;

//* Reset all Counter register Next buffer first
AT91C_BASE_SPI->SPI_TNPR = 0;
AT91C_BASE_SPI->SPI_TNCR = 0;
AT91C_BASE_SPI->SPI_RNPR = 0;
AT91C_BASE_SPI->SPI_TNCR = 0;
AT91C_BASE_SPI->SPI_TPR = 0;
AT91C_BASE_SPI->SPI_TCR = 0;
AT91C_BASE_SPI->SPI_RPR = 0;
AT91C_BASE_SPI->SPI_RCR = 0;

//* Disable receiver and transmitter and stop any activity immediately
AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SWRST | AT91C_SPI_SPIDIS;
AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SWRST | AT91C_SPI_SPIDIS;

/* Configure PIOs */
AT91C_BASE_PIOA->PIO_PDR = (unsigned int) AT91C_PA13_MOSI
|(unsigned int) AT91C_PA14_SPCK
|(unsigned int) AT91C_PA12_MISO;

AT91C_BASE_PIOA->PIO_ASR = (unsigned int) AT91C_PA13_MOSI
|(unsigned int) AT91C_PA14_SPCK
|(unsigned int) AT91C_PA12_MISO;

/* аппаратный сигнал CS для акселерометра */
AT91C_BASE_PIOA->PIO_PDR = (unsigned int) AT91C_PA31_NPCS1;
AT91C_BASE_PIOA->PIO_ASR = (unsigned int) AT91C_PA31_NPCS1;

/* Включаем модуль SPI в PMC */
AT91C_BASE_PMC->PMC_PCER = (unsigned int) 1 << AT91C_ID_SPI;

/* Кофигурируем SPI в режиме MASTER без CS */
AT91C_BASE_SPI->SPI_MR = AT91C_SPI_MSTR | AT91C_SPI_MODFDIS | AT91C_SPI_PCS;

/* Конфигурируем CS */
/* Конфигурируем канал SPI для DF AT45DBXXX */
AT91C_BASE_SPI->SPI_CSR[0] = AT91C_SPI_BITS_8 /* отрицательная полярность тактов */
| AT91C_SPI_CPOL
| ((16 << 8) & AT91C_SPI_SCBR); /* делитель MCK */


/* конфигурируем канал 1 для акселерометра ADXL345 4 MHz максимум */
AT91C_BASE_SPI->SPI_CSR[1] = AT91C_SPI_BITS_8
| AT91C_SPI_CPOL /* отрицательная полярность тактов */
| AT91C_SPI_CSAAT /* не поднимать CS после предачи слова */
| ((16 << 8) & AT91C_SPI_SCBR) /* делитель MCK */
| ((24 << 16) & AT91C_SPI_DLYBS); /* пауза перед подачей тактирующего сигнала */

/* Включаем SPI */
AT91C_BASE_SPI->SPI_CR = AT91C_SPI_SPIEN;

Работа с SPI вкратце выглядит вот так:

CODE

/* ЗАПИСЬ в регистр */
/* дожидаемся окончания передачи */
while(!(AT91C_BASE_SPI->SPI_SR & AT91C_SPI_TXEMPTY))
{ continue; }

/* выбираем указанный чип-селект */
AT91C_BASE_SPI->SPI_MR &= 0xFFF0FFFF;
pcs_device = (~(1 << chip_select));
AT91C_BASE_SPI->SPI_MR |= ( (pcs_device << 16) & AT91C_SPI_PCS );

/* отсылаем слово */
AT91C_BASE_SPI->SPI_TDR = send_word | (( pcs_device << 16) & AT91C_SPI_TPCS);



/* ЧТЕНИЕ из регистра */
/* дожидаемся окончания передачи */
while(!(AT91C_BASE_SPI->SPI_SR & AT91C_SPI_TXEMPTY))
{ continue; }

/* убираем последствия предидущих транзакций */
temp = AT91C_BASE_SPI->SPI_RDR;

/* выбираем указанный CS */
AT91C_BASE_SPI->SPI_MR &= 0xFFF0FFFF;
pcs_device = (~(1 << chip_select));
AT91C_BASE_SPI->SPI_MR |= ( (pcs_device << 16) & AT91C_SPI_PCS );

/* для корректной работы нужно записывать нули */
AT91C_BASE_SPI->SPI_TDR = 0x0000 | ((pcs_device << 16) & AT91C_SPI_TPCS) | AT91C_SPI_LASTXFER;

/* дожидаемся окончания передачи */
while(!(AT91C_BASE_SPI->SPI_SR & AT91C_SPI_RDRF))
{ continue; }

temp = AT91C_BASE_SPI->SPI_RDR;

После последней транзыкции наблюдаю печальное положение вещей на CS1, данные вроде такие как надо, с тактированием точно все ОК. На старых ревизиях A и B все работает как надо. Никаких упоминаний в эррате о таком поведении конечно не нашел.

Продолжаю изучать улучшенный кристалл за 7 баксов.

Сообщение отредактировал IgorKossak - Dec 21 2011, 10:05

Причина редактирования: [codebox] !!!

[Aquatik]

Подниму тему по любимой ревизии С
Пред история... Был приборчик разработан пару лет назад, все с ним было хорошо, собирали прошивали короче все было ок, SAM7S256 был ревизии В...
Намедни собрали серию, хорошо что не большую, на новой ревизии... И тут начались танцы с бубном!!!
Прибор миниатюрный, житага нет.. Шьется через Самбу... Загрузчик стартует самба чип увидела, но прошить не может!!!
log erase+write

loading history file ... 0 events added
SAM-BA console display active (Tcl8.4.13 / Tk8.4.13)
(AT91-ISP v1.13) 1 %
(AT91-ISP v1.13) 1 % FLASH::EraseAll
-I- GENERIC::EraseAll
-I- Sector 0 unlocked
-I- Sector 1 unlocked
-I- Sector 2 unlocked
-I- Sector 3 unlocked
-I- Sector 4 unlocked
-I- Sector 5 unlocked
-I- Sector 6 unlocked
-I- Sector 7 unlocked
-I- Sector 8 unlocked
-I- Sector 9 unlocked
-I- Sector 10 unlocked
-I- Sector 11 unlocked
-I- Sector 12 unlocked
-I- Sector 13 unlocked
-I- Sector 14 unlocked
-I- Sector 15 unlocked
-I- GENERIC::EraseAll
-E- Generic::EraseAll returned error (0x00000004)
(AT91-ISP v1.13) 1 % send_file {Flash} "C:/Documents and Settings/Fly/Рабочий стол/job_test.bin" 0x100000 0
-I- Send File C:/Documents and Settings/Fly/Рабочий стол/job_test.bin at address 0x100000
first_sector 0 last_sector 3
-I- Writing: 0xD300 bytes at 0x0 (buffer addr : 0x202BC8)
-I- 0xD300 bytes written by applet
-I- Writing: 0x7E4 bytes at 0xD300 (buffer addr : 0x202BC8)
-I- 0x7E4 bytes written by applet
-I- Sector 0 locked
-I- Sector 1 locked
-I- Sector 2 locked
-I- Sector 3 locked
(AT91-ISP v1.13) 1 %

Устройство перегружаешь, а оно опа опять на загручики стоит... Типа и не прошивали....
Зная что самба вещь довольно не перманентная, начали прошивать самба прог, он заливает весело дергает ножкой, выбранной в программе,
рапортуя о том что прошил удачно..
Устройство после перезагрузки стартует, вроде все ок, но работает не стабильно часто виснет....
В это же место ставишь чип ревизии В, все становить нормально и самба видет его, и глюков нет...
Ну думали может сборка, перебрали все платы, на всех так же... Ставишь чип В вопрос сразу снимается...
Начали дальше копать, чип QFN64 особо не потыкаешься скопом... Благо был еще один проект с таким же корпусом и на нем есть житаг...
Снимаем с него чип ставим туда С... Чип перед этим затираем ножкой ERASE, для чистоты эксперимента.
Желинк его увидел.... Запускаем отладку во флешь и начинаются чудеса на виража....
После входа в функцию низкоуровневой иницилизации LOWLEVELINIT он начинает беспорядочно скакать по флешь в неопределенной последовательности....
Пока колдовали с настройками случайно был выбран тип SE256, и прошит в отладку во флешь.... Ну бывает, ошиблись... Вернули обратно S256 и тут наступает занавес чип нормально начинает работать в отладчике, все ок.... Все повторяется как только делаешь erase.... Проверили на 10 чипах...
Еще раз скажу что с ривизией B такого не происходить..
Чип под микроскоп сразу изучать все нормально атмеловский произведен 10 год 52 неделя...
Мы к поставщику, где брал? он говорить у атмела в канаде...
Вот и думаем или лыжи не едут....... или...
Явно проблемные чипы...
С атмелом кто нибудь попадался на таком???
И как то возможно проверить что чип именно атмеловский?
И вопрос как теперь поставщику то доказать что брак в явной форме, они то все уже после пайки...

[Aquatik]

С самбой вопрос снят... 2.11 версия корректно с ревизией С работает.. Но глюки описанные выше остались...

[aaarrr]

А на какой частоте он у вас работает?

[Aquatik]

На трех частотах... 2 мГц - 18.432 мГц - 48 мГц с PLL...

Ептить.... Блин еб....й атмел... В еррате есть ответ на мой вопрос! параграф 40.6.6.2 PMC_MCKR...

[aaarrr]

В еррате есть ответ на мой вопрос! параграф 40.6.6.2 PMC_MCKR...

Этот параграф не относится к ревизии C.

Тут вопрос, когда процессор "падает" - при работе от кварца, от PLL, в моменты переключения?

[Aquatik]

Этот параграф не относится к ревизии C.

Тут вопрос, когда процессор "падает" - при работе от кварца, от PLL, в моменты переключения?

да согласен, попутал версия 58818С... хоть это радует...
Проц падает при переключение из ПЛЛ в майнклок

А не может ли дело быть Embedded Flash conroller в 40.9.1.1?

[aaarrr]

Проц падает при переключение из ПЛЛ в майнклок

А с переключением все корректно?
Т.е. последовательность такая: меняем CSS -> ждем MCKRDY -> меняем PRES?

А не может ли дело быть Embedded Flash conroller в 40.9.1.1?

Добавьте WS - узнаете. Но вряд ли, как мне кажется.

[Aquatik]

последовательность такая: меняем CSS -> ждем MCKRDY -> меняем PRES именно так... WS ща попробуем...

[Aquatik]

WS не помогло.... Вернулись к переключению PLL.. При переключении из PLL в main clock в последовательности меняем CSS -> ждем MCKRDY и тут программа зависает и перезагружается по сторожевому таймеру. Хотя в режиме отладки в ОЗУ такое не происходит.

[aaarrr]

А если попробовать расположить в ОЗУ переключатель?

[Aquatik]

пробовали __ramfunc не помогло...

[aaarrr]

Тогда остаются эксперименты, типа переключиться сначала на slow clock и т.п.

Да уж, подложили свинью атмеловцы.

[Aquatik]

при переходе на slow clock, виснет но намного реже... но все равно подвисает...

[Aquatik]

Возможно нашли решения нашей проблемы... При переходе из режима PLL в режим MainClock мы обнуляли регистр PLL (CKGR_PLLR)....
Как только убрали все стало нормально... Причем на B это проходило, а на С нет....
Устройство поставлено на тест, пока сбоев замечено не было...

[D!m@]

Здравствуйте.
Тоже пришлось переходить на ревизию С (at91sam7s256) . Проблема в записи флэша - не пишет и все. Может кто что-то подскажет. Плата работает на частоте 48МГц задержку памяти ставил 1,2,3 всеравно нет записи в флеш. Да на чипе бес буквы С все работает нормально