Jump to content

    

Albun

Участник
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Albun

  • Rank
    Участник
  1. Была у меня когда-то тоже похожая проблема с оптимизацией (правда в IAR-е, но может и для KEIL-а это будет тоже) : без оптимизации работало нормально, а с оптимизацией появились хаотические ошибки и зависания. Причем не стабильно - здесь и сейчас - а время от времени, без никакой видимой системы. Но потом после мучительных поисков нашел так-ки причину - у меня не корректно сохранялись регистры в блоке обработки IRQ прерываний. Я не сохранял регистр R12, а как оказалось компилятор этот регистр тоже использует как регистр общего назначения, т.е. в тех процедурах в которых он используется, компилятор не генериует команды на сохранение его при в ходе процедуру и восстановлении его при выходе из процедуры (как это делается с регистрами R4-R11) Соответственно причина была в том что без оптимизации R12 вообще не использовался компилятором, а оптимизированный код изредка использует R12. И весь хаос получался тогда, когда так стекались обстоятельства, что прерывание возникало в процедуре которая пользовалась R12. Обработчик IRQ в моем коде (MyIrqHandler) тоже компилировался (при оптимизации) с R12. А поскольку компилятор не генерирует код сохранения этого регистра при входе, то при выходе из MyIrqHandler R12 был "сбит", вот и получалось что R12 рушился но происходило это редко и хаотично. Проверьте, может и у вас та-же проблема. IRQ_Handler_Entry: PUSH {R0,R1} MRS R1,CPSR BIC R0,R1,#0x1F ORR R0,R0,#ARM_MODE_SVC MSR CPSR_C,R0 ... PUSH {R1-R3,LR} --> а про R12 я забыл, т.е. потом поправил так: PUSH {R1-R3,R12,LR} /POP {R1-R3,R12,LR} ^ в зависимости от того какие регистры выше R3 будут использованы в MyIrqHandler, компилятор сам их сохранит и восстановит (кроме R12 BL MyIrqHandler (MyIrqHandler - процедура на Cи) POP {R1-R3,LR} ... MSR CPSR_C,R1 POP {R0,R1} SUBS PC,LR,#04
  2. Добрый день! Вот собственно случайно наткнулся на следующую странность. Недавно пришла партия микроконтроллеров из китая - LPC2101FBD48, на самом чипе читается маркировка LPC2101F В спецификациях на этот контроллер сказано что в нем 8 кБ внутренней флеш памяти (0х00000000..0x00001FFF) и 2 кБ SRAM - 0x40000000..0x400007FF Но подключившись по JTAGу к нему я случайно увидел что SRAM в нем видна на все 8 кБ (как в старшей модификации - LPC2103), т.е. до 0х40001FFF. Хотя размер ROM соответствует спецификации на LPC2101 - 8 кБ. (Я даже специально попробовал записать "спец" мусор во все 8 кБ SRAM и потом вычитал и сравнил - все байты сходятся, т.е. действительно полноценные 8 кБ) Не могу поднять то-ли это связано с тем, что в маркировке присутствует "F" или это просто какая-то "не легальная" китайская партия отбракованных чипов с перебитой маркировкой. Ни кто не всетречался с подобным?
  3. NXP LPC2388 Греется

    Нет, как я писал выше с самого начала нашел такую проблему на одном из пинов. Но к текущему моменту проверил всю конфигурацию по каждому пину - без ошибок больше. Более того, специально циклил прошивку сразу после установки делителей PLL=288MHz для частоты 72MHz и 48MHz и ДО конфигурирования портов (т.е. все GPIO после вкл. питания - входы) - ничего не менялось (при этом после флеширования такого кода плата полностью обесточивалась чтоб 100% иметь уверенность что следующий запуск не потащит за собой какие-то остатки предыдущего конфигурирования). Тепловыделение - тоже, высокое. Чип холодный только в случае если не вообще ничего не перестраивать по частоте. В общем как я понял из топика, нагрев NXP чипа не является чем-то необычным. Собственно ничего страшного в этом нет, просто теперь буду не пугаться. Выходит как и советовали выше, придется задействовать все энергосберегающие возможности контроллера. Спасибо всем за помощь.
  4. При 5 кГц тормозов, конечно же, не может не быть. Попробуйте в настройках проекта указать скорость не Auto а прописать вручную, причем желательно кратную 18.544MГц например 1159 (вот только не знаю установит ли MT-Link именно такую цифру или округлит). При целой кратной частоте все должно цепляться нормально. Такая низкая автоматическая скорость может быть из-за "не совместимой" частоты процессора, которая устанавливается после запуска (18544). Ведь сразу после ресета джитаг цепляется по вашему логу на 1МГц а значит кабель позволяет. Второй вариант - подкорректировать именно ее, т.е. в прошивке поставить другие делители которые дадут более кратную CPU частоту
  5. NXP LPC2388 Греется

    Измерил - полный ток который потребляет схема - примерно 130 мА. Если отбросить небольшие потребления второстепенными компонентами схемы, то получается, потребление микроконтроллера - в приделах нормы в соответсвии с документацией (125 mA при 72/48MHz при всей включенной периферии). И тем не менее, чип слижком теплый (опять же, сравниваю с SAM-ми которые на полном газе - холодные)
  6. Уважаемые коллеги, есть такая вот ситуация: LPC2388 контроллер, ставлю частоту процессора 72MHz и 48MHz USB, определенное количество ножек используются как GPIO, большинство из них как выходы, несколько - как входы. Порты Р0 и Р1 используются в режиме high-speed, т.е. бит GPIOM = 1. Аномалия в том, что микроконтроллер излишне греется - конечно не обжечься, но излишне теплый. Один "КЗ" обнаружил - одна из ножек сконфигурированная как выход была подсажена на 0, соответственно при установке 1цы на ней ток через нее протекал максимальный - думал проблему решил, но нет, всеравно контроллер греется. С микроконтроллерами LPC очень давно не работал (плотно на SAM-ах сидел последние несколько лет), поэтому прежде чем начну все детально перепроверять, нет ли КЗ на ножках или еще чего в схеме не так, хотел поинтересоваться - может быть такой уровень тепловыделения на максимальных частотах нормальная ситуация для NXP?
  7. Пишу этот заключительный пост в надежде что это поможет кому то, кто еще стоит перед выбором использовать ему SSC в своих продуктах или нет. Итак, прежде всего, SSC есть аббревиатура от СИНХРОННЫЙ последовательный контроллер, т.е. предполагается что все операции передачи данных жестко и строго синхронизированы с тактирующими импульсами. Следовательно, в определенных случаях контроллер мог бы выступать как мастером (ведущим) так и ведомым. Прочитав документацию был приятно удивлен, так как по описанию SSC являлся очень гибкой вещью которую можно было бы конфигурировать большим количеством способов и добиваться различных режимов работы контроллера, что не могло не радовать. Например схемы тактирования трансмиттера и передатчика позволяют выбирать для каждого по три разных источника тактовых импульсов – МСК, использовать тактирование соседнего блока (трансмиттеру такты ресивера, ресиверу – такты трансмиттера), использовать внешнее тактирование ножек TK и (или) RK. Режим трансмиттера в соответствии с той же документацией может быть как чисто передачей данных, так и передаче данных может предшествовать отправка синхронизационной последовательности битов (до 16), и т.п. На практике все оказалось далеко от ожидаемых надежд. В первую очередь засада поджидает если доверчивый разработчик, прочитав радостно документацию, решит использовать SSC в приложении, где не нужны предшествующие передаче синхронизационные последовательности битов. Объясню. Ставим для трансмиттера и ресивера соответствующие поля STTDLY = 0, т.е. при любых раскладах сразу должна начаться передача/прием данных. Ножку TK назначим получать внешний синхросигнал для трансмиттера, ресивер сконфигурируем получать клоки от трансмиттера (CKS поля), поставим длину данных одинаковую для трансмиттера и ресивера 8 бит (просто для удобства): DATLEN = 8 – 1, DATNB – без разницы, например оставим одно слово, т.е. DATNB = 0. Ставим признак старта для трансмиттера – бесконечный, т.е. начинать передачу сразу же как только была запись в регистр THR (т.е. START = 0), для ресивера – стартовать вместе с трансмиттером, т.е. START = 1. Остальные поля описывать не существенно, так как уже и вышеописанной конфигурации достаточно чтоб испытать первое разочарование. После того как контроллер сконфигурирован и готов к работе, пишем в THR данные которые хотим передать, например THR = 0x00. Т.е. с этого момента контроллер получил признак старта для трансмиттера, а значит и ресивер тоже запускается. Еще замечу, что все это в соответствии с официальной документацией – сделав все как описано выше мы должны получить именно то что хотим. Подаем тактовые импульсы на ножку TK. И что имеем? Ресивер радостно начинает вдвигать в себя поступающие биты с ножки RD начиная с первого такта, в то время как трансмиттер начинает выдавать данные только на 4-м (!!!) такте поступившем на TK. Через восемь тактов ресивер сообщит о готовности данных, в то время как трансмиттеру еще останется выдвинуть 3 бита. И это при том что в документации ни слова не сказано об этой интересной особенности. Можно конечно сконфигурировать ресивер начать прием на 4-м такте с помощью STTDLY = 3. Но разве это поможет если с другого конца стоит устройство которое и не подозревает что его первые три тактовых импульса поданные на ножку TK ушли в пустоту??? Описанное выше была попытка использовать SSC в режиме ведомого SPI. Естественно, имея отдельный контроллер SPI (даже два во многих MCU атмела), зачем возиться с SSC? Но тем не менее, задачи бывают разные в жизни и кто знает что может понадобиться. Тем более что прочитав документацию можно сделать вывод что абсолютно никаких препятствий реализовать приведенное выше нет. Теперь поступим по другому, сконфигурируем ресивер получать тактовые импульсы с ножки RK, трансмиттер – тактироваться от синхроимпульсов ресивера, и выдавать таковые импульсы на ножку TK только во время передачи данных (т.е. поле CKO трансмиттера = 2). Остальное как в предыдущем примере. Подаем на RK непрерывные тактовые импульсы. Записываем в THR данные, например THR = 0x00. И что видим? Ресивер радостно начинает вдвигать в себя биты начиная с первого такта на RK ножке. Трансмиттер первые два такта мертв, т.е. на TK ножке импульсов нет, на ТD ножке – мусор. На третьем такте трансмиттер начинает выдвигать данные, ножка TK дублирует такты с RK. Итого после восьмого такта ресивер уже готов, трансмиттеру еще два такта чтоб закончить передачу. Через два такта трансмиттер останавливается (т.е. TK ножка снова неподвижна), а ресивер уже успел еще 2 бита захватить. Конечно можно поставить для ресивера STTDLY = 2 и тогда ресивер только с третьего такта, как и трансмиттер передачу, начнет прием. А ведь в документации об этом ни слова, в документации все красиво описано, прочитав документацию человек подумает а почему бы нет? В документации приведены диаграммы для случая STTDLY = 0 где видно что данные пойдут сразу по наступлению события старт (т.е. в примере выше – по записи в THR) но нигде не сказано что, очевидно, внутренне для SSC этот старт наступит только на 3-м тактовом импульсе. Это был пример реализовать ведущий (мастер) SPI на SSC. Зачем – ответ как и в рассуждении выше. Плюс еще одно “за” – такой SPI мастер имел бы возможность тактироваться внешним клоком, в то время как встроенный SPI тактируется только от частот кратных MCK. В общем насколько я смог постичь, SSC пригоден для использования ТОЛЬКО в приложениях где задействованы предшествующие передаче/приему синхронизационные последовательности битов (до 16). Случаи когда STTDLY = 0 на практике бесполезны из-за описанных выше 2-х или 3-х тактовых задержек, которые просто недопустимы. Р.S. Просьба не ругать сильно, старался как мог. Думаю данная информация будет кому то не лишней.
  8. На свежую голову подумал, действительно, нигде ведь не сказано что приемник остановится как получит столько-то битов, напротив раз есть биты состояния типа OVRUN предполагается что прием будет скажем так, бесконечно долго. Да и тот же "родственный" SPI тоже так работает. Отсюда и постоянные тактовые импульсы на RK выходе, ведь для приемника "выводить тактовые импульсы в течении передачи данных" получается равносильно "бесконечно". Учел это, и переделал слегка схему: теперь RK назначил как вход для тактовых импульсов, ресивер тактируется от этой ножки, трансмитер тактируется от RX_clock, и ножка трансмитера TK теперь как выход - на нее выдается тактовая частота (CKO = только в течении передачи данных). Померял тестером - теперь действительно, на TK выводятся тактовые импульсы ТОЛЬКО на время передачи, т.е. если я передаю 8 бит - то и меряется тоже только 8 тактов, а после - TK стоит. То что надо. Тоже наблюдается задержка - теперь правда 2 тактовых импульса (а не три) на RK проходят и только на 3-й импульс трансмитер начинает выдавать данные и такты. Но все-равно, другая проблема выплыла - если установить ножку TF чтоб выводила низкий уровень в течении передачи данных (FSOS = AT91C_SSC_FSOS_LOW) то... ничего не происходит, на ножке TF постоянный высокий уровень. И в чем может быть проблема теперь??? :maniac: P.S. Опять же странность, точно то же проделал паралельно с ножкой RF - на ней, при тех же установках FSOS, сигнал падает в 0 сразу же на первом тактовом импульсе от RK (несмотря на то что первые 2 имулься еще не есть передача данных) P.S. Проблему c TF решил - просто банально забыл что я ее после бесчисленных тестов еще в одном месте возвращал в режим обычной I/O ножки как выход. Вернул ее на перефирию А и все стало ОК. В общем тогда еще надо проверить работу ресивера - принимает ли он биты начиная с 3-го такта (смущает очень что RF падала в 0 на первом, "холостом" такте)
  9. Ну как же? А сигналы TF RF - можно выбрать как угодно, поле FSOS - в том числе есть и вариант Driven Low during data transfer есть и Driven High during data transfer и еще много других, по моему более чем достаточно, и все это контроллер сам сделает. Поэтому и выбрал его, но похоже что пока не удачно
  10. Слейв не устанавливает сигналы выборки NPCS, а нужно именно чтоб на момент передачи NPCS менялся. Отдельно ножкой дрыгать тоже не получится, так как частоты будут большие и не всегда успею, а если и привязываться к ручному "дрыганью" то это уже будет общая потеря производительности
  11. Так ведь у них написано что это значит что передача начнется как только будет запись в THR. Конечно не сказано и что она закончится как THR опустеет, но мне кажется что это будет бред, смысл тогда всех этих установок количества битов и особенно количества слов в трансфере. А если я выбрал не внешний клок а внутренний от МСК - что же тогда получится, зазевался, не успел вовремя подгрузить в трансмитер новые данные и он по кругу пока суть да дело гоняет то что есть? Нет, не логично. Самыми простыми словами - нужен SPI мастер только с возможностью того чтоб можно было его тактировать извне. А тот SPI что в атмеле тактируется только кратной частотой от MCK
  12. Так ведь в документации написано: CKO Receive Clock Output Mode RK pin 0x0 - None Input-only 0x1 - Continuous Receive Clock Output 0x2 - Receive Clock only during data transfers 0х2 - клок только в течении транзакций. Иначе какая разница между опциями 0х1 и 0х2? Почему же трансмиттер лопатит постоянно? Я настроил его чтоб он выдал только 8 бит один раз и все (поле DATNB по умолчанию тут стоит 0, т.е. колчество слов на один трансфер равно 1). После этого трансмитеру нечего передавать, трансфер закончен. Да, на его вход постоянно идут тактовые импульсы ну и что? На SPI к примеру тоже идут постоянно тактовые импульсы, но ведь после выдачи слова тут все прекращается успешно, а в SSC - затык. Конечно же SSC не SPI, но согласно документации - поведение его отличается от того что должно бы было быть. По поводу RK - ведь это выход,т.е. тут импульсы должны присутствовать непосредственно тактовые, иначе какой же это Синхронный Последовательный Контроллер? Ваше предположение что может потребоваться несколько тактов на инициализацию трансфера - логично, но это не должно влиять на выходные тактовые имульсы генерируемые контроллером для других устройств (в доке написано что это позволит более гибко организать цеопчку разных устройств). В одном устройстве нужно будет 100 тактов на загрузку сдвигового регистра, в другом - 3, бред получится. Поэтому и ожидаю на выходе более логичных данных. Да и в документации клоки жестко расписаны, приведены диаграммы - с первого же клока. Вот из документации: The receiver can also drive the RK I/O pad continuously or be limited to the actual data transfer. Ну как их по другому понять?
  13. Столкнулся со следующей проблемкой при работе с контроллером SSC (в AT91SAM9260). Конфигурация платы такая: - ножка TK0 соединена с ножкой PB0, которую я перевел в режим вывода, т.е. программно устанавливая на ней 0 или 1 я эмулирую тактовые импульсы на вход ТК0; TК0 конфигурируется как периферия А и сам блок SSC трансмиттера предполагается чтоб использовал эту ножку в качестве тактовых импульсов; - TF0 не используется, остается как обычная I/O в режиме входа; - с ТD0 снимаются данные, ножка конфигурируется как периферия А; - на RD0 поступают данные, конфигурируется как периферия А; - RK ножка используется для вывода тактовых импульсов трансмиттера; конфигурируется как периферия А; сам блок ресивера в качестве испульсов использует TK_clock; - RF не используется, остается как обычная I/O в режиме входа; В документации сказано, что можно в качестве TX_clock выбрать из трех сигналов, один из которых - внешний с ножки TF0, что я и делаю (прописывая CKS поле). Далее сказано, что на ножку RK0 можно выводить RX_clock, плюс этот сигнал может выводиться только в период когда активен прием, что я и делаю (СКО поле). Ставлю STTDLY = 0 для трансмиттера и ресивера, т.е. не использую синхронизационные фреймы. Признак начала (START) для трансмиттера ставлю CONTINUOS а для ресивера - TRANSMIT_START, т.е. трансмиттер должен начать передачу данных сразу же после записи в регистр THR и ресивер начать прием как только начнет работать трансмиттер. Выставляю длину данных - 8 бит (DATLEN=7 для трансмиттера и ресивера). Вот код конфигурирования непосредственно SSC: #define AT91C_SSC_CKS_TK_PIN 0x02 AT91C_BASE_SSC0->SSC_IDR = 0xFFFFFFFF; AT91C_BASE_PMC->PMC_PCER = 0x01 << AT91C_ID_SSC0; AT91C_BASE_SSC0->SSC_CR = AT91C_SSC_SWRST; AT91C_BASE_SSC0->SSC_CR = AT91C_SSC_RXDIS | AT91C_SSC_TXDIS; AT91C_BASE_SSC0->SSC_TFMR = AT91C_SSC_DATDEF | AT91C_SSC_MSBF | AT91C_SSC_FSOS_LOW; AT91C_BASE_SSC0->SSC_TCMR = AT91C_SSC_CKS_TK_PIN | AT91C_SSC_CKO_NONE | AT91C_SSC_START_CONTINOUS; AT91C_BASE_SSC0->SSC_RCMR = AT91C_SSC_CKS_TK | AT91C_SSC_CKO_DATA_TX | AT91C_SSC_CKI | AT91C_SSC_START_TK; AT91C_BASE_SSC0->SSC_RFMR = AT91C_SSC_MSBF; AT91C_BASE_SSC0->SSC_PTCR = AT91C_PDC_RXTDIS | AT91C_PDC_TXTDIS; AT91C_BASE_SSC0->SSC_CR = AT91C_SSC_RXEN | AT91C_SSC_TXEN; AT91C_BASE_SSC0->SSC_TFMR = (AT91C_BASE_SSC0->SSC_TFMR & (~AT91C_SSC_DATLEN)) | (0x08 - 0x01); AT91C_BASE_SSC0->SSC_RFMR = (AT91C_BASE_SSC0->SSC_RFMR & (~AT91C_SSC_DATLEN)) | (0x08 - 0x01); Дальше записываю данные в THR (THR = 00) и вручную тактирую TK0 ножку устанавливая 0 и 1 на PB0 ножке. И теперь странно - тестером меряю ножку TD0 - по идее на ней должен сразу же выводиться мой нолик который я записал в THR, на практике же он появляется там только на 4-й (!) тактовый импульс. Первые 3 такта на TD0 стоит единица. После этого (4й импульс) начинает выдвигаться число что я записал в THR (т.е. 0х00) и после 8-го бита TD0 возвращается в 1 (DATDEF я ставлю в 1) и уже остается в таком положении сколько бы тактов не подавать (что есть логично). Т.е. по документации должны СРАЗУ выйти 8 бит (ведь передачу синхронизации я выключил) а выходят первые три 1-цы и только потом уже 8 бит данных. Что не так??? Второе - меряю ножку RK0, которая по идее, в соответствии с документацией должна бы выводить сигнал только в момент когда активен прием (т.е. восемь тактов). Но на практике - на RK0 постоянно идет тактирование, т.е. истекли 8 тактов, ресивер по идее принял данные и уже должен остановиться - но нет, RK0 ножка, все равно, выводит тактовые импульсы бесконечно, как будто и не поставил я в CKO ресивера (CKO = AT91C_SSC_CKO_DATA_TX ) выводить импульсы только в момент когда трансакции активны. Ну что не так?????? Кто может что дельное подсказать, прошу откликнитесь. Первый раз работаю с SSC, не исключено что что-то упускаю.
  14. Странное замечание. Каналы приема и передачи не зависимы друг от друга, имеют разные регистры и могут по желанию использоваться либо нет. DMA трансфер будет осуществлен только в том случае если соответствующий регистр счетчик (TCR/TNCR или RCR/RNCR) не нулевой и установлен бит присутствия данных в буффере перефирии (TDR/RDR) и естественно если DMA включен. Целиком от вас зависит хотите ли вы трансфер данных осуществлять вручную (записавая данные в TDR/читая из RDR) или возложить всю работу на DMA. В одном из проектов по ходу создании прошивки я начал с передачи и приема - оба вручную по прерываниям (TDRE/RDRF & TMEMPTY). После того как был не удовлетворен этим перевел прием на работу через DMA в то время как передача по прежнему висела на прерывании - вручную записывая новые данные в TDR регистр. Никаких потерь не наблюдалось. Далее и передачу перевел на работу через DMA. Итого во всех трех случаях прием передача были без потерь. Очень вероятно влияние кеширования данных (если оно у вас включено). Либо обратите внимание на скорость работы - может быть у вас скорость передачи данных (частота SPI) граничат со скоростью с которой микроконтроллер способен обработать один трансфер (8-16 бит). Убедитесь что за целый промежуток времени когда у вас пересылаются 10-50к данных не произошла ни разу потеря (OVRES бит в регистре статуса SR должен быть постоянно 0)
  15. Да, именно так пришлось и поступить, назначить общую Interrupt эндпоинт. У меня используется простейшая конфигурация порта - RX & TX, так что по interrupt EP вообще ничего не отсылаю. Я пробовал вообще выбрасывать описание для interrupt EP из дескриптора конфигурации, но тогда системой воспринимался только первый отсылаемый bulk пакет, второй уже не отсылался - система не подтверждала его принятие. Фактически я проверил, если указан один и тот же адрес эндпоинта для двух устройств, то Windows приписывает эту эндпоинт первому устройству. Точно так же пришлось поступить для объединения CDC + CCID ридера - я разместил в дискрипторе конфигурации описание ридера первым а CDC вторым с общей interrupt эндпоинт и соответственно системой воспринимаются пакеты высланные по Interrupt EP как от CCID устройства.