Olimex/Startetkit LPC23/4 + RMII KS8721BL, Баги в схеме :( Опции

[zltigo]

Во всех китах Olimex и Starterkit для чипов LPC23xx и LPC24xx ошибка в подключении PHY KS8721BL в RMII Mode. К контроллеру подключен сигнал CRS (Carrier Sense), а не RXDV(CRS_DV - Carrier Sense/Data Valid). Результат плачевен - все фреймы принимаются с якобы битой CRC. Кстати, там по хорошему надо-бы этот сигнальчик к земле подтянуть, а то со встроенной в LPC PU подтяжкой при Reset потенциально могут быть проблемы.

P.S.
Поражает пофигизм разработчиков в обработке ошибок - описанные киты давно уже в продаже, на них написано всяких разных демок-приложений вплоть до Linux, а обрабатывать ошибки , получается не заморачивается никто особо . Уперся в баг, потратил пару дней, просмотрел интернет вдоль и поперек - кроме одного безответного вопроса на LPC2000 форуме - тишина......

[haker_fox]

чевидно

Все заработало. Основная часть демок от Кейла пошла (web-сервера (Java, CGI), ping и т.п.).
Что было сделано:
1. В инициализации EMAC добавлена строка

CODE

MAC_MCFG = MCFG_HCLK_DIV_28;

после этих строк

CODE

  /* Initialize MAC control registers. */
  MAC_MAC1 = MAC1_PASS_ALL;
  MAC_MAC2 = MAC2_CRC_EN | MAC2_PAD_EN;
  MAC_MAXF = ETH_MAX_FLEN;
  MAC_CLRT = CLRT_DEF;
  MAC_IPGR = IPGR_DEF;

2. Естественно, в начале файла есть макрос

CODE

#define MCFG_HCLK_DIV_28      (7 << 2)

Саму инициализацию вообще не трогал (не за исключением добавления указанной строки), не знаю, правильно или нет. Но работает же.
3. По невнимательности для LPC2468 использовал стартовый код LPC2300.s. Заменил на LPC2400.s.
4. Адрес микросхемы PHY не менял, он был уже 0x0100 (1 << 8).
5. Выключил всю отладку сети (файл Net_Debug.c). Это угробляло всю библиотеку TCPnet в моем случае.

Ну и сменил IP на удобный для меня
Все пошло!!!))) Пинг меньше 1 мс. Сервера работают.
Сегодня запустил под осью RTX. Стандартный пример не смог запустить. Сделал свой. Правда пинг 8 - 30 мс. Но это связано с неправильным распределением приоритетов задач. Это я уже выяснил. Буду учиться и исправлять ситуацию.
Вот вроде и все.

Большое человеческое спасибо участникам за помощь!

[zltigo]

1. В инициализации EMAC добавлена строка

CODE

MAC_MCFG = MCFG_HCLK_DIV_28;

после этих строк

CODE

  /* Initialize MAC control registers. */
  MAC_MAC1 = MAC1_PASS_ALL;
  MAC_MAC2 = MAC2_CRC_EN | MAC2_PAD_EN;
  MAC_MAXF = ETH_MAX_FLEN;
  MAC_CLRT = CLRT_DEF;
  MAC_IPGR = IPGR_DEF;

2. Естественно, в начале файла есть макрос

CODE

#define MCFG_HCLK_DIV_28      (7 << 2)

Саму инициализацию вообще не трогал (не за исключением добавления указанной строки), не знаю, правильно или нет. Но работает же.
3. По невнимательности для LPC2468 использовал стартовый код LPC2300.s. Заменил на LPC2400.s.
4. Адрес микросхемы PHY не менял, он был уже 0x0100 (1 << 8).

Да, демописатели . У меня даже для рабочего варианта поиск PHY производится, дабы не думать каждый раз..

CODE

int init_phy(void)
{
    MCFG = MCFG_HCLK_DIV_28|MCFG_RESET_MII_MGMT;
      vSmartDelay_ms( 2 );

#if( EMAC_CFG_RMII == 0 )
    MCOMMAND &= ~CR_RMII;
#else
    MCOMMAND |= CR_RMII;
#if defined __IOLPC2458_H
    SUPP = SUPP_RESET_MII;
#else
    SUPP = 0;                 // Assume and configure RMII link speed logic for 10Mbit
#endif
#endif

    for( int i = 0; i < 7; i++ )
    {    // Check dividers to yield MII frequency ~2.5 MHz
        if( ( (configCPU_CLOCK_HZ/100000L)/mii_dividers[i][0] ) <=  25 )
        {    MCFG = mii_dividers[i][1];        // Remove reset, set proper MIIM divider
            break;
        }
    }
    vSmartDelay_ms( 10 );    // Short delay while PHY exits reset and new divider is set

      for( phy_addr = 1; phy_addr <= 31; phy_addr++ )
      {   // Put PHY in reset mode
        write_PHY( PHY_REG_BMCR, BMCR_RESET );
        // Wait for hardware reset to end
        for( int i = 0; i < 128; i++ )
        {   vSmartDelay_ms( 1 );
            if( !(read_PHY( PHY_REG_BMCR ) & BMCR_RESET) )
            {    // Reset complete
                goto phy_found;
              }
        }
    }
    printst( "PHY:Missing " );
    return( 1 );

phy_found:
    {
    // Check if this is a valid PHY
      ulong id_phy = (read_PHY( PHY_REG_IDR1 )<<16)|read_PHY( PHY_REG_IDR2 );
    if( id_phy == KS8721BL_ID  )
        xprintf( "PHY%2X:KS8721BL ", phy_addr );
    else if( id_phy == KS8041TL_ID  )
        xprintf( "PHY%2X:KS8041TL ", phy_addr );
    else
    {    xprintf( "PHY%2X:%8X -Unknown ", phy_addr, id_phy );
         return( 2 );
    }
    }

      // Sanity check...
...........

[haker_fox]

Да, демописатели . У меня даже для рабочего варианта поиск PHY производится, дабы не думать каждый раз..

Видимо на кейловских платах другой PHY стоит. Вот они жестко под него примеры и заточили.
За исходник - спасибо! Поизучаю!

[sasamy]

За исходник - спасибо! Поизучаю!

Какой-то индусокод. Представьте что адрес не 1 или 2 а 31 - сколько эта херня будет циклы накручивать с задержками ? Лучше нормальные открытые проекты изучайте.

[zltigo]

Какой-то индусокод. Представьте что адрес не 1 или 2 а 31 - сколько эта херня будет циклы накручивать с задержками ?

Если не умеете считать, то порядка 128ms на адрес. Один раз при инициализации. Зато будет найден любой. При необходимости экономить время и использовании 31 адреса все может быть постфактум скорректировано в конкретном рабочем исходнике. Именно такой подход к делу для ДЕМО кода является нормальным в отличии от забивания конкретного адреса, причем без комментариев, что это адрес.

Лучше нормальные открытые проекты изучайте.

Нормальных открытых нет. Один с относительно нормальным уровнем драйвера я уже в этом топике поминал.

[sasamy]

Если не умеете считать, то порядка 128ms на адрес. Один раз при инициализации. Зато будет найден любой. При необходимости экономить время и использовании 31 адреса все может быть постфактум скорректировано в конкретном рабочем исходнике. Именно такой подход к делу для ДЕМО кода является нормальным в отличии от забивания конкретного адреса, причем без комментариев, что это адрес.

Я как раз умею считать - для 31 адреса задержка составит 3 секунды - это нормально по-вашему ? Смысл не в том что вы ищете живой адрес а в том как вы это делаете - можно было в цикле заслать сброс по всем адресам без задержек, а потом опрашивать начианая с первого и если он не ответил, то для следующих задержки уже не нужны. В итоге задержка практически не будет зависеть от адреса а для 31 сократится в 30 (!) раз.

[zltigo]

можно было в цикле заслать сброс по всем адресам без задержек, а потом....

В результате получим много большую задержку для начального ОЖИДАЕМОГО адреса и более замысловатый код и более сложный для правки с целью получить из этого демо рабочий вариант.
Единственно, что, пожалуй следует изменить, это явно дефинировать ожидаемый адрес. Где-то так:

CODE

#define DEFAULT_PHY_ADDR (1)
  
    for( phy_addr = DEFAULT_PHY_ADDR;; )
      {   // Put PHY in reset mode
        write_PHY( PHY_REG_BMCR, BMCR_RESET );
        // Wait for hardware reset to end
        for( int i = 0; i < 128; i++ )
        {   vSmartDelay_ms( 1 );
            if( !(read_PHY( PHY_REG_BMCR ) & BMCR_RESET) )
            {    // Reset complete
                goto phy_found;
              }
        }
        phy_addr = ( phy_addr + 1 ) & 0x1F;
        if( phy_addr == DEFAULT_PHY_ADDR )
                           {    printst( "PHY:Missing " );
                                 return( 1 );
        }
        
    }

Достаточно изменить DEFAULT_PHY_ADDR на желаемый и получаем максимально быстрый рабочий вариант, который тем не менее обеспечит поиск при запуске демки или каких-то монтажных ошибок

[sasamy]

В результате получим много большую задержку для начального ОЖИДАЕМОГО адреса и более замысловатый код и более сложный для правки с целью получить из этого демо рабочий вариант.

Вы о чем вообще ? вот ваш подправленый код

Код

    for (phy_addr = 1; phy_addr <= 31; phy_addr++)
        // Put PHY in reset mode
        write_PHY(PHY_REG_BMCR, BMCR_RESET);

    phy_addr = 1;

    for (int i = 0; i < 128; i++) {  
        if (!(read_PHY( PHY_REG_BMCR ) & BMCR_RESET))
            // Reset complete
            goto phy_found;
        vSmartDelay_ms(1);
    }
    
    for (phy_addr = 2; phy_addr <= 31; phy_addr++) {
        if (!(read_PHY(PHY_REG_BMCR) & BMCR_RESET))
            goto phy_found;
    }
    
    printst("PHY:Missing ");
    return (1);
      
phy_found:

for( phy_addr = DEFAULT_PHY_ADDR;; )

Это вообще цирк - зачем тогда поиск адреса нужен

Сообщение отредактировал sasamy - Jul 5 2011, 20:21

[zltigo]

Вы о чем вообще ?

О том, что написал.

вот ваш подправленый код

Я понял Вашу мысль и достаточно четко на мой взгляд написал, почему меня такая правка НЕ устраивает. Подправленный код тоже привел. Ознакомьтесь для начала.

[sasamy]

О том, что написал.

Я понял Вашу мысль и достаточно четко на мой взгляд написал, почему меня такая правка НЕ устраивает. Подправленный код тоже привел. Ознакомьтесь для начала.

Я немного опоздал с ответом - в общем это очередная индусятина - собственно то что вы ставили во главу сначала (а это перебрать и найти ЛЮБОЙ адрес даже если ошибка в физике) вдруг отошло на второй план и появился костыль который гробит всю идею на корню

[zltigo]

в общем это очередная индусятина

бла, бла, бла....

собственно то что вы ставили во главу сначала (а это перебрать и найти ЛЮБОЙ адрес даже если ошибка в физике) вдруг отошло на второй план

Было и есть на переднем плане. Во главе угла нормально без лишних рассылок ресетов и прочих ЛИШНИХ телодвижений инициализировать PHY. Если вдруг PHY не нашелся на том адресе, на котором должен быть, то тогда искать. Это НЕ штатный режим и время не имеет значения. Значение-же, для той-же демки имеет понятность и минимально-достаточное количество действий при инициализации. Дивная посылка кучи НЕНУЖНЫХ ресетов может в демке разве только сбить с толку читающего и замаскировать ту самую необходимо-достаточную процедуру инициализации PHY. Кстати, о времени, vSmartDelay_ms() это при работающем шедулере и не при вызове из Idle не задержка, а переключение на другую задачу. До кучи у меня нет зависимости от наличия в функции write_PHY() ожидания окончания транзакции. Отсутствие такого ожидания тоже встречалось в халявных демках .

[sasamy]

бла, бла, бла....

Честно говоря - мне нечего добавить. Учить Вас с таким самомнением бесполезно и поздно, тем более что-то доказывать - я даже не расчитывал что вы согласитесь что код у вас говенный

Сообщение отредактировал sasamy - Jul 5 2011, 20:43

[aaarrr]

...даже не расчитывал что вы согласитесь что код у вас говенный

Ваше "исправление" смотрится гораздо более убого "очередной индусятины", ибо не предполагает удобную смену дефолтного адреса, коли уж на то пошло.

[sasamy]

Ваше "исправление" смотрится гораздо более убого "очередной индусятины", ибо не предполагает удобную смену дефолтного адреса, коли уж на то пошло.

Еще один. Для нервнодышащих, вот исходное сообщение
http://electronix.ru/forum/index.php?showt...st&p=947034
покажите мне - какой там дефолтный адрес. Если он так нужен - пожалуйста, смысл ведь не в этом.

Код

#define DEFAULT_PHY_ADDR (1)

    for (phy_addr = 1; phy_addr <= 31; phy_addr++)
        // Put PHY in reset mode
        write_PHY(PHY_REG_BMCR, BMCR_RESET);

    phy_addr = DEFAULT_PHY_ADDR;

    for (int i = 0; i < 128; i++) {  
        if (!(read_PHY( PHY_REG_BMCR ) & BMCR_RESET))
            // Reset complete
            goto phy_found;
        vSmartDelay_ms(1);
    }
    
    for (phy_addr = 1; phy_addr <= 31; phy_addr++) {
        if ((phy_addr != DEFAULT_PHY_ADDR) &&  (!(read_PHY(PHY_REG_BMCR) & BMCR_RESET)))
            goto phy_found;
    }
    
    printst("PHY:Missing ");
    return (1);
      
phy_found:

[zltigo]

....

CODE

    for (phy_addr = 1; phy_addr <= 31; phy_addr++)
        // Put PHY in reset mode
        write_PHY(PHY_REG_BMCR, BMCR_RESET);

1. Нет сброса по 0 адресу.
2. Тратится время на бездумную передачу 30(31) команды сброса по последовательному интерфейсу все зависимости потребуются они в последствии или нет. Соответственно эти пустые действия непонятны для изучающего вольного предположить в их наличии
какой-то смысл.
3. Если в функции write_PHY() нет ожидания окончания транзакции будет облом.

CODE

    for (phy_addr = 1; phy_addr <= 31; phy_addr++) {
        if ((phy_addr != DEFAULT_PHY_ADDR) &&  (!(read_PHY(PHY_REG_BMCR) & BMCR_RESET)))
            goto phy_found;
    }

1. Опять нет контроля по 0 адресу.
2. (phy_addr != DEFAULT_PHY_ADDR) && лишнее украшение.

Собственно исправление автора еще более убого чем начальный вариант - он теряет смысл, потому что весь диапазон адресов не будет проверен.

Как оказалось, чукча не только не "писатель", но и не "читатель" - типа чисто "критик". Диапазон адресов проверяется весь начиная DEFAULT_PHY_ADDR.

[sasamy]

Код

    for (phy_addr = 1; phy_addr <= 31; phy_addr++)
        // Put PHY in reset mode
        write_PHY(PHY_REG_BMCR, BMCR_RESET);

1. Нет сброса по 0 адресу.

Вообще-то это была копипаста с вашего кода, так что претензии не ко мне

2. Тратится время на бездумную передачу 30(31) команды сброса по последовательному интерфейсу все зависимости потребуются они в последствии или нет.

Вы их точно так же делаете, только в некоторых случаях меньше. На этом последовательном интерфейсе 25 МГц, а у вас первая же задержка 1 мс - о чем вообще может быть речь, эти команды пролетят когда она еще не закончится.

3. Если в функции write_PHY() нет ожидания окончания транзакции будет облом.

Пожалуй на этом хватит - это ваш немного исправленый код - к вам претензии, я хотел всего лишь показать смысл моего замечания - тратится слишком много времени на ненужные ожидания, конечно немного в грубоватой форме сказано, но в принципе это был ваш тон.

(phy_addr != DEFAULT_PHY_ADDR) && лишнее украшение.

Ну с этим согласен - прочитать лишний раз регистр - раз плюнуть.

Сообщение отредактировал sasamy - Jul 5 2011, 22:20

[zltigo]

Вообще-то это была копипаста с вашего кода, так что претензии не ко мне

Кто-то взялся править, причем после публикации моего подчищенного, но не сумел.

Вы их точно так же делаете, только в некоторых случаях меньше.

При штатном течении инициализации ровно один необходимо-достаточный сброс вместо 32.

На этом последовательном интерфейсе 25 МГц

Вы не знаете и типичных скоростей MDIO интерфейсов в PHY . Ошибка на порядок.

я хотел всего лишь показать смысл моего замечания - тратится слишком много времени на ненужные ожидания

только в случае НЕШТАТНОЙ ситуации с PHY. Вместо этого Вы добавили те самые ненужные действия требующие времени и для случая штатной инициализации. Затраты времени меня особо не смущают, но порожден еще и тот самый говнокод ( делающий что-то зачем-то ) .

[aaarrr]

что-то зачем-то

Вот заодно и спрошу: зачем сброс? Вопрос без всякой подковырки, просто интересно.

[zltigo]

Вот заодно и спрошу: зачем сброс? Вопрос без всякой подковырки, просто интересно.

Для порядка, дабы функция инициализации всегда делала все возможное включая инициализацию PHY и после софтового сброса контроллера, если нет аппаратного сброса. Но прежде всего это ведь тест на наличие любого PHY - бит должен самосброситься по окончанию инициализации PHY. Другое дело, что время ожидания очистки в 128ms скорее всего великовато, но с другой стороны оно обычно никак не нормируется производителем PHY . Далее еще, после чтения идентификатора, но перед инициализацией, производятся чтения default значений из регистров PHY. Это тоже диагностика PHY. Порядка 10 лет работы в качестве разработчика диагностических комплексов на VEF-е оставили хорошую привычку, в том числе при POST, делать всю диагностику по максимуму.

...достаточно открыть любой даташит.

Открыть, почитать, подумать...., допустить мысль, что кто-то тоже обладает разумом. Только очевидно это не всем дано - лучше сразу писать первое, что придет в голову .