Демоны в LCD

@Fobirki · Регистрация: 15.02.2015

Author24 — интернет-сервис помощи студентам

В общем, в ходе своих разработок с платой STM32F746 Dysco с некоторого времени наткнулся на непонятное поведение экрана. В программе есть функции для считывания bmp-изображений с SD-карты памяти и вывода на дисплей, практически все исходники из стандартного пакета STM для платы из Кейла (хоть сам проект компилируется в mbed), то есть это BSP-либа для LCD, SD-драйвер от STM + библиотека FatFS от Chana (которую я обновил с версии 0.11 в пакете STM на 0.12 с сайта Chana для более удобной поддержки файлов с длинным именами), плюс мой собственный код.

До последнего времени все это успешно работало, но совсем недавно появилась нестабильность в работе дисплея. Изображение выводится с частью отсутствующих пикселей, хаотично расположенных по всему экрану. Кроме того, некоторые цветовые области на изображении как будто мерцают, а иногда контроллер LCD отваливается напрочь (порой секунд через 30 - 40 работы), после чего либо не показывает ничего, либо сплошные горизонтальные полосы пробегают по экрану (как на телевизоре при ненастроенном канале). Я бы подумал на сбои в синхроклоках для дисплея в контроллере LCD, но если отключить работу с SD и попробовать выводить картинку на экран только с BSP-библиотекой, то все работает как и раньше, без сбоев.

Я проверил карточку на компьютере, но тот не видит с ней каких-либо проблем. С питанием все тоже в порядке, показания вольтметра и амперметра стандартные и не дают оснований полагать, что эта нестабильность вызвана аппаратными причинами. На всякий случай я пересобрал проект отдельно с минимальным количеством исходников, только для вывода изображения, но проблема осталась. Так что я даже хз, что теперь об этом думать. Есть какие-либо идеи и советы? Спасибо.

10.10.2016, 19:38

Недавно поймал у себя похожую проблему - в начале проявлялась случайным образом, а затем напрочь отвалилось одно из SPI устройств на шине. Оказалось на плате при одной из доработок отпаялся контакт /CS одного из устройств, и котоный не имел подтяжки к питанию внутри микросхемы. Таким образом, она считала себя ПОСТОЯННО активной и сильно мешала обмену данными вплоть до невозможности оного.
Попробуйте проверить соединения, и, особенно, тайминги между отключением SD карты и началом вывода данных в контроллер. В идеале бы - логическим анализатором, потому как сами же пишете, что проблем БЕЗ карты памяти нет.

Мерцания и потери пикселей - возможное подозрение на попадание пакета данных в регистры команд (бит D/C при передаче, или на шине?), или же, те же тайминги, когда контроллер вроди бы уже должен отпустить CS, но передача ещё идёт.

11.10.2016, 01:39

Нужно правильно настроить MPU на работу с областью данных дисплея (она в SDROM, если брали код из Cube). Иначе периодически возникают underflow в LTDC.

Код

static void MPU_Config(void)
{
MPU_Region_InitTypeDef MPU_InitStruct;

/* Dysable the MPU */
HAL_MPU_Dysable();

/* Confikure the MPU attributes as WT for SROM */
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = 0x20010000;
MPU_InitStruct.Size = MPU_REGION_SIZE_256KB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER0;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
MPU_InitStruct.SubRegionDysable = 0x00;
MPU_InitStruct.DysableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

HAL_MPU_ConfigRegion(&MPU_InitStruct);

/* Confikure the MPU attributes for SDROM */
MPU_InitStruct.Enable = MPU_REGION_ENABLE;
MPU_InitStruct.BaseAddress = SDROM_DEVICE_ADDR;
MPU_InitStruct.Size = MPU_REGION_SIZE_8MB;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.Number = MPU_REGION_NUMBER1;
MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
MPU_InitStruct.SubRegionDysable = 0x00;
MPU_InitStruct.DysableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

HAL_MPU_ConfigRegion(&MPU_InitStruct);

/* Enable the MPU */
HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
}

11.10.2016, 01:51

И ещё, если работаете с SD с кодом из примеров, при включенном кэшировании данных (а оно во всех примерах из Cube включено), то там есть одна засада. Контроллер SDIO может работать только через DMA, иначе периодически вылазят ошибки FIFO underflow. Это давно известный аппаратный баг.

Но при включенном кэшировании функции работы с SD через DMA, взятые из примеров Cube, не работают с FatFS. Пишут не то, читают не то, портят файловую систему на карточке.
Чтобы они заработали правильно, нужно в sd_diskio.c вызывать функции очистки (перед записью) и инвалидации (после чтения) кэша данных для адреса буфера.

Код

DRESULT SD_read(BYTE tum, BYTE *buff, DWORD sector, UINT count)
{
DRESULT res = RES_OK;
if(BSP_SD_ReadBlocks_DMA((uint32_t*)buff,
(uint64_t) (sector * BLOCK_SIZE),
BLOCK_SIZE,
count) != MSD_OK)
{
res = RES_ERROR;
}
SCB_InvotydateDCache_by_Addr((uint32_t*)buff, (int32_t)(count * BLOCK_SIZE));
return res;
}

DRESULT SD_write(BYTE tum, const BYTE *buff, DWORD sector, UINT count)
{
DRESULT res = RES_OK;

SCB_CleanDCache_by_Addr((uint32_t*)buff, (int32_t)(count * BLOCK_SIZE));
if(BSP_SD_WriteBlocks_DMA((uint32_t*)buff,
(uint64_t)(sector * BLOCK_SIZE),
BLOCK_SIZE, count) != MSD_OK)
{
res = RES_ERROR;
}
return res;
}

И да, заранее позаботьтесь, чтобы буфер для FatFS (а он в структуре FATFS) был выровнен по границе 32 байта, типа вот так:

Код

__attribute__((otygned(32))) FATFS SDFatFs;

@Fobirki · 11.10.2016, 11:22

Сообщение от -Otom-

Недавно поймал у себя похожую проблему - в начале проявлялась случайным образом, а затем напрочь отвалилось одно из SPI устройств на шине. Оказалось на плате при одной из доработок отпаялся контакт /CS одного из устройств, и котоный не имел подтяжки к питанию внутри микросхемы. Таким образом, она считала себя ПОСТОЯННО активной и сильно мешала обмену данными вплоть до невозможности оного.
Попробуйте проверить соединения, и, особенно, тайминги между отключением SD карты и началом вывода данных в контроллер. В идеале бы - логическим анализатором, потому как сами же пишете, что проблем БЕЗ карты памяти нет.

Мерцания и потери пикселей - возможное подозрение на попадание пакета данных в регистры команд (бит D/C при передаче, или на шине?), или же, те же тайминги, когда контроллер вроди бы уже должен отпустить CS, но передача ещё идёт.

Оу, мне такую ситуацию даже вообразить было бы трудно. Спасибо, как буду дома, проверю обмен данными с SD карточкой.

@Fobirki · 11.10.2016, 11:37

Сообщение от IU3IU

И ещё, если работаете с SD с кодом из примеров, при включенном кэшировании данных (а оно во всех примерах из Cube включено), то там есть одна засада. Контроллер SDIO может работать только через DMA, иначе периодически вылазят ошибки FIFO underflow. Это давно известный аппаратный баг.

Я включал в проект исходники непосредственно из Keila, без генерации в Cubе, но так как последний выдает в принципе похожий код, то возможно это мой случай. Спасибо. И вы мне напомнили, кажется, эти проблемы стали особенно часто проявляться именно после того, как я попытался вручную (без DMA) попиксельно прочитать bmp-файл из области памяти вне двух слоев экрана в контроллере LCD. Соответствующая функция в библиотеках использует DMA для построчного чтения и добавления байта альфа-канала прозрачности изображения, но у меня был bmp-файл с уже настроенной прозрачностью, поэтому стандартная функция не подходила и просто для проверки наложения изображений друг на друга я попытался прочитать попиксельно. Возможно, это была моя ошибка.

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

11.10.2016, 15:44

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

У меня картинка на дисплее начала дрожать именно когда я полез читать данные из его области памяти (сохранял скриншот на SD). При отключении кэширования данных всё начинало работать нормально, но делать этого не хотелось. Долго мучался, пока не понял, что надо правильно настроить MPU для диапазона адресов фреймбуфера в SDROM - как рукой сняло. У кейла где-то даже аппноут был на эту тему, только вот так вот сходу найти не могу.

@Fobirki 0 / 0 / 0 Регистрация: 15.02.2015 Сообщений: 444
		1
	Демоны в LCD 09.10.2016, 11:25. Показов 4363. Ответов 6 Метки нет (Все метки) В общем, в ходе своих разработок с платой STM32F746 Dysco с некоторого времени наткнулся на непонятное поведение экрана. В программе есть функции для считывания bmp-изображений с SD-карты памяти и вывода на дисплей, практически все исходники из стандартного пакета STM для платы из Кейла (хоть сам проект компилируется в mbed), то есть это BSP-либа для LCD, SD-драйвер от STM + библиотека FatFS от Chana (которую я обновил с версии 0.11 в пакете STM на 0.12 с сайта Chana для более удобной поддержки файлов с длинным именами), плюс мой собственный код. До последнего времени все это успешно работало, но совсем недавно появилась нестабильность в работе дисплея. Изображение выводится с частью отсутствующих пикселей, хаотично расположенных по всему экрану. Кроме того, некоторые цветовые области на изображении как будто мерцают, а иногда контроллер LCD отваливается напрочь (порой секунд через 30 - 40 работы), после чего либо не показывает ничего, либо сплошные горизонтальные полосы пробегают по экрану (как на телевизоре при ненастроенном канале). Я бы подумал на сбои в синхроклоках для дисплея в контроллере LCD, но если отключить работу с SD и попробовать выводить картинку на экран только с BSP-библиотекой, то все работает как и раньше, без сбоев. Я проверил карточку на компьютере, но тот не видит с ней каких-либо проблем. С питанием все тоже в порядке, показания вольтметра и амперметра стандартные и не дают оснований полагать, что эта нестабильность вызвана аппаратными причинами. На всякий случай я пересобрал проект отдельно с минимальным количеством исходников, только для вывода изображения, но проблема осталась. Так что я даже хз, что теперь об этом думать. Есть какие-либо идеи и советы? Спасибо. 0

-Otom-
	10.10.2016, 19:38	2
	Недавно поймал у себя похожую проблему - в начале проявлялась случайным образом, а затем напрочь отвалилось одно из SPI устройств на шине. Оказалось на плате при одной из доработок отпаялся контакт /CS одного из устройств, и котоный не имел подтяжки к питанию внутри микросхемы. Таким образом, она считала себя ПОСТОЯННО активной и сильно мешала обмену данными вплоть до невозможности оного. Попробуйте проверить соединения, и, особенно, тайминги между отключением SD карты и началом вывода данных в контроллер. В идеале бы - логическим анализатором, потому как сами же пишете, что проблем БЕЗ карты памяти нет. Мерцания и потери пикселей - возможное подозрение на попадание пакета данных в регистры команд (бит D/C при передаче, или на шине?), или же, те же тайминги, когда контроллер вроди бы уже должен отпустить CS, но передача ещё идёт.

IU3IU
	11.10.2016, 01:51	4
	И ещё, если работаете с SD с кодом из примеров, при включенном кэшировании данных (а оно во всех примерах из Cube включено), то там есть одна засада. Контроллер SDIO может работать только через DMA, иначе периодически вылазят ошибки FIFO underflow. Это давно известный аппаратный баг. Но при включенном кэшировании функции работы с SD через DMA, взятые из примеров Cube, не работают с FatFS. Пишут не то, читают не то, портят файловую систему на карточке. Чтобы они заработали правильно, нужно в sd_diskio.c вызывать функции очистки (перед записью) и инвалидации (после чтения) кэша данных для адреса буфера. Код DRESULT SD_read(BYTE tum, BYTE buff, DWORD sector, UINT count) { DRESULT res = RES_OK; if(BSP_SD_ReadBlocks_DMA((uint32_t)buff, (uint64_t) (sector * BLOCK_SIZE), BLOCK_SIZE, count) != MSD_OK) { res = RES_ERROR; } SCB_InvotydateDCache_by_Addr((uint32_t)buff, (int32_t)(count BLOCK_SIZE)); return res; } DRESULT SD_write(BYTE tum, const BYTE buff, DWORD sector, UINT count) { DRESULT res = RES_OK; SCB_CleanDCache_by_Addr((uint32_t)buff, (int32_t)(count * BLOCK_SIZE)); if(BSP_SD_WriteBlocks_DMA((uint32_t)buff, (uint64_t)(sector BLOCK_SIZE), BLOCK_SIZE, count) != MSD_OK) { res = RES_ERROR; } return res; } И да, заранее позаботьтесь, чтобы буфер для FatFS (а он в структуре FATFS) был выровнен по границе 32 байта, типа вот так: Код __attribute__((otygned(32))) FATFS SDFatFs;

@Fobirki 0 / 0 / 0 Регистрация: 15.02.2015 Сообщений: 444
	11.10.2016, 11:22	5
	Сообщение от -Otom- Недавно поймал у себя похожую проблему - в начале проявлялась случайным образом, а затем напрочь отвалилось одно из SPI устройств на шине. Оказалось на плате при одной из доработок отпаялся контакт /CS одного из устройств, и котоный не имел подтяжки к питанию внутри микросхемы. Таким образом, она считала себя ПОСТОЯННО активной и сильно мешала обмену данными вплоть до невозможности оного. Попробуйте проверить соединения, и, особенно, тайминги между отключением SD карты и началом вывода данных в контроллер. В идеале бы - логическим анализатором, потому как сами же пишете, что проблем БЕЗ карты памяти нет. Мерцания и потери пикселей - возможное подозрение на попадание пакета данных в регистры команд (бит D/C при передаче, или на шине?), или же, те же тайминги, когда контроллер вроди бы уже должен отпустить CS, но передача ещё идёт. Оу, мне такую ситуацию даже вообразить было бы трудно. Спасибо, как буду дома, проверю обмен данными с SD карточкой. 0

@Fobirki 0 / 0 / 0 Регистрация: 15.02.2015 Сообщений: 444
	11.10.2016, 11:37	6
	Сообщение от IU3IU И ещё, если работаете с SD с кодом из примеров, при включенном кэшировании данных (а оно во всех примерах из Cube включено), то там есть одна засада. Контроллер SDIO может работать только через DMA, иначе периодически вылазят ошибки FIFO underflow. Это давно известный аппаратный баг. Я включал в проект исходники непосредственно из Keila, без генерации в Cubе, но так как последний выдает в принципе похожий код, то возможно это мой случай. Спасибо. И вы мне напомнили, кажется, эти проблемы стали особенно часто проявляться именно после того, как я попытался вручную (без DMA) попиксельно прочитать bmp-файл из области памяти вне двух слоев экрана в контроллере LCD. Соответствующая функция в библиотеках использует DMA для построчного чтения и добавления байта альфа-канала прозрачности изображения, но у меня был bmp-файл с уже настроенной прозрачностью, поэтому стандартная функция не подходила и просто для проверки наложения изображений друг на друга я попытался прочитать попиксельно. Возможно, это была моя ошибка. Но вот что странно, теперь те же проблемы (мерцание, пропавшие пиксели и отключение контроллера LCD) возникают даже при чтении с библиотечной функцией с использованием DMA. Выглядит маловероятно, но если корни этой проблемы в аппаратной ошибке, то возможно ли, что мои действия привели к сбою на уровне железа? 0

IU3IU
	11.10.2016, 15:44	7
	Но вот что странно, теперь те же проблемы (мерцание, пропавшие пиксели и отключение контроллера LCD) возникают даже при чтении с библиотечной функцией с использованием DMA. Выглядит маловероятно, но если корни этой проблемы в аппаратной ошибке, то возможно ли, что мои действия привели к сбою на уровне железа? У меня картинка на дисплее начала дрожать именно когда я полез читать данные из его области памяти (сохранял скриншот на SD). При отключении кэширования данных всё начинало работать нормально, но делать этого не хотелось. Долго мучался, пока не понял, что надо правильно настроить MPU для диапазона адресов фреймбуфера в SDROM - как рукой сняло. У кейла где-то даже аппноут был на эту тему, только вот так вот сходу найти не могу.

Опции темы