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

Yurik32

Участник
  • Постов

    8
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный
  1. ну по идее да. Стандартная процедура инициализации. Написана не мной. Лежит вот здесь c:\Keil\ARM\Boards\Atmel\AT91SAM7X-EK\RL\TCPnet\Library\EMAC_SAM7X.c и поставляется вместе с кейлом и его библиотеками. Кусок кода инициализации: void init_ethernet (void) { /* Initialize the EMAC ethernet controller. */ U32 regv,tout,id1,id2; /* Enable Peripheral Clock for EMAC Peripherals */ pPMC->PMC_PCER = (1 << AT91C_ID_PIOB) | (1 << AT91C_ID_EMAC); /* Disable pull up on RXDV => PHY normal mode (not in test mode), */ /* and set MII mode. PHY has internal pull down. */ pPIOB->PIO_PPUDR= AT91C_PIO_PB16 | AT91C_PIO_PB15; /* Clear PB18 <=> PHY powerdown */ pPIOB->PIO_IDR = pPIOB->PIO_PER = pPIOB->PIO_OER = AT91C_PIO_PB18; pPIOB->PIO_CODR = AT91C_PIO_PB18; /* After PHY power up, hardware reset the PHY */ pRSTC->RSTC_RCR = 0xA5000000 | AT91C_RSTC_EXTRST; /* Wait for hardware reset to end. */ while (!(pRSTC->RSTC_RSR & AT91C_RSTC_NRSTL)); /* EMAC IO init for EMAC-PHY communication in MII. */ pPIOB->PIO_IDR = pPIOB->PIO_PPUDR= pPIOB->PIO_PDR = pPIOB->PIO_ASR = AT91C_PB0_ETXCK_EREFCK | AT91C_PB1_ETXEN | AT91C_PB2_ETX0 | AT91C_PB3_ETX1 | AT91C_PB4_ECRS | AT91C_PB5_ERX0 | AT91C_PB6_ERX1 | AT91C_PB7_ERXER | AT91C_PB8_EMDC | AT91C_PB9_EMDIO | AT91C_PB10_ETX2 | AT91C_PB11_ETX3 | AT91C_PB12_ETXER | AT91C_PB13_ERX2 | AT91C_PB14_ERX3 | AT91C_PB15_ERXDV_ECRSDV | AT91C_PB16_ECOL | AT91C_PB17_ERXCK; /* Enable communication between EMAC-PHY. */ enable_MDI (); /* Put the DM9161 in reset mode */ write_PHY (PHY_REG_BMCR, BMCR_RESET); /* Wait for hardware reset to end. */ for (tout = 0; tout < 0x100000; tout++) { regv = read_PHY (PHY_REG_BMCR); if (!(regv & BMCR_RESET)) { /* Reset complete */ break; } } /* Check if this is a DM9161 PHY. */ id1 = read_PHY (PHY_REG_PHYID1); id2 = read_PHY (PHY_REG_PHYID2); if (((id1 << 16) | (id2 & 0xfff0)) == MII_DM9161_ID) { .......... } ....... } Вроде все корректно. На эв.кит. AT91SAM7X-EK все же работает нормально.
  2. AT91sam7x + DM9161AEP соединены по MII. Трансформатор - J00-0061 Есть некоторая плата. Схема, в части езернета, полностью 1 к 1 содрана с евалюейшн кита AT91SAM7X-EK. Разводку PCB мягко говоря сделали не совсем грамотно. Первый запуск: С виду PHY работает полностью корректно. Лампочки адекватно мигают и реагируют на переключение режимов работы 10/100Mbit и Half / full duplex. Нормально работает Auto-MDIX. Форма сигналов тактирования на первый взгляд нормальные. МАС, IP, NetMask, Gateway, DNS присваиваются вручную. DHCP отключен. Пробую пропинговать. Результат - Request timed out. Беру ев.кит AT91SAM7X-EK загружаю туда ту же прошивку. Подключаю к ней тот же езернет кабель. Результат - все работает нормально. Беру отладчик и смотрю как выполняется программа. Ход выполнения программы на обеих платах одинаковый. Создается впечатление что проблема на 99% аппаратная. Заметил такой нюанс. Если все выключить. Немного подождать. Затем снова включить. То все запускается. Пинг и другие сервисы работают, но не долго. Проходит 40-80 секунд и снова пинг пропадает и связи нет. Такой эффект наблюдается только на скорости 10Mbit. На 100Мбит связи нет вообще. ---- Если смотреть осциллографом то от PHY к MAC какие то данные доходят. При этом сигнал RX_DV (RX Data Valid) = 1. RX_ER (RX DataError) всегда в 0. Значит ли это что полученные МАСом данные являются правильными и 100% должны были им обработаться? Ответа от МАСа нет. (Ну кроме тех 40-80 секунд при включении в режиме 10Мбит). Подскажите в чем может быть проблема. Хоть бы как-то на тех 10 мбит этот езернет стабильно запустить.
  3. Оно то так. Но эту плату сделали еще до меня. А мне просто дали и сказали "сделай так штоб она работала" Но все равно спасибо :-)
  4. Ну что ж... тогда придется рожать ёжика :-) Спасибо за ответы.
  5. Доброго времени суток. Столкнулся с такой проблемой. Есть FPGA Spartan 3E (XC3S250E) к которому заведена двухнапрямленая 8 бит шина данных. D0 - P32(GCLK12) D1 - P33(GCLK13) D2 - P34(IO) D3 - P35(GCLK14) D4 - P36(GCLK15) D5 - P38(GCLK0) D6 - P40(GCLK2) D7 - P41(GCLK3) Проект Синтез проходит а вот Implement Design: MAP завершается ошибкой Насколько я понимаю то проблема именно в том, что шина заведена на GCLKn. Google сказал что для Spartan 2 такой тип вывода может работать только на вход (при использовании IBUF). А вот конкретно для XC3S250E такой информации в даташити не нашел. Есть ли какой то нормальный способ организовать двухнапрямленую шину данных в данном случае?
  6. Сегодня пробовал сделать на другом ATMega8535(из другой партии), и эщо на ATMega16. Результат тот же. Получается что проблема все таки программная. Тестировал такой код: #include <MEGA8535.H> void main(void) { unsigned char tmp; #asm ("cli") //Выкл. глоб. прерывания // Input/Output Ports initialization // Port A initialization PORTA=0x00; DDRA=0x00; // Port B initialization PORTB=0x00; DDRB=0b00000111; // Port C initialization PORTC=0x00; DDRC=0xFF; // Port D initialization PORTD=0x00; DDRD=0b11000000; // SPI initialization /* Set MISO output, all others input */ DDRB.6 = 1; //DDR_SPI = (1<<DD_MISO); SPCR=0x00; // Clear the SPI interrupt flag #asm in r30,spsr in r30,spdr #endasm /* Enable SPI */ SPCR |= (1<<SPE); // Global enable interrupts #asm("sei") while (1) { SPDR = 0b11001100; /* Wait for reception complete */ while(!(SPSR & (1<<SPIF))) {}; PORTD.6 = 1; PORTD.6 = 0; tmp = SPDR; if (tmp == 0x81) { PORTD.7 = 1; PORTD.7 = 0; }; }; } чтобы прояснить сложившуюся картину выложу Немного осциллограмм. Ето ЧипСелект и Клок который генерирует Мастер (ARM): Мастер постоянно передает посылку из 2 байт Первый байт (0x81): Второй байт (0x1e): От АВРа получаю: Первый байт: Второй байт: Третий байт: Четвертый байт: Тоесть если ресетнуть АВР то тогда в ответ на первую посылку получу первый и второй байт, на вторую посылку - третий и четвертый байты, на третюю посылку снова получу третий и четвертый байты ну и т.д. Отсюда хорошо видно что третий и четвертый байты ето те которые посилал Мастер. Получается что все возвращается назад к АРМу. Методом научного втыка нашел причину. Виной всему было вот ето: while (1) { SPDR = 0b11001100; /* Wait for reception complete */ После того как убрал, и флаг начал выставляться, и прерывания начало работать. Только теперь появилась новая проблема. Вот исходный код преривания SPI: interrupt [SPI_STC] void spi_isr(void) { unsigned char data; PORTD.6 = 1; data = SPDR; if (data == 0x81) { PORTD.7 = 0; PORTD.7 = 1; PORTD.7 = 0; }; if (data == 0x1e) { PORTD.7 = 0; PORTD.7 = 1; PORTD.7 = 1; PORTD.7 = 1; PORTD.7 = 1; PORTD.7 = 0; }; PORTD.6 = 0; } Мастер постоянно посылает посылку из 2 байт. Первый байт - 0x81. Второй - 0x1e. Тоесть сначала мы должны увидеть узкий импульс на PORTD.7 а потом шырокий. А ето осциллограммы. И с них четко видно что все наоборот. Тоесть в прерывании я получаю байт который физически был принят ещо в момент предыдущей пересылки. Это должно так быть ? Или снова какая то ерунда ?
  7. Убрал. Все сигналы генерируются верно. Смотрел осциллографом. Сделал только на прерывании - не работает, потом переделал только на полинге SPIF - тож не работает. Симптомы те же. Я уж прям не знаю к чему придраться. Начинаю грешить на контроллер. Завтра на другом(ATMega16) попробую сделать.
  8. ATMega8535 SPI Slave Mode trouble

    С одной стороны ARM (SPI Master), с другой ATMega8535L. (Тактируется внутренним RC - 8Мгц) Частота SPI - 1МГц. Проверяю как. Беру отправляю байт с АРМа, и ожидаю каких то импульсов на PORTD.7/ PORTD.6 AVRa. Их конечно же нету. на ARMе получаю первый байт 0b11001100. как и ожидалось. а последующее - тэ которые посылал с АРМа. Тоесть данные возвращаются, что свидетельствует о том что они не были программно принятые в AVRе. Исходний код AVRа (проект в CodeVisionAVR): #include <MEGA8535.H> #include <stdio.h> #include <delay.h> #include "header.h" interrupt [SPI_STC] void spi_isr(void) { unsigned char data; PORTD.6 = 0; PORTD.6 = 1; // Clear the SPI interrupt flag #asm in r30,spsr #endasm data = SPDR; PORTD.6 = 0; } void main(void) { unsigned char tmp; #asm ("cli") //Выкл. глоб. прерывания // Input/Output Ports initialization // Port A initialization PORTA=0x00; DDRA=0x00; // Port B initialization PORTB=0x00; DDRB=0b00000111; // Port C initialization PORTC=0x00; DDRC=0xFF; // Port D initialization PORTD=0x00; DDRD=0b11000000; // SPI initialization /* Set MISO output */ DDRB.6 = 1; //DDR_SPI = (1<<DD_MISO); // SPI initialization // SPI Type: Slave // SPI Clock Phase: Cycle Half // SPI Clock Polarity: Low // SPI Data Order: MSB First // SPCR=0xC0; SPCR=0x80; SPSR=0x00; // Clear the SPI interrupt flag #asm in r30,spsr in r30,spdr #endasm /* Enable SPI */ SPCR |= (1<<SPE); // Global enable interrupts #asm("sei") while (1) { SPDR = 0b11001100; /* Wait for reception complete */ while(!(SPSR & (1<<SPIF))) {}; // <<< --- Такое ощущение, что здесь программа уходит в ступор tmp = SPDR; tmp = SPSR; tmp = tmp & 0b10000000; if (tmp) { PORTD.7 = 0; PORTD.7 = 1; PORTD.7 = 0; } // delay_ms(1000); }; } Что я делаю не так ? Есть какие то идеи ?
×
×
  • Создать...