Ну вот у меня работать-работает, но при тактировании от SYSCLK треск подмешивается (убирается если CLK немного задержать щупом осциллографа), при тактировании от WSPLL на 16KHz не заводился, на 44 - с песней.

Ну и шум страшный при записи. Буду пробовать питать от отдельного источника, ну и идею Вашу проверю с ресетом, спасибо!

Пробую UDA1380 с ресетом.

Включаю SYSCLK (заодно подается CLKO и WSO), ресет в 1, жду 10мс, ресет в 0, пытаюсь общаться по i2c. Хренвам. На адрес говорит ACK, на первый байт - не говорит. Иногда в других местах почему-то нет ACK.

В даташите явно написано, что по умолчанию после ресета оно тактируется от SYSCLK, у меня тудыть аж 11МГц приходит. И вот как-то странновато она себя ведет.

То, что нет ACK - видно и на логическом анализаторе, и на осциллографе. Подтяжки стоят 10кОм на 3.3 вольта, но там даже и без них с фронтами все нормально. Скорость 30000.

Какая-то странная микросхема.. описания тактирования I2C вообще нет в даташите.

p.s. Выяснилось, что если при старте не давать ей SYSCLK, то она прекрасно общается по I2C, а если клок выдать - то как-то через раз, и практически нет возможности воткнуть туда конфигурацию. Уже и пониже частоту пробовал, то работает, то нет. Непонятно...

... попробуйте переведите графику в "байт-пиксель" - т.е. в палитру 256 цветов - ибо разрешение 800х480 + видеобуфер во внешней SDRAM приводит к тому, что любая другая цветовая схема слишком "тяжелая" и видеовывод "ломается" при .. например - тупом цикле чтения SDRAM - т.е. использования контроллера FMC одновременно LTDC и ядра. Увы ...

т.к. USB3300
- еще один "конкурент" на внешней шине ...

P.S. 32F429I DISCOVERY 2.4" QVGA TFT LCD - "замануха" и там - все хорошо и красиво внутренний SRAM 256 кило обеспечивает полноцвет на этом экранчике совершенно не затрагивая ресурса наружу ...

Сообщение отредактировал DrGluck - Aug 23 2015, 19:52

Это догадка или факт?
Если факт, то как можно это все посчитать?
Имеется в виду, что 800x600x4 байта на пиксель x 2 слоя x 40 кадров в секунду = 146 мегабайт в секунду по DMA. SDRAM у меня 16-битный, то есть получается что оттуда мы берем со скоростью 73 Мб/c.

Слишком много?
С сколько не много? И какая вообще пропускная способность у шины этой?
И как посчитать?

USB3300 вроде бы по "соседней" шине проходить должно и не трогать никого..

RM0090 Reference manual

чудес не бывает ...
А что за "соседняя шина" наружу ? (D0..D7)

P.S. SDRAM - динамическая память. В настройках FMC и "настраивательного" регистра самой микросхемы есть всякие тайминги ... в том числе и обеспечение целостности информации ( рефреш ) ...
Динамическая память

Сообщение отредактировал DrGluck - Aug 23 2015, 20:20

Дык в референс и смотрю, картинка 2, страница 62.
Там вроде FMC <-> LCD-TFT и USB_OTG <-> SRAM по отдельным узлам проходят и не пересекаются нигде..

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

Там сама плата сделана через одно место. UDA1380 - стоит одна микросхема (HN), схему дают для другой (TT).
Питалово сделано так, что при записи звука жестокий шум и рокотание, питаешь UDA1380 от батареек - тишь и гладь, ибо штатно все питается от одного мелкого 1117.

Короче, там неясно, то ли китайцы плату неправильно развели, то ли глюки ST USB библиотеки (адъ!), то ли я в лыжи обутый.

В общем, воткнул я USB_OTG_HS в режиме FS, пока вроде бы работает, звук на флешку пишет, правда, несжатый, но тут, как я понимаю, выше IMA не прыгнешь (MP3 кодера не нашел от слова "вообще").

Буду пытаться освоить высокие технологии ULPI на какой-нибудь другой плате, разведенной человеками для человеков.

"Там вроде FMC <-> LCD-TFT и USB_OTG <-> SRAM по отдельным узлам проходят и не пересекаются нигде.." ©

- дык это ВНУТРЕННИЕ ШИНЫ ... А физически то как на платке все зацеплено ?
Картинка "правильная" - это пока ядро свои гарантированные 60% ( если не ошибаюсь ) ресурса от тов. Арбитрова не получает ( см. выше про тупой цикл чтения SDRAM )

P.S. "меня терзают смутные сомнения" ... USB_OTG - внутренняя компонента МК ... page 1235 "34.3.1 OTG full-speed core" © - нафига еще внешний контроллер USB ?

Сообщение отредактировал DrGluck - Aug 23 2015, 21:26

Физически на платке это тоже разные ноги. 176 ног, есть куда развернуться.
Про USB_OTG - дык внутри тока контроль, PHY внешний ему нужен для high speed.

Да, действительно ULPI выводятся на отдельные ноги ( альтернативная функция ) - OTG_HS_ULPI_xxxxxx.
Тогда подсказка №2 - уточнить какие ноги задействует графическая библиотека.
Смотрим схему Open429I-C
страница 1 (USB HS ULPI) ... берем навскидку PB0 (DATA1)
Смотрим доку на проц - "Table 12. STM32F429xx alternate function mapping"
TIM3_CH3 / TIM8_CH2N/OTG_HS_ULPI_D1/ETH_MII_RXD2 /TIM1_CH2N /LCD_R3 /EVENTOUT
Учитывая встречающиеся казусы с библиотеками от ST есть смысл просмотреть исходники.
В своем проекте я находил один момент как раз связанный с инициализацией LTDC :
HAL_LTDC_MspInit
.... для пина PB1 они снова задействовали GPIO_AF14_LTDC хотя должны были использовать AF9 !

P.S. еще бы обратил внимание ( исходя из описанных в самом начале симптомов ) на :
PB5 - OTG_HS_ULPI_D7 - FMC_SDCKE1
PC0 - OTG_HS_ULPI_STP - FMC_SDNWE
PC2 - OTG_HS_ULPI_DIR - FMC_SDNE
PC3 - OTG_HS_ULPI_NXT - FMC_SDCKE0

Сообщение отредактировал DrGluck - Aug 24 2015, 07:21

Проверил. Там везде AF14 и ноги совпадают.
FMC/LTDC везде работает нормально, для них везде AF12/AF14. Если бы были ошибочные - не работало бы или работало бы с глюками.

ULPI может быть только AF10. D0 там PA3.
Но я учту, спасибо

... хорошо, будем ждать инфы о причине глюка ...