реклама на сайте
подробности

 
 
> Data-abort на LPC3250, вылетает при определённых условиях
scorp2011
сообщение Sep 25 2011, 09:55
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 72
Регистрация: 29-01-11
Пользователь №: 62 559



Здравствуйте. У меня такая проблема, никак не могу понять от чего.
Система с SDRAM один в один как на плате Phytek, две 16-бит SDRAM как 32бит память.
Код вертится в SDRAM, RTOS Segger/PowerPac, компилятор IAR 6.20. LCD контроллер выводит с SDRAM 320x240 16-бит.
Инициализация контроллера и MMU из примера Seggera. Если Idle задачу ставлю в iRAM в таком виде(int32 LowPowerEnable=1 в SDRAM):
Код
__ramfunc void OS_Idle(void) {     // Idle loop: No task is ready to exec
  while (1)
  {
    if((LowPowerEnable != 0) && ((PWR_CTRL&4)!=0))
    {
      PWR_CTRL &= 0xFFFFFFFB;//идём в Direct Run
      EMCDynamicRefresh = 0x6;         // (64ms/8192)*13MHz/16
    }
  }
}

то черен несколько секунд исполнения программы контроллер вылетает на дата аборт(иногда и на аборт инструкции) именно в
Idle процессе чаще всего в одном месте:
Код
    399              if((LowPowerEnable != 0) && ((PWR_CTRL&4)!=0))
   \                     OS_Idle:
   \                     ??OS_Idle_0:
   \   00000000   ........           LDR      R0,??DataTable17
   \   00000004   000090E5           LDR      R0,[R0, #+0]
   \   00000008   000050E3           CMP      R0,#+0
   \   0000000C   FBFFFF0A           BEQ      ??OS_Idle_0
   \   00000010   ........           LDR      R0,??DataTable17_1;; 0x40004044
   \   00000014   000090E5           LDR      R0,[R0, #+0]!!!!!!!!!!!!!!!!!!!!!Вылетает тут
   \   00000018   040010E3           TST      R0,#0x4
   \   0000001C   F7FFFF0A           BEQ      ??OS_Idle_0
    400              {
    401                PWR_CTRL &= 0xFFFFFFFB;
   \   00000020   ........           LDR      R0,??DataTable17_1;; 0x40004044
   \   00000024   000090E5           LDR      R0,[R0, #+0]!!!!!!!!!!!!!!!!!!!!!или тут
   \   00000028   0400D0E3           BICS     R0,R0,#0x4
   \   0000002C   ........           LDR      R1,??DataTable17_1;; 0x40004044
   \   00000030   000081E5           STR      R0,[R1, #+0]
   \   00000034   F1FFFFEA           B        ??OS_Idle_0
    402                //EMCDynamicRefresh = 0x6;         // (64ms/8192)*13MHz/16
    403              }


При этом в R0 совсем не адрес PWR_CTRL. Это не проблема выравнивания получается как обычно бывает, а ошибка доступа к несуществуещему адресу
Да ещё, имеется
Код
void myHookSub( void )
{
  PWR_CTRL_bit.HCKL_FORCE = 0;//возвращаемся в Run mode
  EMCDynamicRefresh = 0x32;
}

Тоесть таким образом я организовал режим пониженного потребления в Idle.
Заметил если отключить DCACHE то проблема исчезает, но экран перерисовывается очень медленно.
Если Idle перенести в SDRAM то тоже перестаёт вылетать. Если LowPowerEnable обьявляю в iRAM тоже проблема вроде уходит.
Если контроллер кручу всегда в Direct Run режиме(13 Мгц кварц), или в Run то тоже не вылетает.
Создаётся впечатление что кэширование както конфликтует в Direct Run и iRAM. Вообщем я запутался. Ещё эта проблема
усугубляется если в настройках PLL на Периферию я даю деление 15.5 а не 16(так я подстроил частоту чтоб при переключении
Direct Run UART работал на той же частоте, почемуто PLL не точно на 16 умножает).
Конечно есть решение не крутить програму в iRAM и режим пониженного потребления сделать черех FORCE_HCLK(так тоже всё нормально,
но дело в том что я собираюсь переводить контроллер в STOP который через Direct Run и в iRAM(SDRAM в авторефреш загоняю без проблем)
и тоже клинит. Да и хочу понять почему не работает как положенно. Пользуюсь J-Link, J-Trace нет.

Сообщение отредактировал scorp2011 - Sep 25 2011, 10:05
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
DpInRock
сообщение Sep 25 2011, 16:54
Сообщение #2


Гуру
******

Группа: Участник
Сообщений: 2 254
Регистрация: 4-05-07
Из: Moscow
Пользователь №: 27 515



Цитата
м я LCD отключаю, и жду пока SDRAM перейдёт в autorefresh

Из приведенного кода и ваших объяснений этого не следует.
--
В итоге ваша проблема звучит так:
В режиме с пониженной частотой процессора возникают проблемы. ТОчка.

Вы, насколько я понимаю, применяете метод шамана. Пытаетесь код перемещать с места на место.
А следует просто найти конкретную причину.
Там всего два регистра, которые этим заведуют.
И нужно отыскать в какой комбинации или при каком переходе нарушается работа. Этот метод называется "научный тык". Намного эффективнее шаманства.
--
Насколько я вижу рисунок в мануале, вы не можете снизить частоту процессора не снизив частоту периферии. Либо памяти.
Снижать частоту памяти нельзя. Частоту периферии - тоже - иначе как экран будет работать?

Это на первый взгляд. Либо как-то извращаться надо.
Т.е. токо один выход . Запитать проц PERIPH_CLK. Который можно на 32 поделить. Это если экран от HCLK работает.




Сообщение отредактировал DpInRock - Sep 25 2011, 17:13


--------------------
On the road again (Canned Heat)
Go to the top of the page
 
+Quote Post
scorp2011
сообщение Sep 25 2011, 18:22
Сообщение #3


Участник
*

Группа: Участник
Сообщений: 72
Регистрация: 29-01-11
Пользователь №: 62 559



Цитата(DpInRock @ Sep 25 2011, 20:54) *
Из приведенного кода и ваших объяснений этого не следует.
--
В итоге ваша проблема звучит так:
В режиме с пониженной частотой процессора возникают проблемы. ТОчка.

Вы, насколько я понимаю, применяете метод шамана. Пытаетесь код перемещать с места на место.
А следует просто найти конкретную причину.
Там всего два регистра, которые этим заведуют.
И нужно отыскать в какой комбинации или при каком переходе нарушается работа. Этот метод называется "научный тык". Намного эффективнее шаманства.
--
Насколько я вижу рисунок в мануале, вы не можете снизить частоту процессора не снизив частоту периферии. Либо памяти.
Снижать частоту памяти нельзя. Частоту периферии - тоже - иначе как экран будет работать?

Это на первый взгляд. Либо как-то извращаться надо.
Т.е. токо один выход . Запитать проц PERIPH_CLK. Который можно на 32 поделить. Это если экран от HCLK работает.

Может я навалил всё в кучу вначале. Забудем на время про autorefresh у SDRAM и STOP режим процессора. Есть task Idle в RTOS во время которой я процессор перевожу в Direct Run. PERIPH_CLK что в Run что в Direct Run работает с частотой 13МГц(или от SYSCLK или HCLKPLL/16). HCLK в Run работает с частотой 104МГц а в Direct Run естественно 13МГц. Ядро ARM_CLK 208МГц в Run режиме и 13 в Direct Run. Экран разворачивается от внешнего входа поэтому проблем с понижением частоты для экрана нет. SDR SDRAM пожет работать при пониженной частоте ядра(DDR не может), для этого я авторефреш меняю чтоб всё также за 64мс вся SDRAM рефреш сделала.
А на счет научного тыка, так я натыкался до предела, дальше не знаю куда тыкать поэтому и спрашиваю. Если процессор постоянно в Run режиме то нет проблем. Если постоянно в Direct Run то тоже нормально. А вот как только переключать начинаю для понижения потребления то вылетает, причём не сразу а черех несколько секунд.
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 20th July 2025 - 14:03
Рейтинг@Mail.ru


Страница сгенерированна за 0.01417 секунд с 7
ELECTRONIX ©2004-2016