Микропроцессор Coldfire MCF5272 USB-модуль прекращает прерывание
Это проблема, которую я пытаюсь решить годами, периодически тратя на это 1-2 месяца.
Я использую Metrowerks IDE и компилятор ColdFire C MCFCCompiler версии 4.0 для создания встроенного кода, который использует USB-модуль для связи с хостом. Продукт с этим оборудованием выпущен уже восемь лет и довольно успешен. Тем не менее, в течение этих лет мы получали жалобы с мест, что иногда связь с хостом прерывается и операция не восстанавливается.
Я выследил ошибку, используя USB-сниффер и отладочное оборудование Coldfire, и это условие и сценарий, в котором я нахожу код.
Обрыв связи происходит на стороне прошивки, а не драйвера на хосте.
Зависание происходит только при отправке команд микропрограммы USB с хоста (windows 7) в режиме быстрой активации из нескольких потоков. Каждая команда прошивки отвечает обратно на хост. Таким образом, есть максимальный трафик через порт USB.
Я использую реализацию, предоставленную Motorola, которая хорошо документирована в USB-STAND-ALONE-DRIVER_V03.pdf (Google найдет ее для вас). В моей точке фокуса есть две функции, и они должны хорошо играть вместе: usb_in_service (вызывается обработчиком прерываний) и usb_tx_data (который инициирует передачу, которая в какой-то момент сгенерирует прерывание).
Функция usb_tx_data реализована так, что она выручает, если у USB fifo все еще есть данные для отправки на хост. Но ожидание того, чтобы очистить fifo, переводит код в бесконечный цикл.
После этого больше не происходит прерывание, хотя содержимое регистров USB-модуля говорит мне, что прерывания включены.
Я проверил, что USB-модуль не получил событие сброса и не приостановлен.
Основной вопрос заключается в том, связана ли ошибка в оборудовании USB-модуля или в коде. Я не нахожу никаких ошибок, указывающих на эту проблему. Если это код, то где в нем целое, что логика не учитывает?
По горячим следам, потому что мы создаем новую линейку продуктов на основе этой же прошивки, и я не могу выпустить ее, пока это не будет решено.