Форум РадиоКот

Приветствую.
Отладочная плата STM32F746 Disco, с 32-битной SDRAM MT48LC4M32B2, которая подключена по 16-битной шине данных.
И вот такая засада выясняется - при выполнении записи в SDRAM в размерности uint16_t или uint32_t по НЕЧЕТНОМУ адресу вываливается с ошибкой "невыровненный доступ". (чтение выполняется нормально). И ладно бы, было бы понятно, но на отладочной плате STM32F469 с такой же SDRAM, но подключенной по 32-битной шине данных этой проблемы нет ни в каком виде. Так же этой проблемы нет и на STM32F429 с 16-битоной SDRAM.

Начал разбираться че да как, в пошаговой отладке выяснил, что виновата инструкция 16-битного сохранения strh. Причем, при включении оптимизации -03 эта инструкция не используется, вместо нее - strb (побайтное сохранение). Однако, пошаговая отладка на -03, мягко говоря, некомфортна, если не сказать больше.
Вроде бы, по описанию из мануала, FMC в режиме SDRAM должен обеспечивать выбор любого байта сигналами DQM.
И поэтому у меня родилась догадка, что из-за подключения только части шины - 16 бит из 32 возможных, возникла такая проблема. Хотя я и не уверен, что именно в этом дело. По идее, в 32-битной SDRAM при 16-битном подключении вторая половина 32-битной ячейки просто не используется.

А вопрос вот в связи с чем - в проекте буду использовать STM32H743 с 32-битной SDRAM MT48LC4M32B2 на 32-битной шине. И поэтому вопрос - будет ли такая же проблема с невыровненным доступом там?
Проверить сейчас не могу - печатная плата не изготовлена, а отладочная с H743XI имеет только 16-битную SDRAM.

PS. Варианты решения "не используй невыровненный доступ" - не подходят, потому как массив переменных типа RGB888 не имеет выравнивания элементов по четным адресам.
PS2. Инит FMC - строго по мануалу, проверял раз на -дцать, в том числе и пошагово.
PS3. При заполнении через DMA2D работает без проблем в любых вариантах.
PS4. Если пиксельный буфер разместить во внутренней SRAM, то так же проблем не возникает ни в каком варианте. То есть, проблема чисто на стыке "FMC - микросхема SDRAM"

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735738#p4735738"]Начал разбираться че да как, в пошаговой отладке выяснил, что виновата инструкция 16-битного сохранения strh. Причем, при включении оптимизации -03 эта инструкция не используется, вместо нее - strb (побайтное сохранение). Однако, пошаговая отладка на -03, мягко говоря, некомфортна, если не сказать больше.[/uquote]Какие получаются инструкции - исключительно прерогатива написанного вами же кода. И его интерпретации компилятором. При желании можно написать так, что записи разобьются на 8-битные. Только код получится тормозной.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735738#p4735738"]По идее, в 32-битной SDRAM при 16-битном подключении вторая половина 32-битной ячейки просто не используется.[/uquote]Идея ложная. "Вторая половина" находится по адресу на +2 выше первой. Убедиться в этом просто.
По причинам неработы невыровненного доступа не подскажу, но возможно что-то не так или с конфигурированием FMC, или кеша данных, или MPU.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735738#p4735738"]PS. Варианты решения "не используй невыровненный доступ" - не подходят, потому как массив переменных типа RGB888 не имеет выравнивания элементов по четным адресам.[/uquote]Не очень понятно - почему именно "не подходят"?
Что такое "переменные типа RGB888"? 24-битные пиксели или...?
Если пиксели, то почему их нельзя хранить неупакованными - как 32-битные (не используя старшие 8 бит)?
Если нужно хранить именно упакованными, то почему нельзя писать в SDRAM по 2 пикселя? Тогда не будет невыровненных записей в принципе.

а. используйте (uint16*)RGB565, либо (uint32*)RGB888, как предложили выше.
б.

Проверить сейчас не могу - печатная плата не изготовлена, а отладочная с H743XI имеет только 16-битную SDRAM.

Соберите конфигурацию только с SDRAM (х32) и проверьте инструкцию невыровненной записи. Наличие/отсутствие самих микросхем контроллеру перпендикулярно, он просто вернет дурь (при чтении). Напомню, вопрос не в данных, а в получении GP от невыровненного доступа. (могу заблуждаться в возможности, но это легко проверяется _практически_)

[uquote="u37",url="/forum/viewtopic.php?p=4735900#p4735900"]Соберите конфигурацию только с SDRAM (х32) и проверьте инструкцию невыровненной записи. Н[/uquote]
Хм, да это то делал, просто думал, что несоответсвие конфигурации как-то влияет.
Подключил Nucleo-H743 вообще без микросхемы, сконфигил FMC. Запускаю - та же фигня: Вылетает на инструкции 16-битного сохранения strh, при этом r3 содержит 0xD0000001. Видимо, хоть модуль FMC во всех линейках внешне и одинаков, но в F7/H7 ведет себя иначе.
Ладно, фик с ним, дальше не буду разбираться, приму как есть, будем считать, что не критично. Главное, что через DMA2D всё-таки работает, а при прямом обращении надо делать побайтную запись.

[uquote="jcxz",url="/forum/viewtopic.php?p=4735895#p4735895"]Не очень понятно - почему именно "не подходят"?
Что такое "переменные типа RGB888"? 24-битные пиксели или...?
Если пиксели, то почему их нельзя хранить неупакованными - как 32-битные (не используя старшие 8 бит)?
Если нужно хранить именно упакованными, то почему нельзя писать в SDRAM по 2 пикселя?[/uquote]
Ааа, видимо, вы не имели дел с графикой и SDRAM Иначе бы непонимания и не возникло.
При аппаратном считывании модулем LTDC никаких зазоров на выравнивание не допускается. А если перейти в режим ARGB8888, то будет лишний оверхед по объему памяти и по битрейту на шине FMC - микросхема SDRAM. При больших размерах дисплея эти параметры становятся весьма важными.
И по два пикселя сразу писать тоже некомильфо, потому что при записи нужного пикселя будет затираться соседний. А операция "прочитать - изменить - записать" сожрет доталова скорости на шине.

"Вторая половина" находится по адресу на +2 выше первой. Убедиться в этом просто.

Опять не угадали Если FMC настроен на 16-битную шину данных, то адреса он располагает непрерывно - DQM_2 и DQM_3 не используются, а на шине адреса формируется следующий адрес. Поэтому, получить доступ ко второй половине 32-битной ячейки микросхемы SDRAM невозможно - верхние DQM не управляются, а адрес переключает сразу на следующую 32-битную ячейку SDRAM.

что-то не так или с конфигурированием FMC, или кеша данных, или MPU.

MPU и кэш выключены. Конфигурация FMC - строго по мануалу, раз на -дцать перепроверенная и испытанная в разных вариантах. Да она и простая в принципе то - задаются размеры шин данных, задаются тайминги, взятые из даташита SDRAM, подаются команды запуска, предзарядки, загрузки регистра конфигурации и выставляется таймер рефреша. Там запутаться то негде.

В общем, я решил, что хрен с ним, буду учитывать этот факт, и все функции непосредственной записи пикселя в DRAM будут покомпонентными, размером в 1 байт

Значицца, сижу, читаю эррату на H743. Там сказано:

Unsupported read access with unaligned address
Description
Read access with unaligned address, such as a half-word read access starting at odd address, is not supported.
Workaround
Compile the software that accesses the fmc region with a compiler option that ensures data alignment, such as no_unaligned_access

То есть, для ЧТЕНИЯ. А про ЗАПИСЬ - ни слова. А в эррате на F746 вообще нет упоминаний о невыровненном доступе.
Походу, надо писать эррату на эррату - список ошибок в списке ошибок.

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

С другой стороны, сижу и грустно смотрю на эрраты H7-серии. FMC везде, во всех моделях H7 косячный, с проблемой невыровненного доступа. Так же доталова косяков и в остальных модулях, причем, довольно чувствительных косяков, с пометкой No workaround, то есть, без решения.
Мдя. Мож, хрен на эти 480 МГц (которые только для ядра, любая периферия, включая флеш и общую SRAM, вдвое медленнее), и делать на старом F746, который хоть и имеет косяк с SDRAM, но в общем остальных косяков поменьше.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735923#p4735923"]Ааа, видимо, вы не имели дел с графикой и SDRAM Иначе бы непонимания и не возникло.[/uquote]Мимо. Имел дело и с тем и с другим. Потому и непониманию - на кой писать поточечно??? Имхо - в нормально написанном графическом ПО практически не должно быть поточечных манипуляций с картинкой.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735923#p4735923"]А если перейти в режим ARGB8888, то будет лишний оверхед по объему памяти и по битрейту на шине FMC - микросхема SDRAM. При больших размерах дисплея эти параметры становятся весьма важными.[/uquote]Т.е. - увеличение объёма потока по чтению на какую то всего лишь 1/3 вас напрягает. В то время как увеличение объёма потока по записи аж в 3 раза! - совсем не напрягает?

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735923#p4735923"]И по два пикселя сразу писать тоже некомильфо, потому что при записи нужного пикселя будет затираться соседний. А операция "прочитать - изменить - записать" сожрет доталова скорости на шине.[/uquote]Так напишите своё графическое ПО так, чтобы операций "прочитать - изменить - записать" требовалось по минимуму. Чтобы ПО старалось писать пиксели пачками, по многу за раз.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735923#p4735923"]Поэтому, получить доступ ко второй половине 32-битной ячейки микросхемы SDRAM невозможно - верхние DQM не управляются, а адрес переключает сразу на следующую 32-битную ячейку SDRAM.[/uquote]Т.е. - вы взяли микросхему с 32-битной шиной, но подключили к МК только младшие 16 бит? Ну ладно - потеряли половину ёмкости чипа. Ну и что? Работать то оно должно нормально. Какая разница - сколько бит ячейки используется?

[uquote="КотПротон",url="/forum/viewtopic.php?p=4735923#p4735923"]В общем, я решил, что хрен с ним, буду учитывать этот факт, и все функции непосредственной записи пикселя в DRAM будут покомпонентными, размером в 1 байт[/uquote]Да уж.... "решение"... вместо одной 32-битной записи на пиксель, выполняемой одной командой CPU, будет аж ~5 команд! для записи одной единственной точки. Программа будет ползать еле-еле....

[uquote="jcxz",url="/forum/viewtopic.php?p=4736222#p4736222"]]Мимо. Имел дело и с тем и с другим. Имхо - в нормально написанном графическом ПО практически не должно быть поточечных манипуляций с картинкой.[/uquote]
Если бы реально имели дело, то не спрашивали бы, что такое RGB888 и знали бы, что такое отрисовка линий и окружностей по алгоритму Брезенхема. Они попиксельно рисуются. Другого не придумано пока что.

[uquote="jcxz",url="/forum/viewtopic.php?p=4736222#p4736222"]Т.е. - увеличение объёма потока по чтению на какую то всего лишь 1/3 вас напрягает. В то время как увеличение объёма потока по записи аж в 3 раза! - совсем не напрягает?[/uquote]
Меня не напрягает. Напрягает подсистему памяти на участке SDRAM - LTDC, а так же DMA2D - SDRAM. Если бы вы с этим имели дело, то понимали бы.
В мануале четко написано, какие форматы с какой скоростью на какой размер дисплея могут идти. И это вам не 320х240, а 1280х800.

[uquote="jcxz",url="/forum/viewtopic.php?p=4736222#p4736222"]Так напишите своё графическое ПО так, чтобы операций "прочитать - изменить - записать" требовалось по минимуму. Чтобы ПО старалось писать пиксели пачками, по многу за раз.[/uquote]
У меня графический движок уже давно написан и использует как прямое построение, так и граф.ускоритель.

[uquote="jcxz",url="/forum/viewtopic.php?p=4736222#p4736222"]Т.е. - вы взяли микросхему с 32-битной шиной, но подключили к МК только младшие 16 бит? Ну ладно - потеряли половину ёмкости чипа. Ну и что? Работать то оно должно нормально. Какая разница - сколько бит ячейки используется?[/uquote]
Это не я взял, а производитель ST Microelectronics на своей отладочной плате Discovery так поставил. Не знаю почему. Спросите у них, если кажется, что они ошиблись.
В предыдущем сообщении вы не знали, как SDRAM адресуется, а тут вдруг заявляете обратное. Быстро ж переобулись. Я б на вашем месте промолчал....

[uquote="jcxz",url="/forum/viewtopic.php?p=4736222#p4736222"]Да уж.... "решение"... вместо одной 32-битной записи на пиксель, выполняемой одной командой CPU, будет аж ~5 команд! для записи одной единственной точки. Программа будет ползать еле-еле.... [/uquote]
Если бы вы разбирались в теме графики, то спокойно бы реагировали, а не писали бы ерунды. Если сделать одну 32-битную запись поверх 24-битного пикселя, то соседний пиксель будет поврежден. Подумали бы хоть немного, прежде чем писать доталова букв не по делу.

Для тех, кто в танке, поясняю - далеко не всё можно отрисовать во встроенной SRAM по причине размеров. И рисовать кусок в SRAM, потом кидать его через DMA2D в SDRAM, потом повторять для след.куска и так далее - не всегда хорошее решение.
Но по-видимому, придется вернуться к такому решениею из-за косячного контроллера FMC.
И еще раз - 32 бита на пиксель - это непозволительный оверхед при двух слоях и 1280х800 пикс.
Если бы читали мануалы, то видели бы ограничения.
Так что не кричите, а спокойно разберитесь в теме вопроса.

Напомню - тема вопроса была про косяк работы FMC с невыровненным доступом. И я нашел ответ - косячный модуль FMC во всей линейке. Об этом говорит эррата.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]Если бы реально имели дело, то не спрашивали бы, что такое RGB888 и знали бы, что такое отрисовка линий и окружностей по алгоритму Брезенхема. Они попиксельно рисуются. Другого не придумано пока что.[/uquote]Если бы вы реально имели дело с графикой, то знали бы, что только чайники рисуют что-то (тем более - линии) попиксельно.
И потому их код не выполняется, а скорее ползает.
Когда научитесь программировать (а не только своё ЧСВ прокачивать), то сможете и линии и даже круги/окружности рисовать быстро. И проблем с невыровненным доступом не будет. И ахинею про STRB/STRH не будете нести.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]Если бы вы с этим имели дело, то понимали бы.
В мануале четко написано, какие форматы с какой скоростью на какой размер дисплея могут идти. И это вам не 320х240, а 1280х800.[/uquote]Не надо гадать тут, что я знаю или с чем имел дело - вы всё время тыкаете пальцем в небо. С DMA2D я тоже имел дело. И имею законченные проекты с ним.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]У меня графический движок уже давно написан и использует как прямое построение, так и граф.ускоритель.[/uquote]"Движок" рисующий попиксельно , годится только в мусорку.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]Это не я взял, а производитель ST Microelectronics на своей отладочной плате Discovery так поставил. Не знаю почему. Спросите у них, если кажется, что они ошиблись.
В предыдущем сообщении вы не знали, как SDRAM адресуется, а тут вдруг заявляете обратное. Быстро ж переобулись. Я б на вашем месте промолчал....[/uquote]Т.е. - вы не сумели правильно запрограммировать чип, из-за чего используется только половина SDRAM. Да и то запрограммировали криво. Но конечно виноваты все вокруг (и производтель платы в том числе), но конечно только не вы.
Что производитель поставил на свою плату что-то неправильно - не надо рассказывать сказок. Снимите корону и скажите правду, что не справились с инициализацией FMC/SDRAM.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]Если бы вы разбирались в теме графики, то спокойно бы реагировали, а не писали бы ерунды. Если сделать одну 32-битную запись поверх 24-битного пикселя, то соседний пиксель будет поврежден. Подумали бы хоть немного, прежде чем писать доталова букв не по делу.[/uquote]Пока наезжаете и несёте ерунду здесь только вы. Если бы вы сняли корону, умерили своё ЧСВ и хоть немного подумали бы, то поняли бы как писать 32-битными словами.
Если что: моя графическая библиотека в одном из проектов рисует линии и другие фигуры максимально используя 32-битные записи. При том что точки там занимают вообще по 4 бита. И никакой Брезенхем мне не мешает почему-то.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]И я нашел ответ - косячный модуль FMC во всей линейке.[/uquote]Плохому танцору всегда кто-то мешает: производитель платы, чип, еррата... Всегда кто угодно виноват, но только не он сам.


PS: Заходим на сайт "ARM" читаем:

SYMPTOM
If you use an STM32F7xx microcontroller with an external SDRAM, the Cortex-M7 core may unexpectedly run into the hard fault handler because of unaligned access. This may happen for example, when the frame buffer of an LCD, a RAM filesystem or any other data is located into the SDRAM address range 0xC0000000 - 0xC03FFFFF (max. 4MB). The hard fault is executed although the bit UNALIGN_TRP (bit 3) in the CCR register is not enabled.

CAUSE
In general, RAM accesses on Cortex-M7 based devices do not have to be aligned in any way. The Cortex-M7 core can handle unaligned accesses by hardware. Usually, variables should be naturally aligned because these accesses are slightly faster than unaligned accesses.

STM32F7xx devices have the external SDRAM mapped to the address range 0xC0000000 - 0xC03FFFFF (max. 4MB). According to the ARMv7-M Architecture Reference Manual chapter B3.1 (table B3-1), the area 0xC0000000-0xDFFFFFFF (32MB) is specified as Device Memory Type. According to chapter A3.2.1, all accesses to Device Memory Types must be naturally aligned. If they are not, a hard fault will execute no matter if the bit UNALIGN_TRP (bit 3) in the CCR register is enabled or not.

RESOLUTION
There are several possible solutions for the STM32F7xx:

1. Enable the MPU for this region

This is the solution we recommend and which we are using in our emWin GUI Demo for this microcontroller. This can be achieved by the following code that needs to be called before the SDRAM is accessed.
...
This code initializes the MPU so that the SDRAM memory area is considered as Normal Memory type instead of Device Memory type. This disables the access alignment restrictions.

2. Remap the SDRAM to a different address

The SDRAM could also be remapped to address 0x60000000 with the following code:
...
The data of the application needs to be linked into this area as well. The disadvantage is that this address area is usually used by external NOR Flash or PSRAM or SRAM. These external memory devices could not be used in this case.

https://developer.arm.com/documentation/ka002886/latest/
Совет "задействовать MPU" был дан мною ещё в самом первом сообщении. Но ТС его проигнорировал, вместо этого начав наезжать и прокачивать своё ЧСВ.

PPS: К сведению чайников, не знающих что такое STRH/STRB - даже если невыровненный доступ работает, то невыровненные операции доступа к памяти, всё равно выполняются медленнее. Не говоря уже о том, что запись пикселя в два приёма STRH+STRB (даже с выровненной STRH) будет гораздо медленнее одной 32-битной записи. И писать что-то графическое попиксельно, да ещё - записывая каждый пиксель в несколько приёмов - это просто днище. Это не программирование, а говнокодинг.

Ну и к чему этот поток самосознания от вас? Еще три дня назад вы не знали, что такое RGB888 и какая адресация у SDRAM, а сейчас вы хвастаетесь тем, чего за пару дней прочли. Еще и хамите. Тьфу на вас, необразованное хамло и хвастун Вам еще подрасти до моего уровня, потом получите разрешение хамить. Хотя лично я никому не хамлю, несмотря на немалый свой опыт. Хамят те, у кого опыта и знаний по-минималке, это давно известный факт.

А то, что вы процитировали, я уже нашел до вас, О ЧЕМ И НАПИСАЛ В ПРЕДЫДУЩЕМ СООБЩЕНИИ. Это всего лишь констатация факта косяка контроллера FMC/SDRAM.
[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]И я нашел ответ - косячный модуль FMC во всей линейке. .[/uquote]
Так понятно? Так что не стоило истерить.
Вы, сударь, хамло Тьфу на вас еще раз. Чем меньше опыта, тем больше истерик. Поскольку вы сами сказали:
[uquote="jcxz",url="/forum/viewtopic.php?p=4735895#p4735895"]По причинам неработы невыровненного доступа не подскажу,[/uquote]
Так что вы об этом точно так же не знали и узнали буквально сегодня Не надо врать, сударь!

Ладно, можете истерить дальше - чем больше истерик, тем меньше практического опыта у истерекующего.
И к следующему разу -
[uquote="jcxz",url="/forum/viewtopic.php?p=4736372#p4736372"]запрограммировать чип, из-за чего используется только половина SDRAM.[/uquote]
- к следующему вашему потоку самосознания прочтите, как работает SDRAM. Адресуемые в конкретно этой микросхеме SDRAM ячейки - 32-битные. На линиях адреса A[0...] выставляется не адрес байта, а адрес ЯЧЕЙКИ, которая в этой микросхеме является 4-байтной (32 бита).
И конкретный байт выбирается сигналами DQM[3:0]. И если DQM2 и DQM3 не подключены, то старшее полуслово DQ[31:16] не используется. Отсюда - и половина от заявленной ёмкости микросхемы. Это НЕ зависит от конфигурации FMC. Можно выставить ширину шины данных в 32 бита, но если DQM[3:2] и DQ[31:16] не подключены, то старшее полуслово потеряется. Как вы его собрались извлекать то?
Вот сидите теперь и читайте мануалы. А то врёте про то, чего не нюхали. Меня то не обманешь этим фуфлом


[uquote="jcxz",url="/forum/viewtopic.php?p=4735895#p4735895"]"Движок" рисующий попиксельно годится только в мусорку.[/uquote]
Ну нарисуйте наклонную линию под 45° не попиксельно Глупый хвастун! Тьфу на вас еще раз.

[uquote="КотПротон",url="/forum/viewtopic.php?p=4736384#p4736384"]А то, что вы процитировали, я уже нашел до вас, О ЧЕМ И НАПИСАЛ В ПРЕДЫДУЩЕМ СООБЩЕНИИ.[/uquote]Да ладно! Вы об этом узнали только из моего поста.
[uquote="КотПротон",url="/forum/viewtopic.php?p=4736261#p4736261"]И я нашел ответ - косячный модуль FMC во всей линейке. .[/uquote]Как известно: Плохому танцору даже яйца мешают. Это про вас.
[uquote="КотПротон",url="/forum/viewtopic.php?p=4736384#p4736384"]А то врёте про то, чего не нюхали. Меня то не обманешь этим фуфлом
...
Глупый хвастун! Тьфу на вас еще раз.[/uquote]И кто после этого неблагодарное хамло?
Остальной ваш бред комментировать лень. Чешите своё ЧСВ и дальше.

PS: Каждый чайник, только научившийся тыкать в кнопки, почему-то мнит себя великим кодером. Ещё и других поучает....

Ну, на этом и закончим. Видимо, в адресации ячеек SDRAM разбираться вам лень, и линию под 45° тоже ниасилили. И когда поняли, что не вывозите по знаниям, от вас начался сплошной поток хамства и личных оскорблений - обычная практика у таких как вы. Это в инете безопасно оскорблять других, а при разговоре тет-а-тет вам давно бы уже в рыло насовали за это.

Ну и слава богу, вы хоть не будете лезть туда, где не разбираетесь. Слава aллaxу, хамливый дилетант самослился. Тьфу на него еще раз