Перейти к содержанию
    

Странное поведение дисплея

Отключил SDRAM совсем, поотключал периферию - дрейф данных остается все равно...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

По тактированию - зачем перевыполнять план с 60 МГц пиксельколок? Почему бы 48 не сделать?

 

Изменено пользователем GenaSPB

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 hours ago, GenaSPB said:

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

Не думаю.

Проверил в отладке. Мой код, переделанный под RAM, размещает начало буфера по адресу 0x20002300.

Объем памяти в моем контроллере 320 кб. Это 160 кпикселей. При длине строки в 1024 пикселя это 156 строк, то есть четверть экрана. Собственно примерно четверть экрана мусор и занимает

Я подправил код, теперь, начиная с адреса 0х20003300 он шлет не 2000 слов, а около 614 тыс.(это весь экран). В резулььате экран закрашивается синим ровно на столько, но сколько хватает RAM, то есть на четверь (остальное черное, без.мусора) И в этой синеве никакой жизни процессора не наблюдается. Наблюдается только дрожание начала первой линии прямоугольника и конца последней  его линии.

Да и предыдущая картинка, что на видео - там не видно, но когда вживую смотришь - там нет хаотичной трансформации мусора, как а экране отключенного от антенны телевизора. Ощущение, что строки одной и той же картинки просто съезжают на несколько пикселей.

 

Я пошел дальше - добавил еще один слой, в виде квадрата 200х200, расположил его в центре экрана. Получилась картинка в картинке и еще раз в картинке. Границы рамок слоев четкие. Я ведь правильно понимаю, что контроллер ltdc отправляет на дисплей уже совмещенную картинку? Он не может выборочно обновлять определенную область в дислпплее? Он просто тупо копирует свой буфер в буфер контррллер. Тогда это точно не наводки на линиях от проца к дисплею и не в контроллере дисплея.

Идет какой-то рассинхрон чтения

 

Тогда что? Я грешил на трассировку сдрам, но, как видите, при чтении из RAM та же картина. Да и когда я работал со сдрам - я получал чистые, стабильные по текстуре прямоугольники, у них только смещались концы начальных и конечных линий.

проблемы возникают при предаче данных внутри контроллера.

 

 

5 hours ago, GenaSPB said:

По тактированию - зачем перевыполнять план с 60 МГц пиксельколок? Почему бы 48 не сделать?

Там максимум 67.5 мгц. И, повторюсь, рамка вокруг слоя не дрожит. Будь пиксельклок чрезмерен, то страдало бы все изображение. Я все же попробовал уменьшить - нк помогло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для пробы поменяйте полярность пиксельклока. А снижение частоты просто для уменьшения трафика из памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Попробую, когда домой приду. Для пробы я вчера DE режим отключал -толку не было.  От скуки попробую еще на дисплее Dithering отключить, это единственная нога, которой я еще не дергал.

А с тактированием на моем скриншоте все нормально? Может конфликт какой... сравнил с тактированием DISCO, на котрой все работает - идентично, единственное - у меня кварц 8 мгц, у них 25. Но по мануалу, для седьмой серии достаточно и 4 мгц.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я так и знал, что проблема не в SDRAM или SRAM. Иначе в памяти был бы хаос. А у меня не хаос, а рассинхрон чтения.

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

Догадался я заглянуть, что творится в прерываниях.

И ловятся у меня оба прерывания ошибок - FUIF (Генерируется, когда пиксель запрашивается а FIFO пуст) и TERRIF (Генерируется при возникновении ошибки шины).

В чем может быть причина? Куда копать дальше?  Я пока работаю не со SDRAM, a с RAM, которая, как таковая, настроек не требует.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не представляю... Чтение за пределами памяти? Память не обеспечивает 120 мегабайт в секунду? Снижайте пиксель клок...

Изменено пользователем GenaSPB

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хмм... а кто-нибудь, знает, какова скорость ram в stm32f7 ?

Я пиксельклок снизил до 40 мгц - это нижний предел. Все равно дрожит.

К слову, на плате дискавери я ограничил частоту тактирования sdram насколько позволила система тактирования - порядка 2 мгц , думал, она захлебнется и возникнет такой же эффект. Но ничего не произошло, дисплей работает....

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

16 часов назад, MementoMori сказал:

И ловятся у меня оба прерывания ошибок - FUIF (Генерируется, когда пиксель запрашивается а FIFO пуст) и TERRIF (Генерируется при возникновении ошибки шины).

В чем может быть причина? Куда копать дальше?  Я пока работаю не со SDRAM, a с RAM, которая, как таковая, настроек не требует.

еррату не смотрели, может там что подходит?

2.3.3 Spurious clock stoppage with continuous clock feature enabled
Description
With the continuous clock feature enabled, the FMC_CLK clock may spuriously stop when:
 the FMC_CLK clock is divided by 2, and
 an FMC bank set as 32-bit is accessed with a byte access.
division ratio set to 2, the FMC_CLK clock may spuriously stop upon an
Note:With static memories, a spuriously stopped clock can be restarted by issuing a synchronous transaction or any asynchronous transaction different from a byte access on 32-bit data bus width.
Workaround
With the continuous clock feature enabled, do not set the FMC_CLK clock division ratio to 2 when accessing 32-bit asynchronous memories with byte access.
2.3.4 Data read might be corrupted when the write FIFO is disabled
Description
When the write FIFO is disabled, the FIFO empty event is generated for every write access. During a write access, if a new read access occurs, the FMC grants the read access and waits till the FIFO gets empty. If another read access occurs in a very short window (one cycle the FIFO empty event), the returned data are corrupted. This issue occurs only when the write FIFO is disabled (the WFDIS bit in the FMC_BCR1 register is set).
Workaround
Enable the write FIFO.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо, интересная мысль про фифо. Но это об fmc, а у меня проблема даже при работе со sram.

А кстати, за сколько тактов происходит чтение и запись вo внутреннюю sram? A у sdram в связке с stm какая пропускная способность на частоте 108 мгц? Вытянет ли она пиксельклок в 40-50 мгц? Мне ниже 40 никак нельзя снижать. А в идеале бы 50, потому что на 40 экран уже мерцает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 часов назад, MementoMori сказал:

Хмм... а кто-нибудь, знает, какова скорость ram в stm32f7 ?

Там их 4 штуки, какая из? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

GenaSPB советовал снизить пиксельклок. Мотивируя это тем, что может не хватать пропускной способности.

Пытаясь посчитать, какова же она может и должна быть, я наткнулся на интересную картинку. 

Все уже посчитано до нас

 

oVjFLeSq.png

 

У меня 1 слой, память 32 бит, режим включил 16 бит. То есть в этих условиях LTDC способен отработать 78 МГц пиксельклока.

Я снизил пиксельклок до 30 МГЦ (удивительно, но дисплей работает, хотя заявлен минимум 40). Тем не менее, строки все равно дрожат. Но прерывания ошибки LTDC не ловятся. Точнее они ловятся однократно, спустя какое-то время после запуска.

Что интересно, они дрожат меньше на 63 МГц.

 

Копаю дальше....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 часов назад, MementoMori сказал:

STM32F746BGT6

Имелось ввиду 4 штуки разных SRAM :)  Но вас видимо интересуют SRAM1 и SRAM2.

Я конечно могу вам перепечатать сюда например Reference Manual:

The SRAM1 and SRAM2 ....... These memories can be addressed at maximum system clock frequency without wait state.

 

Проблема может быть в том, что кто-то еще занимает шину.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...