Как добавление данных в сегмент во флеш-памяти может испортить время работы программы?

Question

У меня есть встроенное приложение реального времени с основным циклом, работающим на частоте 10 кГц. Он работает на TI TMS320C, настроенном для загрузки с флэш-памяти. Недавно я добавил инициализированный массив в исходный файл, и внезапно временные ошибки облажались (слишком сложно, чтобы объяснить это хорошо - по сути, запись в последовательный порт больше не завершается вовремя.)

Вещи, которые меня смущают:

• Я даже не обращаюсь к новым данным , просто объявляю инициализированный массив.
• Это зависит от размера - проблема появляется, только если массив> 40 слов.
• Я знаю, что я не переполняю никакие сегменты данных в карте ссылок.
• Нет кэширования данных, поэтому это не связано с нарушением целостности кэша.

Любые идеи о том, как простое увеличение размера сегмента .cinit во флэш-памяти может повлиять на время вашего кода?

Дополнительная информация:
Я подумал, что, возможно, код переместился, но он хорошо отделен от данных. Я проверил по карте памяти, что все сегменты кода имеют одинаковые адреса до и после ошибки. Я также проверил, что ни один из сегментов не заполнен - ​​единственные адреса, которые меняются на карте, - это несколько в разделе .cinit. Этот раздел содержит значения данных, используемые для инициализации переменных в оперативной памяти (например, мой массив). К нему нельзя обращаться после вызова main ().

Answer 1

Я бы рисковал собой и утверждал, что у вас нет проблем с производительностью, скорее, какое-то повреждение памяти, которое проявляется как проблема с производительностью. Добавление массива в ваш исполняемый файл, изменяющий картину памяти. Таким образом, я предполагаю, что у вас повреждение памяти, которое в основном безвредно (т. Е. Перезапись неиспользуемой части памяти) и смещение вашей памяти более чем на 40 байт приводит к тому, что повреждение памяти создает большую проблему. Какой из реальных вопросов

Answer 2

После более чем одного дня изучения следов и генерации сборки, я думаю, я понял это. Основной причиной проблемы оказалась проблема проектирования, которая вызывала сбои только в том случае, если ISR, который начал запись с последовательного порта, столкнулся с более высоким приоритетом. Как раз выяснилось время, когда потребовалось добавить несколько дополнительных инструкций в один цикл, чтобы два прерывания сошлись.

Таким образом, возникает вопрос: как хранение, а не обращение к дополнительным данным во флэш-памяти приводит к выполнению дополнительных инструкций?

Похоже, что ответ связан, но не совсем, с предложениями Морозного и Фредерико. Новый массив перемещает некоторые существующие переменные, но не за границы страницы или в более медленные регионы (на этой плате время доступа должно быть одинаковым для всех регионов). Но это действительно изменяет смещения некоторых часто используемых структур, что заставляет оптимизатор выдавать немного разные последовательности команд для доступа к ним. Одно выравнивание данных может привести к остановке конвейера за один цикл, а другой - нет. И эти несколько инструкций сместили время достаточно, чтобы раскрыть основную проблему.

Answer 3

Возникает ли проблема, если массив является последним в его блоке адресного пространства? Если нет, просматривая вашу карту, попробуйте переместить объявление массива так, чтобы все, размещенные после него, перетасовывались, чтобы быть перед ним. Таким образом, вы можете точно определить соответствующий объект и начать выяснять, почему его перемещение вызывает задержку.

Answer 4

Возможно, новый статически распределенный массив выталкивает существующие данные в более медленные области памяти, что приводит к замедлению доступа к этим данным?

Answer 5

Мои подозрения могут указывать на изменение выравнивания между вашими данными / кодом и базовым носителем / памятью. Добавление к вашим данным изменит расположение памяти в вашей куче (в зависимости от модели памяти) и может привести к тому, что ваш код выйдет за границу «страницы» на флэш-устройстве, что приведет к задержке, которой раньше не было.

Answer 6

Возможен конфликт между банком или страницей. Возможно, у вас есть две процедуры, которые вызываются довольно часто (обработчики прерываний или около того), которые были на одной странице и теперь разделены на две страницы.

Answer 7

Может ли инициализация перезаписать другой смежный фрагмент кода? Существуют ли какие-либо структуры или переменные, которые используют массив, которые теперь больше и могут вызвать стекопоток?