Перейти к содержанию
    

"ST does not have any ...

 

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

 

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

 

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

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

.. и почему бы не использовать i2c в таком случае???

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

 

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

 

.. и почему бы не использовать i2c в таком случае???

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

  /* 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 вкратце выглядит вот так:

/* ЗАПИСЬ в регистр */
 /* дожидаемся окончания передачи */
 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
[codebox] !!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подниму тему по любимой ревизии С :angry2:

Пред история... Был приборчик разработан пару лет назад, все с ним было хорошо, собирали прошивали короче все было ок, 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 и тут наступает занавес :krapula: :krapula: чип нормально начинает работать в отладчике, все ок.... Все повторяется как только делаешь erase.... Проверили на 10 чипах...

Еще раз скажу что с ривизией B такого не происходить..

Чип под микроскоп сразу изучать все нормально атмеловский произведен 10 год 52 неделя...

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

Вот и думаем или лыжи не едут....... или...

Явно проблемные чипы...

С атмелом кто нибудь попадался на таком???

И как то возможно проверить что чип именно атмеловский?

И вопрос как теперь поставщику то доказать что брак в явной форме, они то все уже после пайки...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

да согласен, попутал версия 58818С... хоть это радует...

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А с переключением все корректно?

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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

×
×
  • Создать...