Jump to content

    

Lemist

Участник
  • Content Count

    27
  • Joined

  • Last visited

Everything posted by Lemist


  1. Уважаемые разработчики под IAR AVR32! При компиляции (которая проходит по норме) и линковании проекта (в проекте пока отсутствуют обращения к аппаратной части, то есть процессорным регистрам и т.п., только закодированный алгоритм) вываливается сообщение линкера Internal Error: [CoreUtil/General]: Access violation (0xc0000005) at 0066BB69 (reading from address 0x39) и естественно линкование сваливается, причём не формируется ни испольняемый файл, ни карта памяти - вообще папка Exe остаётся девственно пустой. Поскольку сам исходный код ранее компилировался и линковался (в других системах) без проблем, есть подозрения, что это глюк самого IAR AVR32. А может, дело в настройках? Впрочем, прошу прощения, виноват. Ошибка вываливается тогда, когда в код добавляется подпрограмма-обработчик какого-либо прерывания ( с включением директивы #pragma handler=AVR32_EIC_IRQ_GROUP,0 Вроде бы директива корректна, да и аргументы у неё взяты не с потолка...
  2. Кто сталкивался с таким феноменом, подскажите, в чём фишка. Опишу проблему. Я работаю с платой на МК ATmega88PA и прошиваю её программатором JTAGICE mkII с помощью AVR Studio. При обычной прошивке для этого в AVR Studio я использую кнопку "Connect to the Selected AVR Programmer", программатор подключается через USB. Если после обычной прошивки потребовалось перейти на отладочную, AVR Studio нужно разрешить debugWire через SPI. А для запрета debugWire нужно в одном из пунктов меню Debug (...JTAGICE mkII) запретить debugWire. Это известно. А теперь сама ситуация. Через несколько раз (большой статистики не набирал, но где-то после 10-12 раз) перестаёт читаться сигнатура, фьюзы - на любую попытку обратиться к МК AVR Studio ругается, вываливая окошко "ISP Mode Error, а в нижней статус-панельке появляется строка "Entering programming mode.. FAILED". Если попробовать перейти на отладочную прошивку, то после подтверждения "Use SPI to enable debugWire interface" AVR studio не может этого сделать и ругается "Failed to enter SPI mode". И во всех случаях AVR studio рекомендует проверить кабели. Проблема нешуточная - перепрошивка платы после 10 раз становится невозможной - хоть покупай новый МК.
  3. Уважаемые коллеги! Некоторое время занимался другими устройствами. Перед тем, как к ним перейти, прошил несколько свеженьких чистых плат с моим МК. Теперь потребовалось проверить изменения в новой версии. Однако одна из этих плат, которую я взял для проверки, тоже отказалась прошиваться - тем же манером (см. выше). Здесь уже не было никаких переходов - всего одна процедура прошивки. И тем не менее. Кстати, о переходе в режим отладки и отключении DW. После входа в отладку, если он заругался на SPI, пункт меню, позволяющий отключать DW, просто в меню Debug не появляется. Так что воспользоваться этим советомне получается. И самое интересное - сам прибор, его программа продолжает функционировать как ни в чём не бывало! Она воспринимает команды извне, отвечает на них и опрашивает все порты и все прерывания. Кроме сигнатуры...
  4. Цитата(OlegPowerC @ Jun 17 2011, 14:43) А вы elf файлами не пользуетесь случаем? Нет, исключительно HEX. Впрочем, когда наступает эта бодяга, уже неважно - я не попадаю ни в одно нужное окно.
  5. В принципе я бы особо не заморачивался на эту тему, но руководство фирмы заявляет, что во всём виновата программа, которую я прошиваю в МК. Я облазил даташит вдоль и поперёк, но так и не нашёл никаких признаков того, что программа МОЖЕТ как-то повлиять на сам МК. Но этого не объяснишь, да и вообще проблему всё равно надо как-то решать, потому что это ненормально. Но я ведь прав в том, что программа никаким боком не виновата в этой проблеме. И кроме того, непонятно, почему Entering programming mode FAILED. Если я правильно понял, это либо не работает регистр SPMCSR, в который делается запись для программирования Flash-памяти МК (её можно програмировать до 10000 раз, если верить даташиту), либо интерфейc SPI. Но почему???
  6. Пришлось по необходимости заняться МК MSP430F2617. К счастью, для чайников в среде IAR есть примеры. Все примеры удалось запустить и отработать, кроме примера по I2C, хотя он там нужен. Привожу код в примере #include "msp430x26x.h" unsigned char TXData; unsigned char TXByteCtr; void main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop WDT P3SEL |= 0x06; // Assign I2C pins to USCI_B0 UCB0CTL1 |= UCSWRST; // Enable SW reset UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC; // I2C Master, synchronous mode UCB0CTL1 = UCSSEL_2 + UCSWRST; // Use SMCLK, keep SW reset UCB0BR0 = 12; // fSCL = SMCLK/12 = ~100kHz UCB0BR1 = 0; UCB0I2CSA = 0x48; // Slave Address is 048h UCB0CTL1 &= ~UCSWRST; // Clear SW reset, resume operation IE2 |= UCB0TXIE; // Enable TX interrupt TXData = 0x01; // Holds TX data while (1) { TXByteCtr = 1; // Load TX byte counter while (UCB0CTL1 & UCTXSTP); // Ensure stop condition got sent UCB0CTL1 |= UCTR + UCTXSTT; // I2C TX, start condition __bis_SR_register(CPUOFF + GIE); // Enter LPM0 w/ interrupts // Remain in LPM0 until all data // is TX'd TXData++; // Increment data byte } } //------------------------------------------------------------------------------ // The USCIAB0TX_ISR is structured such that it can be used to transmit any // number of bytes by pre-loading TXByteCtr with the byte count. //------------------------------------------------------------------------------ #pragma vector = USCIAB0TX_VECTOR __interrupt void USCIAB0TX_ISR(void) { if (TXByteCtr) // Check TX byte counter { UCB0TXBUF = TXData; // Load TX buffer TXByteCtr--; // Decrement TX byte counter } else { UCB0CTL1 |= UCTXSTP; // I2C stop condition IFG2 &= ~UCB0TXIFG; // Clear USCI_B0 TX int flag __bic_SR_register_on_exit(CPUOFF); // Exit LPM0 } } В комментарии указано: "Этот демо связывает два MSP430 по шине I2C. Мaster передает slave. Это код для master. Он постоянно передает 00h, 01h, ..., 0ffh и демонстрирует, как подключить I2C master transmitter для передачи одного байта using прерывание USCI_B0 TX." Так вот, я запустил этот пример, и он НЕ работает так, как написано в комментарии. В чем может быть дело?
  7. Проблема с I2C в MSP430F2617

    Цитата(rezident @ Oct 8 2010, 15:06) Уважаемый, если предположить, что у вас плохое зрение, то вы видимо забыли надеть очки? Ну причем тут модуль USI (Universal Serial Interface) и соответствующий ему раздел в User's manual (Chapter 14), если в вашем кристалле модуль USCI (Universal Serial Communication Interface) и читать вам следует раздел Chapter 17. Universal Serial Communication Interface, I2C Mode? Может, я и не о том говорил, но вопрос все равно остается. Как из программы отловить наличие подтверждения от приемника? Опять же никаких упоминаний (битов в регистрах) нет.
  8. Проблема с I2C в MSP430F2617

    Извините, что столь неугомонен, но с обменом по протоколу I2C все-таки не все ладно. У меня возникло подозрение, что slave (а в качестве такового в обмене участвует акселерометр LIS331DLH) не отвечает, не дает подтверждение, необходимое по протоколу. Судя по примерам, вся последовательность обмена: Start - Slave Address - R/W - ACK - Data - ACK - S Slave Address - R/W - ACK - Data - ACK - Stop недоступна для программы - значит, существует "нижний" уровень типа микропрограммного, реализцющий собственно обмен. Об этом, кстати, свидетельствует и то, что в упомянутой Вами книге есть раздел "Universal Serial Interface", и регистры этого раздела (например, USICTLx или USICNT etc), однако из программы ни один из этих регистров недоступен, хотя в самой книге есть Ассемблерные примеры управления через эти регистры. Как все-таки убедиться, что подтверждение со стороны приемника slave действительно приходит (или НЕ приходит)? Ведь в последнем случае обмена как раз и не будет.
  9. Проблема с I2C в MSP430F2617

    Цитата(rezident @ Oct 7 2010, 19:29) Как говориться в таких случаях RTFM! Ответы на все эти вопросы есть в MSP430x2xx Family User's Guide (Rev. E), чтением которого вы видимо пренебрегли? Если у вас проблемы с английским, то купите книжку-перевод этого руководства. В соседней теме ее рекламировали. Да нет, и с английским проблем у меня нет, и упомянутый вами документ имеется, я его вообще-то читал. Впрочем, виноват, видимо, читал невнимательно. Сейчас прошелся по разделу I2C и таки нашел фразу RESTART, которой, очевидно, Master и должен менять направление потока данных.
  10. Проблема с I2C в MSP430F2617

    Спасибо за код, должен сказать, что ничего военного в нем нет, и все достаточно прозрачно. Впрочем, из примеров я сделал несколько выводов. Во-первых, получается, что сам обмен включает, кроме передаваемых байтов, еще много чего (очевидно, все это организует встроенный в микроконтроллер модуль, реализующий скрытые функции I2C). Например, в примерах (и, надо полагать, в реальных программах) нет передачи адреса - в лучшем случае он указывается в специальных регистрах при настройках протокола. А кто его тогда передает? Нет там и "обрамления" передаваемых байтов (например, в адресной посылке, кроме самого 7-битного адреса, должен быть так называемый R/W бит, определяющий направление потока данных, а в обычной посылке 8 бит данных дополняются битом подтверждения). Их тоже наверняка формирует встроенный модуль. Здесь для меня из примеров теперь непонятно следующее: я там нигде не нашел и намека на определение направления потока данных (то есть каким образом будет формироваться этот самый R/W бит). А это может быть определяющим для программирования обмена. Например, в процессе работы с каким-либо устройством нужно запросить состояние определенного регистра. Для этого нужно послать запрос (ПЕРЕДАЧА) и перейти на прием. Это как-то нужно сделать программно. Вот такие вопросы.
  11. Проблема с I2C в MSP430F2617

    Цитата(Lemist @ Oct 6 2010, 19:26) Гм, все оказалось донельзя тривиально. Как только прицепили к SCK и SDA подтягивающие резисторы, обмен пошел. Есть, правда, некоторые шероховатости, но это уже отдельная тема. Спасибо за подсказку и дополнительные советы. Обязательно учтем. Слова "обмен пошел" не совсем точно отражают состояние дел. Пошщел в одну сторону - master->slave. Может быть, я спрашиваю, как истинный чайник, очевидные вещи, но тем не менее спрошу: как выдать на GPIO последовательность тактовых импульсов с определенной частотой (например, 400 кГц) - это все для BusClear.
  12. Проблема с I2C в MSP430F2617

    Гм, все оказалось донельзя тривиально. Как только прицепили к SCK и SDA подтягивающие резисторы, обмен пошел. Есть, правда, некоторые шероховатости, но это уже отдельная тема. Спасибо за подсказку и дополнительные советы. Обязательно учтем.
  13. Проблема с I2C в MSP430F2617

    Цитата(rezident @ Oct 6 2010, 16:22) Во-первых, нужно напомнить, что шина I2C обязательно требует pull-up резисторов на обеих линиях (SCL и SDA). Во-вторых, этот пример слишком упрощен. Автомат состояний шины I2C гораздо сложнее и в идеале его нужно реализовывать полностью (назначить действие для каждого возможного варианта состояния шины). В-третьих, нужно обязательно реализовать функцию Bus clear, описанную в спецификации I2C, вызываемую по тайм-ауту неактивности занятой шины. С такой необходимостью мы сталкивались неоднократно и поэтому реализуем ее всегда. Как минимум один раз, после подачи питания на устройства, подключенные к шине I2C, функцию Bus clear необходимо вызывать всегда. Может, он и упрощен, но делать то, что указано в комментарии, он обязан (я так полагал). Но он вообще заходит в прерывание один раз, а потом "уходит в подполье", откуда его отладчиком IAR не вытащить. А эта функция BUS CLEAR, она описана в спецификации? Очевидно, имеются в виду внешние - на плате - резисторы, подтягивающие провода SCK и SDA к напряжению питания, то есть к "1"?
  14. Портирование uCOS под LPC1758

    Все оказалось гораздо проще. В исходниках (файл os_cpu_a.asm) в обработчике системного прерывания OS_CPU_PendSVHandler оказалась закомментированной строка CBZ R0, OS_CPU_PendSVHandler_nosave ; Skip register save the first time и программа, естественно, по первому разу улетала далеко-далеко, потому что в первый раз PSP - нуль. Убрал комментарий, и все заработало...
  15. Попробовал я соорудить тестовую задачу под управлением uC-OS II. Сварганил такой небольшой проект под LPC1758, прицепил к нему программатор J-Link и все это в среде EWARM 5.5 откомпилил. ВСе откомплилось, слинковалось и даже залилось в микроконтроллер. Все хорошо, но после отработки OSStart() все это уходит в подполье и задача TaskKBD никак себя не проявляет. Похоже, ОС в нее не входит и вообще контекст не переключает. Может я что-то не учел? Что-то очень важное... Посмотрите проект плиз. [attachment=44244:Test_OS.zip]
  16. Уважаемые, кто откликнулся! Проблема разрешилась,но совсем другим образом. Я установил новую версию IAR 5.5 и вместо поставленных с программатором драйверов применил те, которые пришли вместе с IAR. И отладка пошла. Все то, о чем мне написали, я тоже увидел - смотрел тщательно, ничего не пропустил, ни RTCK, ни FixedSpeed, пробовал все - но все это не помогало понять сути глюка. Всем спасибо!
  17. Не могу запустить отладку программы под управлением программатора J-Link в среде IAR. Отлаживаемая программа должна располагаться в микроконтроллере LPC1758 с ядром Cortex-M3. После запуска среды IAR и установки необходимых опций проекта в соответствии с документацией на J-Link сеанс отладки я начинаю с того, что после компиляции нажимаю кнопку "Download and Debug". При этом IAR записывает программу с помощью J-Link flash download в микроконтроллер - судя по всему, заливка программы проходит нормально. Однако потом выдается сообщение Failed to measure CPU clock frequency с тремя кнопками внизу (Прервать, Повтор и Пропустить). Нажимаю Прервать - J-Link flash download остается в памяти, и его приходится снимать через Диспетчер задач. Нажимаю Повтор или Пропустить - сообщение повторяется еще раз (J-Link flash download удаляется из памяти), после чего вроде бы IAR начинает сеанс отладки (устанавливает курсор на первую строчку ассемблерного кода). А затем при нажатии любой отладочной кнопки забивается стек и программа зависает. Может, я где-то что-то не учел? Поиски в help-системе IAR тоже ничего конкретного не дали.
  18. Портирование uCOS под LPC1758

    Цитата(andrewlekar @ May 21 2010, 09:02) Стеки IDLE и STAT не маловаты? Кто знает, может, конечно, и 128 байтов мало, но это ведь сам автор Jean J. Labrosse такие размеры установил, вряд ли всем, кто работает с uC/OS-II, пришлось эти размеры менять - по крайней мере, где-нибудь сведения о таком бы сохранились. Думаю, что не может быть дело в этом.
  19. После того, как я поставил новую, последнюю версию EWARM 5.5 и вместо пришедших с программатором драйверов подключил драйвера из инсталляции EWARM, J-Link спокойно соединился и работает. Позор Segger!
  20. Портирование uCOS под CrossWorks

    Все то, о чем я писал ранее, относилось к CrossWorks 1.7. После инсталляции CrossWorks 2.0 (версия evaluation) вся эта масса сообщений перешла в категорию warnings, но линкование так и не состоялось - вывалились две ошибки линковщика о неопределенных символах __stack_process_start__ и __stack_process_end__. Очевидно,их нужно куда-нибудь добавить и сформировать стек процесса. Но меня беспокоит не это, а вся эта масса - то, что они стали warnings, вовсе не уменьшило их потенциальной опасности. Так что CrossWorks для меня потеряно...
  21. Кто-нибудь портировал uCOS под CrossWorks? Если да, подскажите, как в этой среде сделать, чтобы CrossWorks понимала PRIMASK, PSP и другие специальные регистры. И вообще, откуда взялись ошибки типа STM R0, {R4-R11} Io register required LDM R0, {R4-R11} Io register required POP {R14} unvalid register list to push/pop instruction (при этом команда PUSH {R14} прошла без вопросов) ORR LR, LR, #0x04 unshifted register required Ассемблерные команды вроде бы правильные, соответствуют архитектуре Cortex, но... Отзовитесь, плиз. Пожалуйста, не удаляйте эту тему.
  22. Портирование uCOS под CrossWorks

    Просмотрев help на CrossWorks, я вызвал в UltraEdit файл flash_placement.xml и добавил в него строку: <ProgramSection alignment="4" load="Yes" inputsections="*(.code .code.*)" name=".code"/> После этого линковщик перестал выдавать сообщение "region UNPLACED_SECTIONS is full", но остальные ошибки с предупреждением dangerous error остались. Все они одного вида - first occurrence: THUMB Flash Debug/os_cpu_c.o: thumb call to arm. И касаются они как правило двух вещей в этих модулях - OS_ENTER_CRITICAL(); и OS_EXIT_CRITICAL(); - это запрещение и разрешение прерываний - и идут попарно. Что линковщику нужно?
  23. Портирование uCOS под CrossWorks

    Цитата(bseyur @ May 11 2010, 18:56) А вы не пробовали вообще не указывать директивы вроде code16 или code32? Cortex - то ведь thumb-only процессор, у него один-единственный набор команд, следовательно и необходимость подобных директив отпадает. В даташите на процессор под ARM-инструкциями для LPC17xx понимаются существующие 32-разрядные инструкции, но на самом деле они лежат в одном наборе с 16-разрядными под общим названием Thumb-2 и не требуют особого объявления. Есть, конечно, такие команды как LDR.N (16 бит) и LDR.W (32 бит), но это уже, скорее, тема для иного разговора, если интересно, можете почитать о них в документации. Если не указывать никакой директивы "вроде code16 или code32", эффект тот же, как и при указании code16 - ассемблерный файл компилится, а потом при линковании выпадают все те сообщения, что упомянуты у меня в предыдущей реплике: C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 1.7/gcc/bin/ld: region UNPLACED_SECTIONS is full (THUMB Flash Debug/LPC1756_Test.elf section .code) Что это за region UNPLACED_SECTIONS и чем это он забит? Ведь в компилируемом ассемблерном файле четко указано .section .code, "ax" то есть это именованная секция.
  24. Портирование uCOS под CrossWorks

    И главная проблема в компиляции проектов под CrossWorks, так и осталась за кадром. Дело вот в чем: если при настройке под синтаксис CrossWorks указать директиву .code 32 то CrossWorks просто весь последующий код понимает как набор ARM-инструкций и на каждую строку ругается примерно так: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bx LR' А если указать директиву .code 16 выдается сообщение другого вида: C:/Program Files/Rowley Associates Limited/CrossWorks for ARM 1.7/gcc/bin/ld: region UNPLACED_SECTIONS is full (THUMB Flash Debug/LPC1756_Test.elf section .code) В то же время в datasheet на Cortex (конкретно это микроконтроллер LPC1758) нет никаких указаний, что ARM-инструкции запрещены - они там расписаны, как положено. Впечатление такое, что в CrossWorks где-то есть фича, которую можно установить, и CrossWorks будет все понимать. Но я пока такую фичу НЕ НАШЕЛ. А пока она не установлена, ARM-инструкции для CrossWorks останутся persona non grata, хотя это неправильно. Есть ли выход из этой ситуации?
  25. Портирование uCOS под CrossWorks

    Цитата(igorsk @ May 1 2010, 00:37) Тут смотрел? Упоминается конкретно M3. Это сайт Micrium, там по указанной ссылке так просто не попасть - предлагают зарегистрироваться. Все бы ничего, но в процедуре регистрации имеется комбо со списком Target Processor. Так вот, в этом списке НЕТ Cortex, а где же он тогда по этой ссылке упоминается конкретно? Я просто наверняка не пройду регистрацию, потому что не нашел там Cortex. Может, плохо смотрел (хотя два раза и внимательно)?