Keil LPC1769 нехватка RAM(?), Данные после сборки проекта вмещаются в RAM но не всё так просто. Опции

[Sv9t]

Доброго времени суток.
Прошу прощения, если вопрос глупый, однако спросить больше негде.

Есть программа, которая должна быть запущенна через RTX Keil на LPC1769. Проект собирается, по выводу линковщика всё выглядит так, будто должно ещё оставаться свободное место и в ПЗУ и в ОЗУ, однако при работе в симуляторе проект циклится ещё где-то при инициализации RTOS. Если же в одной из областей памяти при сборке проекта прописать размер не 0x8000, а 0xA000, то всё работает нормально.
Вопрос такой, это в проекте косяк или действительно не хватает ОЗУ?

[jcxz]

Однозначно - в проекте. Если не хватает памяти, проект не должен собираться.

[Sv9t]

Однозначно - в проекте. Если не хватает памяти, проект не должен собираться.

Хорошо, наверное так. Но тогда почему добавленные 8кб исправляют ситуацию? Как разобраться в чём ошибка? В отладчике проект зацикливается ещё до выполнения функции SystemCoreClockUpdate в файле system_LPC17xx.c, после того, как уже вышел из SystemInit. При этом от размера указанной при сборке доступной RAM меняется место, где проект зацикливается, но он всё равно собирается и запускается в отладчике.

Если надо, приложу часть кода из дизассемблера.

[Dron_Gus]

Не все симуляторы правильно симулируют периферию. Кажетс в том же Keil в симуляторе LPC17** циклился на ожидании захвата PLL.

[SyncLair]

Не все симуляторы правильно симулируют периферию. Кажетс в том же Keil в симуляторе LPC17** циклился на ожидании захвата PLL.

Подтверждаю -- сам налетал на такое. Хотя наверное сейчас ошибка исправлена)

[AlexandrY]

после того, как уже вышел из SystemInit.

Где в RTX такая функция "SystemInit"?
Есть только os_sys_init , и из нее не выходят.

[Sv9t]

Где в RTX такая функция "SystemInit"?
Есть только os_sys_init , и из нее не выходят.

В файле system_LPC17xx.c строка 507. В ней как раз и происходит ожидание захвата PLL, как писал Dron_Gus.

Проблема в том, что из вывода дизассемблера не понятно какой части когда программы это дело соответствует, и как это исправлять. Где-то читал, что стек начинается с конца ОЗУ и растёт вниз. Может быть такое, что стек и данные в ОЗУ пересекаются? Это бы объяснило, почему увеличение размера ОЗУ помогает. Если да, то как проверить и исправить?

[Dron_Gus]

Если вы увеличиваете размерв ОЗУ за пределы физической памяти, то и стек попадает на несуществующую память. Очевидно, что правильно это работать не будет. Либо будет крэп читаться либо Hard Fault случиться. Как это будет работать на симуляторе - неизвестно.
Сделайте выход из цикла ожидания по таймауту. Или вообще не ждите лока. Я думаю, симулятору на это пофиг.

[AlexandrY]

В файле system_LPC17xx.c строка 507. В ней как раз и происходит ожидание захвата PLL, как писал Dron_Gus.

Проблема в том, что из вывода дизассемблера не понятно какой части когда программы это дело соответствует, и как это исправлять. Где-то читал, что стек начинается с конца ОЗУ и растёт вниз. Может быть такое, что стек и данные в ОЗУ пересекаются? Это бы объяснило, почему увеличение размера ОЗУ помогает. Если да, то как проверить и исправить?

В Keil-е по умолчанию стек растет вверх, а системный heap вниз. При плохом раскладе они наезжают друг на друга.
Как точно используется системный heap скрыто в библиотеках компилятора ARM.
Обычно самые не очевидные и тяжелые проблемы бывают с ним. Поэтому рекомендую исследовать его пространство на предмет засорения, а сперва увеличить его.
Системный стек тоже возможно требует увеличения.

[toweroff]

С RTX бывали проблемы под LPC2000. Девайс мог проработать и час, мог и два, а мог и 5 мин не проработать. Ничего динамически не выделялось, куча не использовалась. А вот увеличил стек на сотню байт - и все прошло.
Сначала верил Кейлу, где он расчитывал макс.глубину вызовов, но, похоже, не все он учитывает. Так что посмотреть на цифру все-таки стОит, но и увеличить ее процентов на 20 не помешает