BeagleBone Black зависает

В настоящее время мы разрабатываем приложение для BeagleBone Black (с использованием стандартного дистрибутива Angstrom). Некоторое время (5-10 минут) он работает довольно успешно под GDB (удаленно управляемым Netbeans), но в какой-то относительно случайный момент времени он зависает - светодиоды тактового сигнала перестают мигать, и требуется полная перезагрузка.

Одна из возможностей заключается в том, что это просто количество (USB) устройств, которое вызывает это. Мы связаны последовательным каналом FTDI с моим компьютером для разработки (есть клиентское приложение, которое общается с моим сервером BBB). Существует 4-сторонний концентратор FTDI с несколькими устройствами (в настоящее время 3), еще одно соединение FTDI с другим подключенным оборудованием. Также два устройства I2C. Плюс мышь и клавиатура.

Конечно, у меня нет никаких доказательств, кроме слухов, что проблема связана с USB. Мое программное обеспечение не вызывает никаких сигналов, файл журнала сообщает мне очень немногое. Я запустил приложение системного монитора, чтобы проверить, не происходит ли утечка памяти, но оно работает нормально и стабильно (хотя ЦП действительно подкрадывается). Я хотел бы найти способ разобраться в том, что не удается, и был бы признателен за помощь.


beagleboneblack angstrom-linux
person Julian Gold    schedule 21.11.2014    source источник
comment
Нет обратной связи? Ну что ж, вот граната, которую нужно бросить. Я установил ubuntu на свой ноутбук (+ Netbeans + svn + ...), получил и запустил код, и он прочный, как скала, работает весь день (правда, без I2C). Мы сильно подозреваем стек USB на BBB / Angstrom.   -  person Julian Gold    schedule 26.11.2014

Ответы (2)


arrow_upward
7
arrow_downward

Наконец, дно кроличьей норы:

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/308549

Похоже, что есть проблема в микросхеме TI, в частности, в контроллере прерываний, которая вызывает прерывание "лепет", когда USB становится чрезмерно загруженным. Это вызывает попытку перезагрузки хоста, и приложение, соответственно, умирает. Это объясняет, почему проблема существует как в Angrstrom, так и в Debian - это вообще не проблема стека / драйвера, а проблема с чипом TI. Ой! Из-за этого нам, вероятно, придется отказаться от BBB в качестве нашей платформы.

Вывод последовательной консоли отладки подтверждает, что это так для нашего приложения:

_handle_irq+0x39/0x58)
[  466.343796] [<c0008551>] (omap3_intc_handle_irq+0x39/0x58) from [<c045b95b>]
(__irq_svc+0x3b/0x5c)
[  466.359334] Exception stack(0xd2759cf8 to 0xd2759d40)
[  466.368332] 9ce0:                                                       00000000 c0849ac0
[  466.382735] 9d00: 00000000 00000000 c07a2080 00000000 d2758000 00000002 d2759db0 00000003
[  466.397178] 9d20: c0812610 d2758000 b405025a d2759d40 c0031241 c0030f4e 40000133 ffffffff
[  466.411686] [<c045b95b>] (__irq_svc+0x3b/0x5c) from [<c0030f4e>] (__do_softirq+0x46/0x174)
[  466.426346] [<c0030f4e>] (__do_softirq+0x46/0x174) from [<c0031241>] (irq_exit+0x29/0x50)
[  466.440833] [<c0031241>] (irq_exit+0x29/0x50) from [<c000c8cf>] (handle_IRQ+0x3f/0x5c)
[  466.454864] [<c000c8cf>] (handle_IRQ+0x3f/0x5c) from [<c0008551>]        (omap3_intc_handle_irq+0x39/0x58)
[  466.470777] [<c0008551>] (omap3_intc_handle_irq+0x39/0x58) from [<c045b95b>](__irq_svc+0x3b/0x5c)
[  466.486319] Exception stack(0xd2759db0 to 0xd2759df8)
[  466.495351] 9da0:                                     00000002 00000000 00007d00 00000000
[  466.509782] 9dc0: c07c81d0 c07c81d0 c07c75dc 00007d02 0000007d 00000003 c0812610 de5f4b40
[  466.524147] 9de0: 00000100 d2759df8 c0025b2d c0025bea 00000133 ffffffff
[  466.536019] [<c045b95b>] (__irq_svc+0x3b/0x5c) from [<c0025bea>] (omap3_noncore_dpll_set_rate+0x1f2/0x330)
[  466.553005] [<c0025bea>] (omap3_noncore_dpll_set_rate+0x1f2/0x330) from [<c0383273>]  (clk_change_rate+0x1b/0x52)
[  466.570813] [<c0383273>] (clk_change_rate+0x1b/0x52) from [<c03832fb>] (clk_set_rate+0x51/0x72)
[  466.586199] [<c03832fb>] (clk_set_rate+0x51/0x72) from [<c034ba29>] (cpu0_set_target+0xf9/0x198)
[  466.601754] [<c034ba29>] (cpu0_set_target+0xf9/0x198) from [<c0348c5d>] (__cpufreq_driver_target+0x4d/0x70)
[  466.618890] [<c0348c5d>] (__cpufreq_driver_target+0x4d/0x70) from [<c034b33b>] (dbs_check_cpu+0x123/0x134)
[  466.635897] [<c034b33b>] (dbs_check_cpu+0x123/0x134) from [<c034ad31>] (od_dbs_timer+0x4d/0xb0)
[  466.651283] [<c034ad31>] (od_dbs_timer+0x4d/0xb0) from [<c003c8c5>] (process_one_work+0x1b5/0x2c0)
[  466.667088] [<c003c8c5>] (process_one_work+0x1b5/0x2c0) from [<c003cca3>] (worker_thread+0x19b/0x258)
[  466.683355] [<c003cca3>] (worker_thread+0x19b/0x258) from [<c003fb8f>] (kthread+0x67/0x74)
[  466.698026] [<c003fb8f>] (kthread+0x67/0x74) from [<c000c0dd>] (ret_from_fork+0x11/0x34)
[  466.712148] drm_kms_helper: panic occurred, switching back to text console
[  407.924892] CAUTION: musb: Babble Interrupt Occurred
[  407.965570] CAUTION: musb: Babble Interrupt Occurred
[  408.026994]  gadget: high-speed config #1: Multifunction with RNDIS
[  413.918684] musb_g_ep0_irq 710: SetupEnd came in a wrong ep0stage wait
person Julian Gold    schedule 10.12.2014
comment
Вывод: BBB еще не готов к прайм-тайму. ЗАПРЕЩАЕТСЯ использовать его в качестве промышленного образца. Element14 должен знать о своей проблеме и сидеть дальше. - person RobC; 15.10.2015

arrow_upward
0
arrow_downward

Таким образом, похоже, что подключение мыши к концентратору USB и закрепление ее на BBB может вызвать эту проблему, если на концентраторе есть другие устройства, выполняющие ввод-вывод. Коллега сообщил мне, что на Raspberry Pi тоже есть проблемы с такими вещами. После отключения мыши программа работала более часа без зависаний. Подключив обратно, примерно через 10 минут произошло зависание. Снял мышь, снова запустил, и уже полчаса снова без проблем.

person Julian Gold    schedule 27.11.2014
comment
Слишком хорошо, чтобы быть правдой. По-прежнему зависает, просто занимает в среднем немного больше времени. Вздох. - person Julian Gold; 28.11.2014