Jump to content

    

visht

Свой
  • Content Count

    299
  • Joined

  • Last visited

Community Reputation

0 Обычный

About visht

  • Rank
    Местный
  1. Имею аналогичную проблему, но приведенное решение не работает. в наличии пакет lib_usb драйвер который был получен из zadig_2.1.2.exe При попытке установить через ПКМ - "Выбранный Inf-файл не поддерживает этого метода установки" при запуске DPInst64.exe пишет что установил, а по факту - Для устройства не установлены драйверы. (Код 28) притом что сама zadig_2.1.2.exe их успешно устанавливает, но нужно впихнуть их установку в инсталятор. что посоветуете для Windows начиная от XP и до 10 ?
  2. мдя, отключил и все стало вменяемо, была мысль ... но как то вроде условие, должен из очереди все команды убирать в любом случае. Спасибо.
  3. не забыл, и написал об этом... , и потом привел листинг ... Вопрос был не в том как сделать , а в том почему так, И вот на этот вопрос можно ли поподробнее, что же все таки было задумано ... ?
  4. Один и тот же код выполняется с разной скоростью на 2-х разных процессорах. И даже на одном и том же процессоре при выборе разных условий оптимизации. может есть этому научное объяснение, хотелось бы его выслушать. А пока факты: программа выполняет действия: дергает ногой делает задержку (циклом с volatile), дергает ногой выполняет функцию дергает ногой снова задержка дергает ногой выполняет функцию дергает ногой снова задержка дергает ногой измеряются промежутки времени потраченные на задержку между дерганиями для дергания ногой используется Fast метод, соотв бит установлен. вариант 1: уровень оптимизации Level 2, time optimization - off имеем задержки снятые ЛА 70us 195us 250us 96: ESYNC_X; 0x0000B0B4 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0B8 E2200001 EOR R0,R0,#0x00000001 0x0000B0BC E1C403B6 STRH R0,[R4,#0x36] 97: for (i = 0; i < 800; i++); // wait 70 µs 0x0000B0C0 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0C4 E2800001 ADD R0,R0,#0x00000001 0x0000B0C8 E3500E32 CMP R0,#0x00000320 0x0000B0CC 3AFFFFFC BCC 0x0000B0C4 98: ESYNC_X; 0x0000B0D0 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0D4 E2200001 EOR R0,R0,#0x00000001 0x0000B0D8 E1C403B6 STRH R0,[R4,#0x36] 99: write(0x6a); 0x0000B0DC E3A0006A MOV R0,#0x0000006A 0x0000B0E0 EBFFFF91 BL write(0x0000AF2C) 100: ESYNC_X; 0x0000B0E4 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0E8 E2200001 EOR R0,R0,#0x00000001 0x0000B0EC E1C403B6 STRH R0,[R4,#0x36] 101: for (i = 0; i < 1600; i++); // wait 140 µs 0x0000B0F0 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0F4 E2800001 ADD R0,R0,#0x00000001 0x0000B0F8 E3500D19 CMP R0,#0x00000640 0x0000B0FC 3AFFFFFC BCC 0x0000B0F4 102: ESYNC_X; 0x0000B100 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B104 E2200001 EOR R0,R0,#0x00000001 0x0000B108 E1C403B6 STRH R0,[R4,#0x36] 103: write(0x6b); 0x0000B10C E3A0006B MOV R0,#0x0000006B 0x0000B110 EBFFFF85 BL write(0x0000AF2C) 104: ESYNC_X; 0x0000B114 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B118 E2200001 EOR R0,R0,#0x00000001 0x0000B11C E1C403B6 STRH R0,[R4,#0x36] 105: for (i = 0; i < 1800; i++); // wait 250 us 0x0000B120 E59F1094 LDR R1,[PC,#0x0094] // тут 0x708, зуб на холодец 0x0000B124 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B128 E2800001 ADD R0,R0,#0x00000001 0x0000B12C E1500001 CMP R0,R1 0x0000B130 3AFFFFFC BCC 0x0000B128 106: ESYNC_X; 0x0000B134 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B138 E2200001 EOR R0,R0,#0x00000001 0x0000B13C E1C403B6 STRH R0,[R4,#0x36] вариант 2: уровень оптимизации Level 2, time optimization - on имеем задержки снятые ЛА 70us 250us 157us 96: ESYNC_X; 0x0000B0DC E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0E0 E2200001 EOR R0,R0,#0x00000001 0x0000B0E4 E1C403B6 STRH R0,[R4,#0x36] 97: for (i = 0; i < 800; i++); // wait 70 µs 0x0000B0E8 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0EC E2800001 ADD R0,R0,#0x00000001 0x0000B0F0 E3500E32 CMP R0,#0x00000320 0x0000B0F4 3AFFFFFC BCC 0x0000B0EC 98: ESYNC_X; 0x0000B0F8 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0FC E2200001 EOR R0,R0,#0x00000001 0x0000B100 E1C403B6 STRH R0,[R4,#0x36] 99: write(0x6a); 0x0000B104 E3A0006A MOV R0,#0x0000006A 0x0000B108 EBFFFF89 BL write(0x0000AF34) 100: ESYNC_X; 0x0000B10C E1D403B6 LDRH R0,[R4,#0x36] 0x0000B110 E2200001 EOR R0,R0,#0x00000001 0x0000B114 E1C403B6 STRH R0,[R4,#0x36] 101: for (i = 0; i < 1600; i++); // wait 140 µs 0x0000B118 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B11C E2800001 ADD R0,R0,#0x00000001 0x0000B120 E3500D19 CMP R0,#0x00000640 0x0000B124 3AFFFFFC BCC 0x0000B11C 102: ESYNC_X; 0x0000B128 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B12C E2200001 EOR R0,R0,#0x00000001 0x0000B130 E1C403B6 STRH R0,[R4,#0x36] 103: write(0x6b); 0x0000B134 E3A0006B MOV R0,#0x0000006B 0x0000B138 EBFFFF7D BL write(0x0000AF34) 104: ESYNC_X; 0x0000B13C E1D403B6 LDRH R0,[R4,#0x36] 0x0000B140 E2200001 EOR R0,R0,#0x00000001 0x0000B144 E1C403B6 STRH R0,[R4,#0x36] 105: for (i = 0; i < 1800; i++); // wait 250 us 0x0000B148 E3A01FC2 MOV R1,#0x00000308 0x0000B14C E3A00000 MOV R0,#task_io(0x00000000) 0x0000B150 E2811B01 ADD R1,R1,#0x00000400 0x0000B154 E2800001 ADD R0,R0,#0x00000001 0x0000B158 E1500001 CMP R0,R1 0x0000B15C 3AFFFFFC BCC 0x0000B154 106: ESYNC_X; 0x0000B160 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B164 E2200001 EOR R0,R0,#0x00000001 0x0000B168 E1C403B6 STRH R0,[R4,#0x36] и вот смотрю я на листинг, и он одинаковый, и команду те же, а задержка разная, причем первая одинаковая, а вторая увеличивается ... и если сосредоточить внимание только на второй то имеем 195us 0x0000B0F0 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0F4 E2800001 ADD R0,R0,#0x00000001 0x0000B0F8 E3500D19 CMP R0,#0x00000640 0x0000B0FC 3AFFFFFC BCC 0x0000B0F4 250us 0x0000B118 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B11C E2800001 ADD R0,R0,#0x00000001 0x0000B120 E3500D19 CMP R0,#0x00000640 0x0000B124 3AFFFFFC BCC 0x0000B11C как так то ? чем дальше адресация флешь, тем дольще выполнение команды ? Жду ваших мнений. Спасибо.
  5. IAR HID mouse example

    Цитата(Chestor @ Feb 9 2011, 23:10) О неисправности USB сужу исходя из того, что светодиод на USB-порте не загорелся и вообще устройство компом не видится никак. не находиться вообще, или определяется как неизвестное устройство ? в первом случае проверьте правильность управления 1,5 кОм резистором. Вполне возможно что на платах это реализовано по разному. во втором проверьте на тот ли порт (у него их 2) подключен ваш разьем, правильно ли выбраны все PINSELx.
  6. suspend & resume USB LPC23xx

    Цитата(kovigor @ Feb 8 2011, 13:01) Не за что, рад был помочь. Вообще-то, гадать нет смысла. Это должно быть расписано в документации или в эррате. Если не расписано, то нужно пытать техподдержку. Если и она не знает, то варианта два - или обходить эту особенность окольными путями, как это сделали вы, или же искать другой МК, лишенный этой особенности, если это возможно ... у них там так и написано. USB_NEED_CLK is asserted if any of the bits of the USBClkSt register are asserted. а вот что имелось ввиду под словом любой, остается тайной. Техподдержка не отвечает. Запрос отправлял через офф. сайт, а там конкретных email нету, и мучать некого ... а я бы помучал Сегодня пришло письмо, с просьбой подождать еще 5 дней. Тем временем я выяснил, что USB_NEED_CLK все таки сбрасывается, но только при работе в железе. Т.е. если ходить JTAG-ом то в USBClkSt всегда установлен младший бит, и соответственно USB_NEED_CLK всегда 1. А при работе процессора в нормальном режиме, этот бит 0, и все происходит правильно. Однако это не решает проблемы, так как при установки USBWAKE бита просыпания контроллера не происходит. Может нужно самому выключить PLL так как при Power Down она не выключается, может еще что ... пока не выяснил. Но появился новый вопрос в техподдержку, буду продолжать долбить.
  7. suspend & resume USB LPC23xx

    Цитата(kovigor @ Feb 8 2011, 00:01) По той, что я предложил, с просыпанием по первому же SOF, пришедшему по принудительно заведенной на GPIO линии D+ (D-) ? А я эту схему в LPC214x не использовал. Я ее предложил специально вам. На LPC214x все реализуется штатными средствами МК. Я может не так выразился, но в своих изысканиях я вешал на D+ и D- входы USB - сниффера на FPGA. И это не мешало шине отлично работать. Посему я вам и посоветовал быть смелее ... Ну я примерно так и понял. Проверял без буфера, просто ногу паралельно на вход прерывания EINT, все работало. Потом выяснил, что есть возможность просыпаться по той же ноге, но изнутри, и на этом варианте остановился. Так что решение найдено, спасибо за наставления и помощь. PS: USB_NEED_CLK так и не удалось сбросить, проблема видать в том, что USBClkSt = 0x13, т.е. младший бит который Reserved по каким-то внутренним причинам = 1. А сам USB_NEED_CLK видать реализован как лог сложение всех битов USBClkSt. Попытка усыпить контроллер с просыпанием по USB WAKEUP тут же приводит к просыпанию, так как этот бит = 1;
  8. suspend & resume USB LPC23xx

    За обещанный промежуток в 5 рабочих дней техподдрежка NXP так и не ответила. Видимо вопрос не укладывается в стандартные ответы На форуме NXP аналогичная ситуация ... По предложенной методике все получилось. Причем в LPC23xx есть возможность настроить на просыпание GPIO0, что позволило обойтись без внешних повторителей. Кодvoid  suspend(void) {      USBClkCtrl = 0x00;      while ((USBClkSt & 0x12) != 0x00);      INTWAKE = 1u<<7;      IO0_INT_EN_F = 1u<<29;      IO0_INT_CLR = 1<<29;      PCON = 0x06; // Power Down      PLL_init(); } void  resume(void) {      INTWAKE = 0;      USBClkCtrl = 0x12;      while ((USBClkSt & 0x12) != 0x12); } Поиск путей снижения тока потребления привел к следующим изысканиям, может кому то это пригодится: 1. Если USB модуль включен в PCONP, и Power Down происходит не по шине USB, то сам модуль потребляет ~1 мА. При этом, его можно отключить с помощью PINSEL настроив D+ и D- как GPIO. 2. При получении suspend по USB 1мА модулем не потребляется, но можно отключить D+ и D- при этом USB продолжает функционировать и дальше. 3. Сработка прерывания по GPIO0 происходит даже при том, что нога выбрана как USB+. 4. Выключение DEV_CLK и AHB_CLK впринципе не требуется, но логика подсказывает что выключать все таки правильнее. 5. Cигнал USB_POW о наличии подключения USB разьема потребляет 100мкА (подаю через 10к) по понятным причинам 5 В USB и 3.3В контроллера. И вот тут как нельзя кстати подходит предложенный буфер. 6. в Power Down по описанию должна сбрасываться PLL и USB_DIV (в отличие от LPC21xx тут частота береться от основной PLL), но на практике получается что PLL и делитель остаются в настроенном состоянии. Хотя осциллом вижу прекращение генерации на кварце. Вот с 6 пунктом вопрос, то ли я опять чего то гдето не дочитал, то ли глюк чипа, то ли просто мне так везет, но когда нибудь PLL все таки отключиться .. ? И еще вопрос, а что привело к использованию такого рода схемы на LPC124x, ведь там то проблем с USB_NEED_CLK нет ?
  9. suspend & resume USB LPC23xx

    Цитата(kovigor @ Jan 27 2011, 13:33) Ну что я могу сказать ? Заведите линию D+ или D- на вход внешнего прерывания МК, можно через КМОП - повторитель вроде SN74LVC1G07. На 12МБит все должно работать. У меня, во всяком случае, работало и работает. Была такая мысль, но я пока её отгонял. Написал в support и на форум NXP. Подождем результатов, а пока попробую реализовать по вашей схеме.
  10. suspend & resume USB LPC23xx

    Цитата(kovigor @ Jan 27 2011, 13:05) Хорошо. А если не обращать на этот бит внимания, а просто, например, раз в миллисекунду в обработчике любого подходящего прерывания проверять USBDevIntSt.DEV_STAT ? Этот бит укажет вам на "USB suspend change". Дальше подаете команду: Get Device Status (Command: 0xFE, Data: read 1 byte). Она выдаст вам, пропали маркеры на шине или не пропали (см. Table230, описание битов SUS и SUS_CH). Дальше все просто, и usb_needclk оказывается не нужным. Я, правда, так не делал, поэтому ничего не обещаю ... Само прерывание по suspend() работает, с FE попробую, но ... ведь тот же usb_needclk используется для просыпания контроллера, и соответственно он уже не проснется.
  11. suspend & resume USB LPC23xx

    Цитата(kovigor @ Jan 27 2011, 12:17) Вообще, в чем проблема ? В том, что вы не знаете, что на шине пропали маркеры SOF и вы не знаете, когда переходить в Suspend ? в моем случае AP_CLK = 0, т.е. я должен дождаться пока usb_needclk не сброситься, и потом могу убрать тактирование с USB модуля. SOF пропадает, это я вижу на осциллографе, но вот usb_needclk продолжает быть 1. и соответственно дальше ничего не возможно делать. Получается, что я не вижу аппаратно пропадание SOF.
  12. suspend & resume USB LPC23xx

    привожу результаты последних исследований. Цитата*((int*)0xFFE0C008) = 1; после этого ядро USB отваливается, J-LINK показавает в области памяти USB 0xAAAAAAAA т.о. действия описанные в Errata можно расценивать как дезу, ну или все таки оно работает на единственной ревизии "-" найти которую уже не получиться. т.о. имеем проблему с тем, что USB_NEED_CLK никогда не становиться равным 0. похожая проблема поднималась тут и тут и осталась без решения. Кроме предложенного вырианта от NXP, был проверен пакет code.bundle.lpc23xx.lpc24xx.uvision.zip в котором вроде как, suspend и resume обрабатываются. результат не удивил, при suspend происходит зависание на цикле ожидания USB_NEED_CLK; непонятно как это работало у человека, который писал этот код Есть ли у кого из присутсвующих возможность проверить данный код на платах ENG_BOARD_LPC24XX или KEIL_BOARD_LPC23XX или SK-LPC2378 (c мелкими изменениями в инициализации) ? Есть ли адрес службы поддержки NXP (не то что на сайте, а тот с которого отвечают ), или какие другие предложения по поиску решения ?
  13. suspend & resume USB LPC23xx

    Цитата(kovigor @ Jan 21 2011, 00:06) Там надо воздействовать как минимум на регистр PCON. Вот обработчик прерывания, извлеченный из одного из моих проектов для LPC214x. Большое Спасибо, за предоставленный код, основную идею понял, но на LPC23xx все оказалось несколько иначе, возможно я опять все попутал ... Итак имеем бит USB_NEED_CLK который должен сброситься после 2ms как только активность на шине прекратиться. Once USB_NEED_CLK becomes one, it it resets to zero 5 ms after the last packet has been received/sent, or 2 ms after the Suspend Change (SUS_CH) interrupt has occurred. В другом месте говориться о том что состояние биты DEV_CLK_EN и AHB_CLK_EN должны быть 0 0 и только после этого USB_NEED_CLK будет равен нулю. After entering the suspend state with DEV_CLK_EN and AHB_CLK_EN cleared, the DEV_CLK_ON and AHB_CLK_ON will be cleared when the corresponding clock turns off. When both bits are zero, USB_NEED_CLK will be low, indicating that the chip can be put into Power Down mode by writing to the PCON register. На самом деле USB_NEED_CLK всегда 1. Errata утверждает что данная проблема имела место в ревизии -, а у меня B. Но предложенный ими вариант решения проблемы испробовал. After setting the PCUSB bit in PCONP (located at 0xE01F C0C4), write 0x1 to address 0xFFE0C008. The USB_NEED_CLK signal will now function correctly. Writing to address 0xFFE0C008 only needs to be done once after each chip reset. чудо произошло, но не надолго. При таком подходе контроллер абсолютно никак не реагирует на то, чтобы ответить на запрос шины, до дискриптора даже не доходит. Хотя если бродить JTAG-ом то все находиться как нужно, при сбросе контроллера и запуске отладки. Тогда сделал следущее: Код     FIO2DIR = (1<<3); if (!(FIO2PIN & (1<<2))) // кнопка для отладки {     *((int*)0xFFE0C008) = 1;                           // без этого USB_NEED_CLK всегда 1     if (FIO2PIN & (1<<3)) FIO2CLR = (1<<3);  else FIO2SET |= (1<<3);  // проверка входа в режим     USBClkCtrl &= ~0x12;                        // без этого USB_NEED_CLK всегда 1     while ((USBClkSt & 0x12) != 0x00);     while (USB_INT_STAT & 0x00000100);     INTWAKE = 0x20;     PCON = 0x06;     USBClkCtrl = 0x12;                        /* Dev clock, AHB clock enable  */     while ((USBClkSt & 0x12) != 0x12);     INTWAKE = 0x00; } при этом во первых.... Кодif (FIO2PIN & (1<<3)) FIO2CLR = (1<<3);  else FIO2SET |= (1<<3); срабатывает только при отладке JTAG КодPCON = 0x06; - срабатывает всегда (смотрю по потребляемому току), но проснуться контроллер уже не может. Допустим мы пропустим все режимы сна, а просто после запуска и определения устройства остановимся на suspend, выключим а затем включим драйвер, и продолжим выполнение программы. По логике код должен продолжить функционирование как ни в чем не бывало, но проблема остается все в той же форме.
  14. suspend & resume USB LPC23xx

    Решил пойти другим путем. 1. скачал с сайта производителя тут пример AN10759 USB bootloader (LPC23xx) (v.1.0, 2008-10-14) Там контроллер выдает себя за Mass Storage и появляется в винде в виде диска с файлом firmware. 2. Залил его в мой контроллер. И собственно все те же проблемы. Находиться диск, на нем файл, винда не ругается, применяет стандартный драйвер. Но попытка воспроизвести отключение драйвера с последующей активацией вызывает точно такие же проблемы. Сами функции обработки suspend и Resume есть, но они пустые. Собственно как и у меня. Никаких действий с вводом контроллера в спящий режим не производиться. Может в этом и проблема ? Тогда вопрос, как правильно это делать ? В документации на контроллер никаких упоминаний про рекомендуемые действия после suspend и resume я не нашел. Может не там искал, или не так понял...
  15. suspend & resume USB LPC23xx

    Цитата(kovigor @ Jan 17 2011, 23:58) Много раз боролся с этой проблемой на разных МК. Всегда использовал цифровой осиллограф, синхронизировал его по заданному событию и рассматривал момент пробуждения. Вариантов масса. Но чаще всего я так или иначе неправильно формировал временную диаграмму Upstream Resume. насколько я себе думал, то пробуждение возложено на встроенный контроллер, и все диаграммы он должен формировать аппаратно, без участия написанного кода. Пользовательское ПО должно обеспечить снижение энергопотребления. Или я ошибаюсь ? Проблема в том что что-то в модуле USB происходит такое, из за чего он виснет. Но, по этому поводу в даташите никаких намеков. suspend описан только как событие, и никаких рекомендаций или последовательностей действий я не нашел. Errata тоже молчит по этому поводу.