alvy

Имеется отладочная плата с TMS320C6A8168 на борту + JTAG emulator (XDS100). Устанавливаю последний CCS v5, создаю проект, пытаюсь залить его в плату, но при создании ccxml файла конфигурации не вижу среди "Board or Device" Cortex-A8 ядра - как мне добавить его поддержку?

Выбираю ОС для TMS320C6A8168 - для ARM ядра (на DSP скорее всего будет SYS/BIOS). Требования - реал тайм, но при этом требуется организовать доступ через Ethernet (telnet'ом, например). У TI есть Network Development Kit, который предоставляет такую функциональность, но семейство Integra не поддерживается. Какие возможные пути решения / альтернативные ОС?

А если при установке CCS передвинуть дату очень сильно вперед, а после установки вернуть назад - триальный период увеличится?

А какая лицензия идет у CCSv5? Тестовая ограниченная по времени или по коду? Есть ли в природе принципиальная схема этой отладочной платы? Если кто таковой располагает, буду очень признателен за нее (можно на почту av[ собака ]nikor.tsk.ru )

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

Доброго времени суток! Разыскивается документацию к TMDXEVM8168 - как минимум интересно глянуть на pdf, как максимум - все содержимое SD карты, идущей в комплекте. Плата идти будет долго, а поизучать документацию хотелось бы пораньше. Заранее огромное спасибо!

DS = DataSheet

Проверить регионы размещения S1L - расписать, где хранится kickstart, где S1L, в каких секторах хранятся настройки S1L, не перезаписываются ли они u-bootником поверх... Когда ковырялся с LPC3250, все проблемы были либо от другого типа используемой NAND/SDRAM, либо от пересечения регионов в NAND

В том то и дело, что в логах ее видно не как данные - появляется отдельная строчка типа Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72] Собственно это и сбило с толку. А поскольку опыта работы на этом уровне Ethernet еще не очень много, то и возникли вопросы )

Извиняюсь, не заметил сразу. С Wireshark'ом работаю всего несколько дней, с ходу не совсем понял, как получить этот самый pcap файл. Как только мне отдадут оборудование постараюсь сделать такой лог. Версия 1.4.4 Только что ответили из Micrel: Так что похоже, что действительно все нормально формируется. Как доберусь до оборудования буду проверять. Все, всем спасибо за правильные вопросы и участие - Wireshark действительно не показывает контрольную сумму, НО почему-то есил ее продублировать, то он ее покажет... В общем, CRC микросхемой формируется, пакеты до программы доходят. Тему можно закрывать.

log.7z Там очередность пакетов такая же: сначала пакеты с неправильной контр. суммой, потом с отсутствующей, потом с правильной.

1. пакет с неправильной CRC32 (должен быть отброшен сетевой картой). KSZ8841 было указано отправить 112 байт, последними 4 байтами отправлена контрольная сумма (Frame check sequence): Frame 1: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3) Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3) Source: OrientPo_01:23:45 (00:13:37:01:23:45) Type: IP (0x0800) Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72] Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001) Data (66 bytes) 0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 0040 40 41 @A 2. пакет с отсутствующей контрольной суммой (так же должен быть отброшен сетевой картой). KSZ8841 было указано отправить 108 байт, бит TXCE Transmit CRC Enable взведен, но контрольной суммы нет: Frame 13: 108 bytes on wire (864 bits), 108 bytes captured (864 bits) Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3) Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3) Source: OrientPo_01:23:45 (00:13:37:01:23:45) Type: IP (0x0800) Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001) Data (66 bytes) 0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 0040 40 41 @A 3. пакет с правильной контрольной суммой (принят и сетевой картой и программой). Все так же как и в первом случае: Frame 14: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3) Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3) Source: OrientPo_01:23:45 (00:13:37:01:23:45) Type: IP (0x0800) Frame check sequence: 0xdee9ac72 [correct] Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100) User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001) Data (66 bytes) 0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./ 0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 0040 40 41 @A Как написано в Wikipedia про Wireshark

Wireshark показывает все пакеты, даже с неправильными контрольными суммами в заголовках и неправильным или отсутствующим совсем CRC32. Сейчас получается: передаю микросхеме общую длину пакета с заголовками, но без CRC32 - до сетевой карты доходит все, но без CRC. Пробовал указывать длину пакета + 4 пустых (0x00) байта под CRC - в таком же нулевом виде они и показываются в Wireshark'е. Такое ощущение, что микросхема вообще игнорирует указанный в первом посте бит. В случае, когда я сам формирую CRC и добавляю ее в конце пакета, сетевая карта принимает пакет и успешно передает его программе на ПК. Понятно, конечно, что в крайнем случае вариант с ручным подсчетом контрольной суммы вполне подходит, но хотелось бы все таки заставить считать ее в KSZ8841. Обратился в службу техподдержи Micrel, но уже полтора дня ответа не приходит.

Имеется KSZ8841-16MVLI. Задача - передать через нее UDP пакет. С самим пакетом проблем нет - заголовки, контрольные суммы в заголовках - все проверено на приемной стороне Wireshark'ом. Проблема возникла с контрольной суммой CRC32, которая следует после данных, в конце пакета. В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется. Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать?

Собрал последнюю версию из CVS (Linux version 2.6.34), ошибок JFFS2 на вскидку меньше стало, но там вообще не конфигурируется eth0 - в стартовом логе есть строчка: ... Creating 5 MTD partitions on "lpc32xx_nand": 0x000000000000-0x000000320000 : "ea3250-boot" 0x000000320000-0x000000fa0000 : "ea3250-uboot" 0x000000fa0000-0x000000fe0000 : "ea3250-ubt-prms" 0x000000fe0000-0x0000013e0000 : "ea3250-kernel" 0x0000013e0000-0x000008000000 : "ea3250-jffs2" eth%d: Invalid ethernet MAC address. Please set using ifconfig lpc_mii_bus: probed ... Как такое победить? Попытки установить MAC адрес вручную с помощью ifconfig не принесли успеха