LPC1788, MatrixARB Опции

[ar__systems]

Вопрос по регмстру matrixarb.

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

Т.е. вроде очевидно что FIFO экрана время от времени не успевает получать данные. Ок. В даташите нашел регистр MATRIXARB, в котором написано, что чтобы отдать приоритет дисплею надо туда записать 0x00000c09. Записал, в этом случае все довольно быстро виснет.

Дефолтное значение регистра по даташиту - 0x0000000D
Попробовал записать его - все равно виснет
Посмотрел, что там было до моей записи - 0x00010004

Это странно, т.к. до сегодняшнего дня регистр matrixarb не был определен в LPC177x_8x.h там было RESERVED на его месте.

Вторая странность, что вот этот 16ый бит по даташиту должен быть всегда нулем:

Код

Table 27. Matrix Arbitration register (MATRIXARB- 0x400F C188) bit description
11:10 PRI_LCD LCD DMA priority. 0
13:12 PRI_USB USB DMA priority. 0
15:14 - Reserved. Read value is undefined, only zero should be written. NA
16 ROM_LAT ROM latency select. Should always be 0. 0
31:17 - Reserved. Read value is undefined, only zero should be written. NA

Возникает подозрение, может я не туда пишу?

Код

xprintf("& LPC_SC->MATRIXARB %x\n", &(LPC_SC->MATRIXARB) );
xprintf("  LPC_SC->MATRIXARB %x\n", LPC_SC->MATRIXARB );

и на выходе:

Код

& LPC_SC->MATRIXARB 400fc188                                                    
  LPC_SC->MATRIXARB 10004

У кого-то есть идеи, что происходит?

Поставил breakpoint на ResetISR, значение этого регистра такое же, 0х10004
Записал туда 0x10C09, никакого эффекта

[DpInRock]

Т.е. вроде очевидно что FIFO экрана время от времени не успевает получать данные.

Совсем неочевидно.
Чтобы стало очевидно, надо проверить FIFO_underflow_interrupt бит.

А после чего рассчитать интенсивность потока на LCD (в соответствии с настройками LCD) и сравнить с потоком выборки команд, раз уж LCD и память команд сидят на одном интерфейсе.

А посмотрев результат - перенести команды обращения к буферу во внутренний флэш или еще лучше - во внутреннюю SRAM.

[ar__systems]

Совсем неочевидно.
Чтобы стало очевидно, надо проверить FIFO_underflow_interrupt бит.

Не очевидно? А какие другие варианты? Вопрос не о том, что куда переносить. Вся программа и так во внутреннем флеше, во внешнем флеше только данные.

Экран 800*600*8бит, 50Гц = 24МБ/сек. Шина 60MГц,32бит SDRAM = 240MB/sec
Вопрос только в правильной настройке matrix arbitration

[DpInRock]

А какие другие варианты?

Масса. (Более прозаичных. Ключевое слов V-Sync, например. Да и по горизонтали тоже могут быть проблемы... Хотя трудно судить не видя картинку...)
В общем-то, это ваше, конечно, дело.
---
А если нет уверенности "туда ли я пишу"
*( ( volatile unsigned long *) 0x400FC188) ) = 0xC09 (0xC09 - как раз рекомендовано даташитом в вашем случае).

Но разбираться в стиле "очевидно-не очевидно" - можно крайне долго.
З.Ы. Ну и арбиртраж я бы устанавливал из когда где-нибудь внутри, еще до настройки всего остального.
P.S.2 Ну и скорость развертки LCD тоже можно поменять. К примеру по ходу работы и посмотреть что будет...

Сообщение отредактировал DpInRock - Mar 8 2014, 05:39

[ar__systems]

Масса. (Более прозаичных. Ключевое слов V-Sync, например. Да и по горизонтали тоже могут быть проблемы... Хотя трудно судить не видя картинку...)

Что с ним может быть, с V-Syncом, и как это может быть связано с моими обращениями к внешнему флешу?

[DpInRock]

Возможные причины вашей проблемы можно обсуждать вечность. Это неинтересно.
Если есть возможность узнать точно - теоретизировать просто глупо.
Узнайте состояние FIFO_underflow.

[ar__systems]

NXP ответил, что у них баг в документации. Бит 16 должен быть всегда 1. Как это возможно, я что, первый попробовал использовать этот регистр?

[DpInRock]

У других все нормально с арбитражем... Да и у вас - тоже.