Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: ошибка в openOCD и в драйверах ftd2xx под linux64
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
klen
обновил исходники openOCD
собрал, запускаю :
Error: couldn't write MPSSE commands to FT2232

подозрительно, все работало еще неделю назад, залазю в git репозиторий посмотреть что недавно правили в драйвере ft2232 - вижу что недавно ничего! а то что правили - давно и несущественно. лезем в код под отладчиком и изумляемся.

CODE
static int ft2232_write(uint8_t* buf, int size, uint32_t* bytes_written)
{
#if BUILD_FT2232_FTD2XX == 1
    FT_STATUS status;
    DWORD dw_bytes_written;
    if ((status = FT_Write(ftdih, buf, size, &dw_bytes_written)) != FT_OK)
    {
        *bytes_written = dw_bytes_written;
        LOG_ERROR("FT_Write returned: %lu", status);
        return ERROR_JTAG_DEVICE_ERROR;
    }
    else
    {
        *bytes_written = dw_bytes_written;
    }
#elif BUILD_FT2232_LIBFTDI == 1
    int retval;
    if ((retval = ftdi_write_data(&ftdic, buf, size)) < 0)
    {
        *bytes_written = 0;
        LOG_ERROR("ftdi_write_data: %s", ftdi_get_error_string(&ftdic));
        return ERROR_JTAG_DEVICE_ERROR;
    }
    else
    {
        *bytes_written = retval;
    }
#endif

    if (*bytes_written != (uint32_t)size)
    {
        return ERROR_JTAG_DEVICE_ERROR;
    }

    return ERROR_OK;
}

стековая переменная dw_bytes_written не инициализируется (атоматически не должна по стандарту) , песатель кода надеется что при вызове FT_Write чтото в нее запишется по любому. Вот тут и начинается события из разрадя ''встретились два барана" - двараза мимо кассы, песатели FT_Write так изготовили что если писать команду без данных, тоесть размер size равен нулю, то она почемуто думает что в dw_bytes_written ничего записывать ненадо - ну так они видят мир в FTDI, простите, в индии. таким образом в результате в пременной dw_bytes_written после операции имеем мусор из стека при входе в эту процедуру с вываливанием в итоге по ERROR_JTAG_DEVICE_ERROR.

контрольный вопрос - как это работало раньше? ответ, ВЕЗЛО - код так распологался в озу и так стеки использовались что в нужном месте всегда оказывался нуль, гдето переписали кусок кода который также временами проходится по стек и по другому его использует и все - ПРЕВЕД!

решение проблемы - инициализация нулем dw_bytes_written = 0 при объявлении.
делаем правку собираем запускаем - вау! заработало!

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

выводы:
а) авторы молодцы - openOCD замечательная вещь, но кодописатели-любители, как работают С.С++ как работают компиллеры не знают, наверно им это не нада, до поры и так все хрустит.
б) песатели драйверов ftdi d2xx под linux64 - уроды, драйверы это ответственная вещь и писать их должны пониающее люди. драйвер для винды возможно работает правильно - если драйвер другие кексы делали.
с) вебадмины forum.sparkfun.com - дятлы.
д) как обычно - пока сам напильником не допилиш - счасть я не будет wink.gif но это наверно норма жизни, мы все разные и хотим разного.

я так изнервничался при регистрации на forum.sparkfun.com что промазал разделом. прошу прощения. просьба к админам переместить топик в соседний раздел GNU/OpenSource средства разработки для avr/arm/mips


засим откланиюсь.
_3m
в репозитарии по состоянию на 8 декабря ошибка не исправлена.
Там еще новые ошибки добавили в ft2232.c и parport.c
Интересно как народ собирает софт с заведомо некомпилируемыми файлами ?
Krom
Я так и не подружился с новыми версиями. Ни с последней из репозитария, ни с 0.4.0. Собирается, отладка идет, а с записью во флеш LPC1768 траблы. Старый скрипт не работает, ругается на команду reset_halt, хотя в мануале такая команда присутствует. Все попытки замены ее чем-либо приводят к неоднозначным результатам - то запишется, то не запишется...
klen
ваще все нафег разломали черти. тоже руками заставляю компилится сначала а потом работать. как JIM вынесли из проекта так с тех пор и поехало. можно конечно помочь "братьям славянам" - код не сложный, но чето времени нету на такое - сами пусть доделывают. я таки надеюсь что чтото умное и мудрое заложили и напильником еще неоппилил. хотя по коммитам кода этого не видно sm.gif сдается козла в капусту пустили. можно логи глянуть кто у них там самый "плодовитый" sm.gif

вчерашнее состояние исходников заставлял собратся. заставил. нехочет читать старые скрипты (для мне они свежие sm.gif) выкинул команды котрые его в тупор приводили. заработал таки. шьет отлаживать можно. Но! через телнет присасываесся - падает! причем тут телнет??? интерференция неиначе. дебажить это сил уже небыло - бросил. изза этого свежак не выложил sad.gif с 0.4.0 теже яйца - подтверждаю, это не релиз это треш sm.gif про косяки в parport охотно верю, я правтда туда не лазюк - искореняю старые технологии.

"..я беременна, это временно.."
поэтому не стоит растраиватся.
_3m
Цитата(klen @ Dec 9 2010, 20:50) *
вчерашнее состояние исходников заставлял собратся. заставил. нехочет читать старые скрипты (для мне они свежие sm.gif) выкинул команды котрые его в тупор приводили. заработал таки. шьет отлаживать можно. Но! через телнет присасываесся - падает! причем тут телнет???

У меня Open On-Chip Debugger 0.5.0-dev-00641-g740b9e2-dirty (2010-12-09-15:33)
Телнет работает. Соединение с GDB через pipe зависает через пару запусков. Работаю через TCP/IP
ОС - 32х битная ubuntu 10.04 под Vmware player.
Krom
Цитата(klen @ Dec 9 2010, 20:50) *
вчерашнее состояние исходников заставлял собратся. заставил. нехочет читать старые скрипты (для мне они свежие sm.gif) выкинул команды котрые его в тупор приводили. заработал таки. шьет отлаживать можно. Но!

И 0.4.0, и самые свежие со старыми скриптами у мну дружить не хотят. ругаются на reset_halt. Eсли вместо reset_halt поставить две последовательные команды reset и halt - отладка запускается, а шить флеш не хочет. В рабочей сборке ocd при прошивке флеши устройство сбрасывается на все время прошивки (видно по очистке индикатора) и перезапускается после загрузки, то в новых версиях со сбросом и остановом творится черт знает что. Может запустится секунд через 5 (как тогда идет прошивка?), или не перезапуститься после загрузки флеш...
Пробовал на разных JTAG - Amontec JTagKey и Olimex ARM-USB-TINY - результат один и тот же.
Сергей Борщ
У меня в устройстве два кристалла в цепочке. Похоже кроме меня этот режим не использует никто, ибо чтобы запустить его пришлось неделю копаться в коде. Слал баг-репорт к 0.4.0 о неправильном формировании карты памяти для gdb в этом случае. Влили в реп. Через пару месяцев сделали аналогичную ж. в другом месте. При возникновении события вызывается правильный скрипт, но выполняется он всегда на первом проце. Потому что проц он определяет из большой структуры "контекст", но почему-то забыли о них, и во всех случаях идет обращение к дефолтному контексту. Точка останова срабатывает на одном ядре, а в gdb отсылаются два пакета - по одному для каждого ядра... Думал патчи послать, так они JIM открутили и оно (судя по списку рассылки) у многих перестало собираться... решил не обновляться пока они сами не разберутся чего хотят.
klen
Цитата(Сергей Борщ @ Dec 10 2010, 17:43) *
... пока они сами не разбирутся чего хотят.

аналогичные ощущения, решил пока использовать крайнюю рабочую версию.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.