Конфликт RAM и SPI Опции

[zheka]

Господа, я понимаю, что причину моей проблемы вы не найдете, но может быть подскажете, как искать ошибку.
А может быть и констатируете, что это не ошибка, а глюк отладчика...

Суть такова. Контроллер STM32F103, в нем включен USART. В обработчике прерывания по приему заполняется буфер, объявленный как uint8_t rx_buffer[50]; Буфер кольцевой.
Работаю с KEIL. Отлаживаю по SWD, в окно watch я добавил rx_buffer. Проблема в чем - в эту переменную, согласно уведомлениям отладчика, периодически в случайные позиции на мгновение вместо 0x00 записывается 0xFF или 0xAA. При этом единственное место в программе, где в эту переменную что-то пишется - это обработка прерывания по приему, я ставил брейкпоинт на эту единственную строку - не срабатывает. Потому как я для чистоты эксперимента вообще отключил источник данных.

Я закомментировал практически всю программу

Код

main()
{
while(1)
  {
    LCD_DrawFill(0,0,30,30,BLACK);
  }

}

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

Я бы обозначил эту проблему, как конфликт SPI и RAM если бы не два "но".

1. В SPI ведется запись еще несколькими функциями, но проблема возникает только в одной из них.
2. Я написал кусок кода, который в цикле проверяет каждый элемент rx_buffer на предмет отличия его от изначального 0x00 и поставил на нем брейкпоинт. Понимая, что проверка и кратковременное изменение буфера могут не совпасть по времени, я запустил программу на ночь, по моим прикидкам буфер должен был быть проверен около 3 миллионов раз. Ни разу програма не засекла вмешательство в буфер.


Похожие глюки, с записыванием данных не в те переменные у меня была как-то, когда я объявил безразмерный массив ( uint8_t XXX[]; ) Но в данном случае ничего такого у меня нет.

Скажите, возможно ли что отладчик брешет?
Как используя средства отдладки KEIL подловить момент записи в переменную и определить кто на нее посягает?

Сообщение отредактировал zheka - Jan 19 2017, 09:59

[jcxz]

Как используя средства отдладки KEIL подловить момент записи в переменную и определить кто на нее посягает?

Насчёт Кейла не скажу, но у Вас же Cortex-M3? В нём есть MPU. Выносите rx_buffer в отдельную секцию памяти, выравниваете ещё положение и размер на 64 байта (например), закрываете к ней доступ по записи через MPU, приоткрывая его временно только в точке записи (в ISR) (на всякий случай запретив прерывания на это время (или назначив прерыванию rx_buffer наивысший приоритет из всех)).
Если в каком-то другом месте будет попытка записи в эту область - сразу получите исключение, проанализируете его источник - найдёте виновника.
Я таким образом не раз решал проблемы со случайными записями в переменные.

Обычно это называют watchpoint, вроде бы. У Кейла это называется data breakpoint. Если настроить всё как надо, отладчик остановится в тот момент, когда процессор попробует записать что-то в указанный диапазон адресов. Он не остановится, если туда полезет DMA, но это не ваш случай, насколько я понял.

Плохой метод. Наличие watchpoint-ов вызывает изменение временной диаграммы работы программы (вызывает резкое её замедление).
Видимо потому, что анализ условия watchpoint выполняется программно в ПО эмулятора (или отладчика?).
Изменение времянки может привести к исчезновению проблемы.
Применение MPU - менее инвазивный метод.

Ещё другой способ:
Запускаете высокочастотное прерывание от любого таймера. Частотой 500-1000кГц (зависит от производительности процессора). Так чтобы оно грузило процессор процентов на 50% или больше.
В ISR сравниваете какие-то части rx_buffer с копией (Ваш ISR, который пишет в rx_buffer, должен дублировать запись и в его копию).
Назначаете приоритет прерывания записи rx_buffer самым высоким, прерывания от таймера - выше других, но ниже прерывания пишущего rx_buffer.
Если при очередной проверке данные не совпали - читаете из стека в какой точке идёт выполнение фоновой программы.
Если обработчик таймера будет коротким (лучше на асм), то сможете обнаружить точку модификации с точностью до примерно десятка команд или меньше.
Но конечно этот метод сильнее влияет на выполнение самой исследуемой программы чем метод с MPU. Да и весь rx_buffer сразу в одном прерывании не проконтролируешь, только 1-2 32-битных слова.

[Obam]

Опередили про MPU…

PM0056 STM32F10xxx Cortex-M3 programming manual:
About the STM32 core peripherals
0xE000ED90-0xE000ED93 MPU type register Reads as zero, indicating no MPU is implemented(1)

Сообщение отредактировал Obam - Jan 19 2017, 10:08

[jcxz]

0xE000ED90-0xE000ED93 MPU type register Reads as zero, indicating no MPU is implemented(1)

Не надо использовать такие МК.

[Obam]

"Кутузов был без глаза. Нет! У Кутузова не было глаза!"

Не надо использовать такие МК.

STM чумовая контора: с rev3 (PM0056) руководства по программированию в CM3 - есть MPU!
Что меня и смутило: как так в L152 - есть, а в F103 вдруг нет?!