Hz!

В ноуте не работала интегрированная в материнскую плату сетевая карта. Винда писала, что устройство исправно, но при подключении рабочего сетевого кабеля ничего не менялось. Вероятно сгорели порты. В одной мастеркой мне поменяли контроллер (не заработала), во второй сказали, что погорела трансформаторная сборка (в этой модели ипользуется бестрансформаторный Ethernet разъем) и ее надо тоже заменить. Ни e-find ни digi-key ничего не нашли. Может ли кто помочь советом, а еще лучше - делом? Проблема осложняется тем, что мне хватит и одной штуки, а с розницей даже если и найду, мало кто будет связываться ). PS: ноут - hp pavilion dv4-2145dx. карточка на основе Realtek RTL8139/810x Fast Ethernet Adapter. NS681680.pdf

Как ее проверить, если контроллер не определяется, а в железе багов не обнаружено.... ?

Не удается подключиться джитагом к микроконтроллеру на одной из трех плат. Соплей не обнаружено, все компоненты запаяны аналогично двум рабочим. Напряжение питания стабильное. Ни через джитаг, ни через uart достучаться до контроллера не получилось. Единственное что было замечено, что кварц не генерит ничего. Отсюда вопрос: должен ли генерить кварц у непрошитого контроллера (ведь при загрузке он тактируется от внутреннего генератора), и если да, то может ли это говорить, что единственный способ запустить плату - это запаять новый контроллер?

Спасибо.

Спасибо, все собралось. Могли бы вы пояснить откуда взялась эта платформенно зависимая функция?

Не линкуется пример из FreeRTOSV5.4.2. Выдает следующее: arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c App\ParTest.c -o obj\Debug\App\ParTest.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c App\boot.s -o obj\Debug\App\boot.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c App\dynamic.c -o obj\Debug\App\dynamic.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c App\main.c -o obj\Debug\App\main.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\croutine.c -o obj\Debug\FreeRTOS\croutine.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\list.c -o obj\Debug\FreeRTOS\list.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\portable\GCC\ARM7_LPC23xx\port.c -o obj\Debug\FreeRTOS\portable\GCC\ARM7_LPC23xx\port.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\portable\GCC\ARM7_LPC23xx\portISR.c -o obj\Debug\FreeRTOS\portable\GCC\ARM7_LPC23xx\portISR.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\portable\MemMang\heap_2.c -o obj\Debug\FreeRTOS\portable\MemMang\heap_2.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\queue.c -o obj\Debug\FreeRTOS\queue.o arm-elf-gcc.exe -IFreeRTOS\include -IFreeRTOS\portable\GCC\ARM7_LPC23xx -IApp -c FreeRTOS\tasks.c -o obj\Debug\FreeRTOS\tasks.o arm-elf-gcc.exe obj\Debug\App\ParTest.o obj\Debug\App\boot.o obj\Debug\App\dynamic.o obj\Debug\App\main.o obj\Debug\FreeRTOS\croutine.o obj\Debug\FreeRTOS\list.o obj\Debug\FreeRTOS\portable\GCC\ARM7_LPC23xx\port.o obj\Debug\FreeRTOS\portable\GCC\ARM7_LPC23xx\portISR.o obj\Debug\FreeRTOS\portable\MemMang\heap_2.o obj\Debug\FreeRTOS\queue.o obj\Debug\FreeRTOS\tasks.o -o bin\Debug\Base.elf -Wl,-Map=.\obj/Base.map,--cref -T.\lpc2368.ld -nostartfiles x:/progs/yagarto20090817/bin/../lib/gcc/arm-elf/4.4.1/../../../../arm-elf/lib\libc.a(lib_a-freer.o): In function `_malloc_trim_r': C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../newlib-1.17.0/newlib/libc/stdlib/mallocr.c:3326: undefined reference to `_sbrk_r' C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../newlib-1.17.0/newlib/libc/stdlib/mallocr.c:3335: undefined reference to `_sbrk_r' C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../newlib-1.17.0/newlib/libc/stdlib/mallocr.c:3340: undefined reference to `_sbrk_r' x:/progs/yagarto20090817/bin/../lib/gcc/arm-elf/4.4.1/../../../../arm-elf/lib\libc.a(lib_a-mallocr.o): In function `malloc_extend_top': C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../newlib-1.17.0/newlib/libc/stdlib/mallocr.c:2160: undefined reference to `_sbrk_r' C:\msys\1.0\home\yagarto\newlib-build\arm-elf\newlib\libc\stdlib/../../../../../newlib-1.17.0/newlib/libc/stdlib/mallocr.c:2197: undefined reference to `_sbrk_r' collect2: ld returned 1 exit status Process terminated with status 1 (0 minutes, 7 seconds) 5 errors, 0 warnings Подскажите, в чем может быть причина. Прикрепляю проект в Code:Blocks. TOOLS: Binutils-2.19.1 Newlib-1.17.0 GCC-4.4.1 GDB-6.8.50-20080308 Insight-6.8.50-20080308

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

Организовал последовательную запись-чтение во внутренние регистры (не М4блоки), но внутри микросхемы пошивка работает не всегда корректно. Наблюдал отладчиком такую ситуацию, когда при выставлении сигнала разрешения запись (чтение) в регистр не производится. Контроллер считывает неправильную информацию, причем всего регистра, а не одного какого-то бита. Это происходит не постоянно, но довольно часто. Регистры располагаются в трех одинаковых блоках (по 2 в каждом блоке), и уменьшение их количества влияет на частоту появления ошибок. С питанием все нормально. Скачков и просадок нет. Приложенный файл – структура проекта. Cyclone II EP2C8T144C8N K BAB9T0631А ISv102.zip

Запуск установленных Mega Core IP вызывает такую вот ошибку: Путь для установки указал \Quartus II\quartus\libraries\megafunctions. По указанному адресу launcher.jar лежит. Java 1.6. В чем может быть проблема?

Тогда план такой: в стеке резервирую пулы для приема в количестве больше, чем RxDescriptorNumber. При инициализации EMAC выделяю необходимое количество pbuf-ов (== RxDescriptorNumber), настраиваю дескрипторы и жду прихода пакета. Входящий пакет записываю в буферы, потом их склеиваю в один через указатели в структуре pbuf. Выделяю новые буферы и прописываю их адреса в дескрипторах, а принятый пакет передаю в стек. Когда он обработан и становится ненужным, он освобождается стеком, таким образом, восполняется количество свободных pool-ов. Покритикуйте, пожалуйста, такой подход.

т.е. я могу в дескрипторах emac указывать адреса 0х40000000 .. 0x40010000 и он сразу туда будет складировать принимаемые данные, или я неправильно понял? Нашел:

Адаптирую сабжевый стек для работы под uCOS на LPC2387. Проблем с прикручиванием к оси не возникло т.к. примеров хватает. А вот с MAC уровнем сложнее. Нашел проект LwIPWeb, но там прием осуществляется простым копированием данных из Ethernet ram в обычную. В стеке есть возможность использовать POOLы, но нету возможности расположить PBUF_POOL в области Ethernet ram не помещая туда все остальные его части. Второй вариант – использовать при выделении памяти под pbuf опцию PBUF_REF, когда высвобождается память только под саму структуру, а буферы и указатели не них делать самому, но тут возникает куча вопросов по поводу того, как долго выделенные буферы будут использоваться стеком и не приведет ли такой подход к забиванию буфера. Есть третий вариант, это использование пересылки по DMA из Ethernet ram в обычную, это лучше, чем простое копирование, но я склоняюсь к варианту №2, как к более «правильному». Если кто-то делал по-другому, подскажите.

Уточню вопрос: Объясните пожалуйста, какя моя ошибка в первом приведенном фрагменте кода привела к тому, что счетчик начал срабатывать не только на положительные перепады spi_clk, но и в то время, когда входные сигналы остаются неизменными.

Извините, не указал always @ (CS) begin if (CS) begin spi_recv = 0; end else begin spi_recv = 1; end end Я пытался написать счетчик (до 16 со сбросом) принятых/отправленных бит, обнуляющийся при появлении сигнала CS и икрементирующийся по нарастающему фронту сигнала spi_clk.

Пишу модуль SPI. Заткнулся в самом начале. Почему этот код always @ (posedge spi_clk or posedge spi_recv) begin if (spi_recv) begin if (spi_clk) begin if (count >= 16) begin count = 0; spi_new_data = 1; end else begin count = count + 1; spi_new_data = 0; end end else begin count = 0; end end else begin count = 0; end end выдает такую диаграмму ? Такой код работает нормально always @ ( posedge spi_clk) begin if (spi_recv) begin if (count > 15) begin count = 0; spi_new_data = 1; end else begin count = count + 1; spi_new_data = 0; end end else begin count = 0; end end