Comments 7
и ST тут ни при чём, но в документации на тест DSP про это ни слова
Но, почему ни при чём? Eсли это их библиотека для тестирования, и она предполагает, что флаги в регистре будут в состоянии 0000, но сама их в это состояние не переводит, то я бы написал баг-репорт.
Кроме того непонятна необходимость сброса этих флагов в основном коде, а не в коде, который крутится в диагностическом потоке.
Да, согласен, надо было ST указать в документации, что эталон был высчитан на GE==0000.
Дело в том, что это библиотека от ST, с конретным хешем, она с таким хешем и сертификат имеет от TUV. Поэтому менять изменять её код нельзя, иначе автоматически считается, что у неё нет сертификата. Ну и самое главное по договору, мы и не могли никак её менять вообще.
Вся такая диагностика крутится у нас в самой низкоприоритетной задаче, поэтому перед тестом в этой задаче нельзя никак, так как есть риск, что высокоприоритеная с расчтетом вклинится в момент после сброса флага GE и запуском функции диагностики.
Спасибо за разбор, особенно за кусок про то, как ошибка пропадала под отладчиком.
Ваш GE — частный случай очень противной категории: самопроверка молча считает, что стартует с чистого состояния, а состояние ей досталось от предыдущей работы. У меня недавно был тот же по духу случай на несколько этажей выше: обёртка над базой подставляла запрос через JS-замену, где `$$` означает один `$`. Долларовые кавычки схлопывались, запрос не выполнялся, а обёртка отвечала HTTP 200 с телом-ошибкой. Проверка «уже делали это?» читала пустоту и всегда отвечала «нет».
Общее у наших историй в том, что тест проверял свой участок и радовался, а сломан был контракт со слоем, в который никто не заглядывал.
Вопрос по вашему выходу из ситуации: вы в итоге остановились на сбросе GE перед диагностикой или совсем отказались от SIMD в этом месте? Интересно, насколько дорого обошёлся отказ по времени выполнения.
Да, мы совсем отказались от SIMD инструкций в данном случае условно расчет по времени увеличился с 16мс до примерно 40мс, но весь цикл измерения примерно 300мс, поэтому для нас не критично. Зато код стал читабельнее и понятнее. Можно было конечно поменять на Q команды, но к моменту, когда полный разбор произошел уже на С++ функции были переписаны и решили время не тратить.
Под отладчиком она пропадала чисто по случайности, когда включался отладчик, сигнал на плате сенсора чуть чуть становился мьше букавально на какие-то несколько милливольт, но этого хватало, чтбы операция вычитания не высталяла флаг GE.
На обычном коде без DSP-инструкций это были бы
CMP+ ветвление на каждый отсчёт
Строго говоря, и обычными средствами можно обойтись без переходов, используя команду IT, но, понятно дело, в специализированных случаях специализированные средства эффективнее -- команды DSP не просто так ввели.
У ST существует официальный ES0647 — X-CUBE-CLASSB self-test library software errata, где описана буквально эта самая ошибка:
APSR register content is incorrectly assumed to have all GE bits cleared during the test.
И ST прямо пишет, что при GE != 0 функция CPU TMCB способна вернуть STL_FAILED на полностью исправном процессоре. Это классифицировано как false positive.
Не понимаю зачем так мусолить повествование о примитивном баге про который знает любая заштатная модель. Или на подписке экономите?
История одного бага