[dOb 8]

Здравствуйте.

согласно Datasheet Table 4-5. Start-up timings of Operating conditions

Огромная величина 143 ms

Хотелось бы уменьшить до приемлемого значения.

Предлагается следующее решение:

На вход OSCIN подать внешнюю частоту 48МГЦ.

Отключить все PLL, настроить HCLK = 48МГЦ

Насколько можно уменьшить Start-up timing?

Изменено 14 апреля, 2023 пользователем haker_fox
Для GigaDevice у нас есть свой подфорум.

[Arlleex 131]

Думаю, никак.

Там же сначала стартует Boot ROM, который копирует из Flash в ОЗУ. И он знать ничего не знает о Ваших кварцах.

[jcxz 184]

32 минуты назад, Arlleex сказал:

Там же сначала стартует Boot ROM

Он всегда стартует что-ль? И именно он копирует FLASH->RAM, не аппаратно копируется?

В мануале указано:

Если выбрать 000 (Main Flash Memory) - тоже будет копировать?

А если выбрать внешнюю NOR FLASH (010) и повесить туда параллельную флешку и расположить свой boot-код там - может так получится быстро запустить этот код?

 

PS: И вопрос к ТС - Вы мануал вообще читали? Особенно - в части boot-modes?

Извините за такой вопрос, но как показывает практика - большинство вопрошающих тут мануалы даже не открывают.... 

[Arlleex 131]

25 минут назад, jcxz сказал:

Он всегда стартует что-ль? И именно он копирует FLASH->RAM, не аппаратно копируется?

Мне без разницы, кто там и как запускается, главное, что есть процесс копирования из Flash в ОЗУ и сугубо на мой личный взгляд, было бы логично делать это тем же припаянным поверх флешки CPU, а не изобретать аппаратный копировальщик))

Опять же, GD микроконтроллеры мимикрируют под STM, но на самом деле внутри чипа скорее флешка с припаянным процессором, а не наоборот. И GD выполняет код (в итоге) из ОЗУ. Это ОЗУ - отдельное, "выглядит" как флеш-область с адреса 0x08000000. Поэтому для GD нет необходимости настраивать такты доступа к Flash - доступ к инструкциям и данным будет однотактный.

[jcxz 184]

6 минут назад, Arlleex сказал:

было бы логично делать это тем же припаянным поверх флешки CPU

Тогда получается - выбрав boot-опцию "Main Flash Memory" можно избежать копирования и сразу запустить свой код? Такое простое решение...

[Arlleex 131]

9 минут назад, jcxz сказал:

Тогда получается - выбрав boot-опцию "Main Flash Memory" можно избежать копирования и сразу запустить свой код? Такое простое решение...

Нет-нет. Main Flash Memory в качестве опции загрузки это, я полагаю, и есть мимикрирование под STM. Имеется в виду, что управление будет передано образу, записанному во Flash. Но никто не запрещал им вместо Flash, расположенной по 0x08000000, запаять RAM, при старте копировать в эту RAM содержимое Flash (которая существует как отдельная чуть ли ни микросхема-кристалл поверх кристалла CPU) и запустить управление оттуда. CPU то какая разница, что физически за память будет по 0x08000000? Никакой.

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

Естественно, этот регион более быстрой памяти кэшируется не весь, о чем явно указано в даташите

Цитата

3.2. On-chip memory

 Up to 3072 Kbytes of Flash memory, including code Flash and data Flash.

 The region of the MCU executing instructions without waiting time is up to 512K bytes (in case that Flash size equal to 512K, all memory is no waiting time). A long delay when CPU fetches the instructions out of the range.

 192 KB of SRAM.

 

[jcxz 184]

1 час назад, Arlleex сказал:

Но никто не запрещал им вместо Flash, расположенной по 0x08000000, запаять RAM, при старте копировать в эту RAM содержимое Flash

Я понимаю, что копируется. Вопрос - при каких установках boot-конфигурации это выполняется? И есть ли такие, при которых не выполняется?

Например: при конфиге '010' - выполняется копирование или нет? Если нет, то можно его использовать (как писал выше).

[Arlleex 131]

1 час назад, jcxz сказал:

Например: при конфиге '010' - выполняется копирование или нет? Если нет, то можно его использовать (как писал выше).

Ну, возможно. Скорее всего это можно проверить только экспериментально.

[dOb 8]

В 14.04.2023 в 13:47, Arlleex сказал:

Скорее всего это можно проверить только экспериментально.

Наконец то получил старткит.

Эксперимент удивил: Время готовности не зависит от настроек PLL  и всегда составляет 142мс.

Методика: В файле system_gd32f4xx.c поочерёдно раскомментировал строки

__SYSTEM_CLOCK_IRC16M

__SYSTEM_CLOCK_HXTAL

...

[Arlleex 131]

То, что от PLL не зависит это итак понятно было (мне, по крайней мере) еще в начале топика.

[asen 0]

интересно а у контроллеров AT32F407 тоже еть внешняя флеха кешируется никто не в курсе ?

[Obam 30]

интересно а у контроллеров AT32F407 тоже еть внешняя флеха кешируется никто не в курсе ?
У них такая же "шляпа" со стартом?
Зачитайте нам их RefMan (((-;

PS: вообще конечно, дикость - ~150мс неупраляемое устройство под питанием \-8<Ж

Изменено 18 марта пользователем Obam

[asen 0]

я думаю нет тут ничего страшного просто надо принимать во внимание при создании схемотехники 

[VladislavS 29]

+1. Что 150 мкс, что 150 мс - суть одно и то же. При внутрисхемной прошивке вообще секунды контроллер в ауте. Схемотехника должна это предусматривать.

[mantech 34]

В 14.04.2023 в 11:12, Arlleex сказал:

которая существует как отдельная чуть ли ни микросхема-кристалл поверх кристалла CPU

Круто)) Это такой суровый китайский SIP?)))