Отладка WCH CH32V317. Есть странности/глюки. Вроде, не фатальные,
но попивают крови. Дублирую тут своё сообщение из группы RISC-V
MCU: WCH CH32V317 и отладка WCH-LinkE с комплектным OpenOCD из MRS 2.5, но среда - Eclipse CDT с GDB (не MRS).
Условия: FreeRTOS, критичный код, когда с большой частотой идут прерывания, передаются уведомления, переключаются задачи. Всё отлажено, всё работает, каждую ассемблерную инструкцию управления задачами FreeRTOS знаю. Не только видел, но могу обосновать зачем она там.
И при всём при этом, как минимум два раза наблюдал такое именно во время отладки, когда подключён отладчик и держится сессия GDB:
а) Происходят сбои - например, прерывание DMA срабатывает дважды подряд после одной транзакции. Или что-то подобное - разобрать сложно - при пошаговой отладке всё работает.
б) При снижении скорости работы периферии, связанной с DMA - работает нормально.
в) Сбои постоянные - возникают на несколько-тысячной транзакции, но каждый раз, после перезапуска, на одной и той же. Если меняю код - меняется и количество транзакций перед сбоем. Но для каждой версии прошивки, во время отладки, момент наступления сбоя - один и тот же, на том же номере транзакции (правда, в описываемом случае, других сигналов на МК вообще не поступало - возможно, нагрузка при обработке внешних возмущений меняла бы картину).
г) Но сбои не вечные. После нескольких перезапусков кода (хоть командой в среде разработки, хоть автоматически изнутри программы) - на третью-четвёртую попытку - удачное завершение обмена (~32МБ данных суммарно по каналам SPI) .
И уже дважды было подобное. Нет, трижды. Просто в давний раз я уже не помню, с чем работал, возможно, с UART. Получается так: всё перепроверяю - всё под контролем, я не дурак. Код, вплоть до ассемблера - чёткий, верный. Ну, думаю, всё, тут я больше ничего не сделаю. Проблема в другом.
И если раньше методом тыка, то теперь просто знаю:
- Нужно перезагрузить МК по питанию (один вариант лечения);
- Нужно остановить отладку (нажать стоп в среде разработки) и перезапустить чип внешним RESET.
В сегодняшнем случае у меня сработал второй вариант, не пришлось даже снимать питания с МК.
Nikolay_Po (Сегодня, 01:37, просмотров: 13)