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


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

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

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

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

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



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

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



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

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

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


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

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

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

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

Подниму тему по любимой ревизии С
Пред история... Был приборчик разработан пару лет назад, все с ним было хорошо, собирали прошивали короче все было ок, 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 неделя...
Мы к поставщику, где брал? он говорить у атмела в канаде...
Вот и думаем или лыжи не едут....... или...
Явно проблемные чипы...
С атмелом кто нибудь попадался на таком???
И как то возможно проверить что чип именно атмеловский?
И вопрос как теперь поставщику то доказать что брак в явной форме, они то все уже после пайки...

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

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

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

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

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

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

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

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

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


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

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

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

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

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