Lemist

Уважаемые разработчики под 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 Вроде бы директива корректна, да и аргументы у неё взяты не с потолка...

Уважаемые коллеги! Некоторое время занимался другими устройствами. Перед тем, как к ним перейти, прошил несколько свеженьких чистых плат с моим МК. Теперь потребовалось проверить изменения в новой версии. Однако одна из этих плат, которую я взял для проверки, тоже отказалась прошиваться - тем же манером (см. выше). Здесь уже не было никаких переходов - всего одна процедура прошивки. И тем не менее. Кстати, о переходе в режим отладки и отключении DW. После входа в отладку, если он заругался на SPI, пункт меню, позволяющий отключать DW, просто в меню Debug не появляется. Так что воспользоваться этим советомне получается. И самое интересное - сам прибор, его программа продолжает функционировать как ни в чём не бывало! Она воспринимает команды извне, отвечает на них и опрашивает все порты и все прерывания. Кроме сигнатуры... :(

Нет, исключительно HEX. Впрочем, когда наступает эта бодяга, уже неважно - я не попадаю ни в одно нужное окно.

В принципе я бы особо не заморачивался на эту тему, но руководство фирмы заявляет, что во всём виновата программа, которую я прошиваю в МК. Я облазил даташит вдоль и поперёк, но так и не нашёл никаких признаков того, что программа МОЖЕТ как-то повлиять на сам МК. Но этого не объяснишь, да и вообще проблему всё равно надо как-то решать, потому что это ненормально. Но я ведь прав в том, что программа никаким боком не виновата в этой проблеме. И кроме того, непонятно, почему Entering programming mode FAILED. Если я правильно понял, это либо не работает регистр SPMCSR, в который делается запись для программирования Flash-памяти МК (её можно програмировать до 10000 раз, если верить даташиту), либо интерфейc SPI. Но почему???

Кто сталкивался с таким феноменом, подскажите, в чём фишка. Опишу проблему. Я работаю с платой на МК 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 раз становится невозможной - хоть покупай новый МК. :(

Может, я и не о том говорил, но вопрос все равно остается. Как из программы отловить наличие подтверждения от приемника? Опять же никаких упоминаний (битов в регистрах) нет.

Извините, что столь неугомонен, но с обменом по протоколу 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 действительно приходит (или НЕ приходит)? Ведь в последнем случае обмена как раз и не будет.

Да нет, и с английским проблем у меня нет, и упомянутый вами документ имеется, я его вообще-то читал. Впрочем, виноват, видимо, читал невнимательно. Сейчас прошелся по разделу I2C и таки нашел фразу RESTART, которой, очевидно, Master и должен менять направление потока данных.

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

Слова "обмен пошел" не совсем точно отражают состояние дел. Пошщел в одну сторону - master->slave. Может быть, я спрашиваю, как истинный чайник, очевидные вещи, но тем не менее спрошу: как выдать на GPIO последовательность тактовых импульсов с определенной частотой (например, 400 кГц) - это все для BusClear.

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

Может, он и упрощен, но делать то, что указано в комментарии, он обязан (я так полагал). Но он вообще заходит в прерывание один раз, а потом "уходит в подполье", откуда его отладчиком IAR не вытащить. А эта функция BUS CLEAR, она описана в спецификации? Очевидно, имеются в виду внешние - на плате - резисторы, подтягивающие провода SCK и SDA к напряжению питания, то есть к "1"?

Пришлось по необходимости заняться МК 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." Так вот, я запустил этот пример, и он НЕ работает так, как написано в комментарии. В чем может быть дело?

Все оказалось гораздо проще. В исходниках (файл os_cpu_a.asm) в обработчике системного прерывания OS_CPU_PendSVHandler оказалась закомментированной строка CBZ R0, OS_CPU_PendSVHandler_nosave ; Skip register save the first time и программа, естественно, по первому разу улетала далеко-далеко, потому что в первый раз PSP - нуль. Убрал комментарий, и все заработало...

Уважаемые, кто откликнулся! Проблема разрешилась,но совсем другим образом. Я установил новую версию IAR 5.5 и вместо поставленных с программатором драйверов применил те, которые пришли вместе с IAR. И отладка пошла. Все то, о чем мне написали, я тоже увидел - смотрел тщательно, ничего не пропустил, ни RTCK, ни FixedSpeed, пробовал все - но все это не помогало понять сути глюка. Всем спасибо!