| Автор |
Съобщение |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
 Проблем с PLL за LPC2468
Здравейте. Опитвам се да пусна PLL на едно LPC2468 като използвам последователността дадена от NXP в документацията, но не ми се получава. Кода съм го пробвал за работи за LPC2364 и работи чудесно, но тук не става макар че по принцип не открих разлика в начина на настройване между двете LPC-та. Ето кода който ползвам за инициализация на PLL-la.
//1. Disconect PLL if connected
if(PLLSTAT & PLLSTAT_PLLC_MASK) // If PLL is connected
{
PLLCON = 1; // Enable PLL, disconnected
PLLFEED = 0xAA;
PLLFEED = 0x55;
}
// 2. Disable the PLL with - one feed sequence.
PLLCON = 0; // Disable PLL, disconnected
PLLFEED = 0xAA;
PLLFEED = 0x55;
//3. Step 3
//4. Select Clock Source for PLL CLKSRCSEL = 0x01; // The Main OSC selected for clock source
//5. Write to the PLLCFG(M and N) and make it effective with one feed sequence. The PLLCFG can
// only be updated when the PLL is disabled.
PLLCFG = 0x13; // M=20 and N=1 FIN=12MHz FCCO=480MHz M-1=19 N-1=0
PLLFEED = 0xAA;
PLLFEED = 0x55;
//6. Enable the PLL with one feed sequence.
PLLCON=0x01; // Enable PLL
PLLFEED = 0xAA;
PLLFEED = 0x55;
//7. Change the CPU Clock Divider setting for the operation with the PLL.
CCLKCFG=0x07; //devide FCCO/CCLKSEL+1 - 480MHz/8=60MHz
//8. Wait for the PLL to achieve lock by monitoring the PLOCK bit in the PLLSTAT register
while(!(PLLSTAT&PLLSTAT_PLOCK_MASK)); //wait PLL to be locked
//9. Connect the PLL with one feed sequence.
PLLCON = 0x03; // Enable PLL and Connect PLL
PLLFEED = 0xAA;
PLLFEED = 0x55;
while ( !(PLLSTAT & PLLSTAT_PLLC_MASK) );//;wait PLL to be connected
Значи проблема се получава когато се минава през стъпка 4. И тогава процесора просто забива и не минава нататък. Може би има някакъв проблем когато се превключва от RC осцилатора към MAIN осцилатора и LPC-to забива. Това чудо съм го писал на CrossStudio. Ако някой е имал подобен проблем и го е разрешил нека помогне. Предварително благодаря!
|
| Чет Яну 22, 2009 7:38 pm |
|
 |
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 2:01 pm Мнения: 1952 Местоположение: Варна
|
Здравей,
Преди да започнеш конфигурацията на PLL стартирал ли си основния осцилатор. Трябва и да го изчакаш да се стабилизира.
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
| Пет Яну 23, 2009 10:51 am |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
Да стартирам основния осцилатор и го изчаквам да се стабилизира и след това се занимавам с PLL-a, но когато се опитам да включа основния осцилатор като входен клок за PLL нещата се прецакват, забива и не знам какво става.
|
| Пет Яну 23, 2009 12:13 pm |
|
 |
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 6:52 pm Мнения: 11266 Местоположение: Добрич
|
Не разбирам от LPC-та но има някои общи заболявания при много арм-чета
1) JTAG клока трябва да е по-нисък от клока на таргет ядрото, иначе някои команди се дънят и дебъгера се омазва. Затова процедурите за смяна на клок не винаги могат да се дебъгват, щото пускат една инструкция, процесора я изпълнява и спира, а дебъгера губи връзка и си мислиш че всичко ти е забило. Пробвай с брейкпоинт след смяна на клока и GO.
2) При стартиране някои дебъгери качват разни агенти, било да префлашнат или нещо друго. Та тия агенти често си пускат осцилатора или PLL-a щото иначе ще префлашват цял ден. Лошото е, че не винаги после изключват всичко и реално ти си мислиш че кодът ти се изпълнява след ресет, а пък всъщност не е така. Затова ако искаш да дебъгваш обикновено се проверява на какъв клок си в момента, или първо изпълняваш код за изключване (което е по-удобно).
3) Избягвай да режеш клона, на който седиш. т.е. не бъзикай PLL-a ако в момента ядрото го ползва. Поради горната точка може да се окаже, че кодът ти се изпълнява с PLL клока.
Казвам всичко това защото няма логика един процесор да забива, когато се програмира PLL дето не се ползва. Най-вероятно се ползва по някакъв начин и затова има проблем.
|
| Пет Яну 23, 2009 12:53 pm |
|
 |
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 2:01 pm Мнения: 1952 Местоположение: Варна
|
Имах подобни проблеми, но малко съм позабравил къде беше точното решение. miro_atc ми поосвежи паметта.
@Achiles Добави това непосредствено преди точка 4.
Или пробвай само за доказателство на тезата да дебъгваш с доста по-нисък клок на JTAG.
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
| Пет Яну 23, 2009 1:04 pm |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
10x miro_atc. По точка 1 съм пробвал много пъти но не стават нещата. Като мине през CLKSRCSEL = 0x01; и забива и ми изважда съобщение "Cannot stop target" като се опитам да изляза от дебъг режим. Блокираше и при Startup фаила на същото място когато се опитавах да го дебъгвам там. После сложих #define NO_PLL_ENABLE в фаила за да не ми бъзика PLL при стартиране и да си го правя само аз но си забива и в моя код.
Що се отнася до съвет No3 - нали изключвам PLL по процедурата която е в документацията така че не би трябвало работи с него. А иначе този код съм си го ползвал за LPC2364 и там работи и търсих да няма някаква разлика но не успях да открия. Но ще го мъча може да стане някой ден.
|
| Пет Яну 23, 2009 1:10 pm |
|
 |
|
miro_atc
Ранг: Форумен бог
Регистриран на: Нед Фев 26, 2006 6:52 pm Мнения: 11266 Местоположение: Добрич
|
много странно с какво дебъгваш... и в кой файл го слагаш това. Надявам се не в сорс файла, щото досега не съм срещал АРМ дебъгер, който да се влияе от #define
Иначе както казах не познавам LPC и не мога да помогна повече.... Не знам как работи просто. При SAM примерно си има следене на клока и ако си на PLL може да спреш PLL-a то ще се усети че няма клок, ще преключи на вътрешните 32Кhz и ако имаш зададен делител може и на честота под 1Hz да падне. Естествено дебъгера веднага ще те отсвири... Но иначе процесора ще си работи, ех доста баааавничко разбира се. Можеш осцилатора да разпоиш както си работи -> няма да забие...
Абе има много вероятности... Затова спираш в началото на функцията и без да изпълнява НИКАКЪВ код само четеш и пишеш през дебъгера регистрите проиграваш цялата процедура... Проверяваш естествено стойностите на регистрите за да видиш кое ти е било включено и кое ти включваш, дали се включва и прочие...
|
| Пет Яну 23, 2009 1:35 pm |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
Опитах номера с да дебъгвам с доста по-нисък клок на JTAG и не се промени нищо. После обаче не знам как на магия може би успях да го прекарам успешно през въпросната точка 4, но пък заби на точка 7.
//7. Change the CPU Clock Divider setting for the operation with the PLL. CCLKCFG=0x07; //devide FCCO/CCLKSEL+1 - 480MHz/8=60MHz
Та се чудех дали това трябва да се направи точно тук но в документацията изрично пише да се направи преди да се включи PLL-a така че си го оставих тук, но отново нямам идея защо така се получава. Явно има нещо при превключването и деленето на клока. Ще се мъча пък дано тръгне някой ден.
|
| Пет Яну 23, 2009 3:40 pm |
|
 |
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 2:01 pm Мнения: 1952 Местоположение: Варна
|
Това е функцията която ползвам.
Използвам я точно за LPC2468.
Проблема според мен е точно в това че понижаваш честотата на ядрото под тази на JTAG-a.
Някъде може би излишно се презастраховам с полирането на флаговете, но ти прецени какво да оставиш.
Успех!
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
| Пет Яну 23, 2009 5:17 pm |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
Мерси ще пробвам. Мисля че при мен може да има и някакъв хардуерен проблем затова ще проверя отново всичко и тогава ще видим какво ще стане.
|
| Пет Яну 23, 2009 5:25 pm |
|
 |
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 2:01 pm Мнения: 1952 Местоположение: Варна
|
Винаги можеш да приложиш и насилствени методи.
Зареди през серийния порт чрез вградения bootloader една орязана програмка - само конфигурация на процесора с включен PLL и един мигащ светодиод на някой пин. Може да я качиш във FLASH-a може във RAM-a. Имай впредвид че bootloader-a тръгва с вътрешния генератор и включен PLL. Така че ако я качваш в RAM твоя код трябва да може успешно да преконфигурира PLL-a. Ако светодиода ти мига с честотата която си задал значи кода за конфигуриране на PLL-a и целия хардуер в който се съмняваш работи и проблема остава да е във връзката ти през JTAG-a. Повтаряш теста с различни конфигурации за PLL-a и делителите както и с изключен PLL за да си сигурен в резултата.
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
| Съб Яну 24, 2009 9:14 am |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
Най-накрая успях да разреша проблема с PLL-a, макар и да стана малко странно. Сменях кварца и и кондензаторите и какво ли не пробвах. Последно ми забиваше на точка 7.
7. Change the CPU Clock Divider setting for the operation with the PLL. CCLKCFG=0x07;
В документацията пише, че в CCLKCFG регистъра се поддържат само 0 и нечетните стойности като не е препоръчително да се пишат четни стойности. Колкото и нечетни стойности да слагах все ми забиваше и накрая като записах 4 всичко си тръгна като по мед и масло. Явно не винаги трябва да се доверяваме на писаното по дебелите книги  .
Искам да благодаря на всички които откликнаха на моя зов за помощ. Мисля че от вас научих нови и интересни неща които вероятно ще са ми полезни занапред. Ще се радвам ако помагате и в бъдеще. 10х.
|
| Вто Яну 27, 2009 11:46 pm |
|
 |
|
Zdrav
Ранг: Форумен бог
Регистриран на: Сря Яну 26, 2005 2:01 pm Мнения: 1952 Местоположение: Варна
|
Можеш ли да провериш каква е действителната честота на която работи ядрото с тези конфигурации?
Странно защо при теб се получава така. Аз използвам Fosc = 12 MHz, N = 1, M = 12 и записвам 3 в CCLKCFG. За да получа 72 MHz за ядрото.
Каква ревизия е чипа на платката ти?
_________________ Най-опасният враг на истината и свободата е мнозинството.
|
| Сря Яну 28, 2009 6:19 am |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
Ревизията е "B". Аз последно ползвам кварц 18.432МHz като стойностите са N=16 и M=125 и така получавам pllclk=288MHz. После като разделя на CCLKCFG=0x04; тоест на 5 се получава 57.6MHz. Тая честота я деля на 4 после за UART като наглася UART-a на скоростта на която искам ми праща и приема точно това което искам. Така че мисля че трябва честотата 57.6MHz да е точно такава или поне така излиза по пътя на логиката. Не знам дали има някакъв начин точно да се измери на колко реално работи ядрото (може би въпроса е глупав  ) ?
|
| Сря Яну 28, 2009 11:00 am |
|
 |
|
Achiles
Ранг: Минаващ
Регистриран на: Сря Фев 07, 2007 11:58 am Мнения: 16 Местоположение: Пловдив
|
Сега го пробвах да разделя 288 на 4 за 72MHz като пиша в CCLKCFG 3 и се получи. Просто не знам как стана след като 1000 пъти не ставаше преди това. Zdrav възможно ли е според теб проблема да е бил в кварца или кондензаторите към него и въпреки че OSCSTAT бит се сетва да няма стабилна честота и при превключването към PLL-а той да забива? Друго обяснение не виждам защото и преди както и сега спазвах писанията в документацията и съм сигурен, че не сам объркал нищо от там, но не тръгваше. Що се отнася за честотата на JTAG-a за която стана въпрос също пробвах каква ли не ама резултата си беше същия.
|
| Сря Яну 28, 2009 11:18 am |
|
|