Ви не увійшли.
А #define SDRAM_READBURST FMC_Read_Burst_Disable якось впливає?
Змінював коли ще був встановлений параметр SDRAM FMC_SDMemory_Width_16b, результат не змінювався. З параметром SDRAM FMC_SDMemory_Width_8b і FMC_Read_Burst_Enable, стає гірше.
Зараз зображення стабільне. Пробував знову замінити швидкість пінів SDRSM з 25мГц на 50мГц, артефакти з'явились знову, але появляються рідко. З GPIO_Speed_25MHz з зображенням все гаразд.
Наразі налаштував роздільну здатність LTDC 800х600 pixel clock 40мГц, нашвидкоруч написав функції для роботи з графікою, щоб зображення було динамічним, також налаштував переривання таймера по захвату, щоб перевірити чи не буде воно заважати LTDC. Тестую вже декілька годин, артефакти за цей час з'являлись лише пару разів.
p.s. Саме зміна третього пункту допомогла, з першими 2 пунктами атрефакти все ще були.
А #define SDRAM_READBURST FMC_Read_Burst_Disable якось впливає?
Я б сказав "десь між формувачем адреси в МК і декодером адреси в мікросхемі SDRAM". Малоймовірно, що збоїть десь в самому МК чи після декодера в SDRAM, хоча таке теж не виключено.
Ніби як вирішив проблему з артефактами, поки що рішення дуже грубе, намагаюсь зрозуміти чому працює саме в такому варіанті.
1. Роздільна здатність 400х600, частота LTDC 20мГц.
2. Замінив LTDC_Pixelformat_RGB565 на LTDC_Pixelformat_L8. Відповідно (LTDC_CFBLineLength) і (LTDC_CFBPitch) теж підправив.
3. В налаштуваннях SDRAM FMC_SDMemory_Width_16b замінив на FMC_SDMemory_Width_8b.
Все інше ніби залишив так як і було. Поки що жодного артефакта не вискакувало.
p.s. Саме зміна третього пункту допомогла, з першими 2 пунктами атрефакти все ще були.
Ще не перевіряв, виходить що ще може бути проблема в самій мікросхемі SDRAM?
Я б сказав "десь між формувачем адреси в МК і декодером адреси в мікросхемі SDRAM". Малоймовірно, що збоїть десь в самому МК чи після декодера в SDRAM, хоча таке теж не виключено.
90 МГц - не така висока частота по сучасним міркам, але нюанси розводки плати і монтажу вже мають значення. І при одних зовнішніх умовах (електромагнітний фон, якість живлення) може працювати стабільно, при інших уже ні.
Але якщо опустити частоту ядра до 80мГц відповідно частота SDRAM при цьому опускається до 40мГц, то працює і на GPIO_Speed_2MHz, з тими ж артефактами.
Тобто від абсолютного значення частоти не залежить, характеристики лінії, схоже, не впливають. Тоді залишаються таймінги відносно тактової частоти.
Маркування SDRAM що у мене на платі IS42S16400J-7TL, даташит каже що із закінченням -7 (CAS Latency=3 143Mhz) (CAS Latency=2 133Mhz) навіть так, запасу по частоті має вистачати.
Якщо нічого не плутаю, то для динамічної памʼяті занадто низька частота зі сторони хоста теж не є добре. Хоча тут можу помилятись.
Дані-то читаються наче б то правильні, тільки не з тих адрес
Ще не перевіряв, виходить що ще може бути проблема в самій мікросхемі SDRAM?
це ж тільки умовні позначення, насправді конфігурується вихідний опір
Про це знаю, просто так простіше пояснити що саме змінювалось
Із цікавості, не пробували ставити low speed (GPIO_Speed_2MHz)?
Не працює зовсім, екран при цьому чорний. Але якщо опустити частоту ядра до 80мГц відповідно частота SDRAM при цьому опускається до 40мГц, то працює і на GPIO_Speed_2MHz, з тими ж артефактами.
Ще, в програмі SD clock frequency конфігурується на 90 МГц, а в даташиті на IS42S16400J говориться про "Clock frequency: 200, 166, 143, 133 MHz".
Маркування SDRAM що у мене на платі IS42S16400J-7TL, даташит каже що із закінченням -7 (CAS Latency=3 143Mhz) (CAS Latency=2 133Mhz) навіть так, запасу по частоті має вистачати.
Це типу тест на перевірку цілісності даних у пам'яті.
Не стільки цілісність даних, скільки надійність комунікації. Дані-то читаються наче б то правильні, тільки не з тих адрес
Єдине що дає результат, це зменшення швидкості роботи пінів що підключаються до SDRAM.
При налаштуванні пінів на 50мГц артефакти майже постійно присутні на екрані.
При налаштуванні пінів на 25мГц артефакти на екрані з'являються десь періодичністю 3 - 4 рази на хвилину.
Занадто різкі фронти спричиняють дзвін, який дає (додає) завади. 25 і 50 МГц - це ж тільки умовні позначення, насправді конфігурується вихідний опір, який впливає на крутизну фронтів та спектр. Фактичний спектр залежить від характеристики навантаження.
Із цікавості, не пробували ставити low speed (GPIO_Speed_2MHz)?
Ще, в програмі SD clock frequency конфігурується на 90 МГц, а в даташиті на IS42S16400J говориться про "Clock frequency: 200, 166, 143, 133 MHz".
Можна спробувати потестити програмно
Це типу тест на перевірку цілісності даних у пам'яті.
Поки що пробував ініціалізувати SDRAM, гарантовано робочим кодом іншого автора, результат без змін. Також не допомагає і зменшення частоти ядра, при цьому SDRAM працює на нижчій частоті, з більшими таймінгами.
Єдине що дає результат, це зменшення швидкості роботи пінів що підключаються до SDRAM.
При налаштуванні пінів на 50мГц артефакти майже постійно присутні на екрані.
При налаштуванні пінів на 25мГц артефакти на екрані з'являються десь періодичністю 3 - 4 рази на хвилину.
Візуально все припаяно добре, пробував деформувати плату і натискати на мікросхеми, реакції на це немає.
Можна спробувати потестити програмно. Я б заповнював памʼять послідовно яким-небудь псевдорандомним паттерном з довжелезним періодом, потім генерував цей же паттерн і порівнював із прочитаними значеннями. Може і готові тести є.
Хоча не знаю, таймінги при читанні ядром і LTDC теоретично можуть і відрізнятись.
Може просто погано пропаяний контакт шини адреси?
Візуально все припаяно добре, пробував деформувати плату і натискати на мікросхеми, реакції на це немає.
З'являються у випадковому місці там де на екрані зображені чорні кола, там де екран по горизонталі повністю залитий зеленим не з'являються.
...
якщо уважно придивитись на сам артефакт, то здається ніби артефактні пікселі читаються з пам'яті по неправильній адресі.
Так, схоже саме на це. Наскільки видно з фотографії, зсунуто ліворуч на два пікселя, ніби в 1-му біті адреси (при нумерації з 0) замість одиниці читається нуль. Може просто погано пропаяний контакт шини адреси?
Поки не дуже зрозуміло, як воно виглядає в динаміці. Схоже на "сніг" CGA? Скільки часу такий піксель тримається, один кадр чи довше?.
Ні на сніг не схоже, і так тримається десь приблизно один кадр, сфотографувати було важко. З'являються у випадковому місці там де на екрані зображені чорні кола, там де екран по горизонталі повністю залитий зеленим не з'являються.
А якщо виводити з внутрішньої SRAM, а не з SDRAM?
При роботі з SRAM таких артефактів немає.
Може FMC невірно сконфігурований для цієї мікросхеми SDRAM.
Мікросхема SDRAM (IS42S16400J) ніби як стандартна для всіх плат з таким мікроконтролером. Конфігурацію взяв в того ж самого автора на GitHub, тому в правильності не впевнений. Думаю потрібно збільшити таймінг там де SDRAM перемикає свою лінію даних на вихід, щоб збільшити час зчитування. Хоча якщо уважно придивитись на сам артефакт, то здається ніби артефактні пікселі читаються з пам'яті по неправильній адресі.
Тепер з'явилась нова проблема, з артефактами (фото).
Поки не дуже зрозуміло, як воно виглядає в динаміці. Схоже на "сніг" CGA? Скільки часу такий піксель тримається, один кадр чи довше?
З'являються і зникають на екрані навіть коли у пам'ять нічого не записується.
А якщо виводити з внутрішньої SRAM, а не з SDRAM?
SDRAM завжди "записується" через refresh, але іноді це прозоро для зовнішнього інтерфейса.
Якщо зменшити швидкість роботи пінів що підключаються до пам'яті з 50мГц до 25мГц то вони починають з'являтися набагато рідше, але зовсім не зникають.
Може FMC невірно сконфігурований для цієї мікросхеми SDRAM.
Ще виявив що якщо підключити щуп осцилографа до будь якої лінії даних SDRAM, то кількість таких артефактів різко зростає.
Екранування та заземлення мали би допомогти.
Тепер з'явилась нова проблема, з артефактами (фото). З'являються і зникають на екрані навіть коли у пам'ять нічого не записується. Якщо зменшити швидкість роботи пінів що підключаються до пам'яті з 50мГц до 25мГц то вони починають з'являтися набагато рідше, але зовсім не зникають. Ще виявив що якщо підключити щуп осцилографа до будь якої лінії даних SDRAM, то кількість таких артефактів різко зростає.
Здається джитер поборов. Зображення чисте, сигнал з тактового виходу тепер теж чистий.
Всьому вина це помилка в коді налаштувань таймінгів. Потрібно було в кожному параметрі добавити -1, як то вимагає суворий reference manual
Аналіз осцилограми мав би показати розбіжність фактичних таймінгів з очікуваними. Особливо при порівнянні з еталонним сигналом.
Так, зазвичай регістри лічильників містять "верхнє" значення, при досягненні якого лічильник обнуляється, а не тривалість циклу. ST відомі "якістю" своєї документації. В коді HAL же просто "configures the number of Horizontal synchronization width", і тільки в RM "number of Horizontal Synchronization pixels minus 1".
Здається джитер поборов. Зображення чисте, сигнал з тактового виходу тепер теж чистий.
Всьому вина це помилка в коді налаштувань таймінгів. Потрібно було в кожному параметрі добавити -1, як то вимагає суворий reference manual
// Налаштування таймінгів LCD
LTDC_InitStruct.LTDC_HorizontalSync = (HSYNC_Width-1);
LTDC_InitStruct.LTDC_VerticalSync = (VSYNC_Width-1);
LTDC_InitStruct.LTDC_AccumulatedHBP = (HSYNC_Width + HBP)-1;
LTDC_InitStruct.LTDC_AccumulatedVBP = (VSYNC_Width + VBP)-1;
LTDC_InitStruct.LTDC_AccumulatedActiveW = (HSYNC_Width + HBP + Active_Width)-1;
LTDC_InitStruct.LTDC_AccumulatedActiveH = (VSYNC_Width + VBP + Active_Height)-1;
LTDC_InitStruct.LTDC_TotalWidth = (HSYNC_Width + HBP + Active_Width + HFP)-1;
LTDC_InitStruct.LTDC_TotalHeigh = (VSYNC_Width + VBP + Active_Height + VFP)-1;