LPC4337, свой загрузчик. Инициализация SDRAM, мешает работе приложения Опции

[haker_fox]

Добрый день!
Задаю вопрос по просьбе своего коллеги. Они изготовил бутлоадер, который принимает приложение по каналу связи, и записывает его во внутреннюю флеш микроконтроллера. Само приложение 100% работает. Но вот нюанс. И приложение, и бутлоадер инициализируют внешнюю SDRAM, которую каждый использует для себя. И вот на старте инициализации SDRAM приложением проц то-ли улетает куда-то, то-ли зависает. Вопрос: почему такое может происходить. Ведь при повторной инициализации EMC приложением, данных, используемых кем-либо, нет. Это какая-то особенность контроллера памяти?

[Arlleex]

Какой из указателей? Про переключение режима CPU конечно забыли?
И про сброс периферии тоже.

А при чем тут указатели стека и режим CPU? Загрузчик обязан обеспечить обновление ПО и (если необходимо) переход на приложение. Приложение не должно знать о существовании загрузчика, поэтому компилируется ровно так же, как и без загрузчика (только поправить ld-скрипт и вначале приложения сместить таблицу векторов. Ну или перед переходом на приложение в загрузчике ее сместить). При старте МК с загрузчиком:
1. Проверяется тип сброса - если программный, то (в моем случае) это только означает, что был запрос обновления ПО из приложения, если нет - JumpToApplicatioin().
2. Инициализируется периферия, необходимая для приема прошивки.
3. Принимается прошивка, сравниваются соответствующие контрольные суммы и т.д.
4. Деинициализируется периферия в случае успешного обновления ПО.
5. JumpToApplication().

Код

void HW_JumpToApplication(void)
{
unsigned int pFunction = *((volatile unsigned int *)(APPLICATION_BASE_ADDRESS + 4));
void (*UserApplication)(void) = (void (*)())pFunction;
__set_MSP(*(volatile unsigned int *)APPLICATION_BASE_ADDRESS);
UserApplication();
    
return;
}

О каком переключении CPU идет речь? И о каком стеке? После сброса CPU всегда использует основной стек и находится в режиме потока с привелегированным доступом, поэтому загрузчик инициализирует именно MSP.

Внутри целевого прилоежния первым делом сдвигается таблица векторов прерываний (если это не сделал загрузчик) и поехали.
Или Вы о чем?

Сообщение отредактировал Arlleex - May 24 2018, 05:08

[jcxz]

1. Проверяется тип сброса - если программный, то (в моем случае) это только означает, что был запрос обновления ПО из приложения, если нет - JumpToApplicatioin().
...

Видимо Вы на практике никогда не писали реально работающий в боевых условиях бутлоадер, умеющий обновлять прошивку...
Внимание вопрос:
Если после приёма прошивки (и записи её во флешь с установленным флажком "имеется новая прошивка") выполняется Ваш программный сброс, загрузчик делает как Вы написали и переходит к пункту 2 вашего списка.... и в этот момент происходит случайный сброс (например - сработал супервизор питания из-за помехи по питанию). Что получится? Да - прошивка не обновится уже никогда.
А если сброс произошёл во время прошивки? А если 100 сбросов произошло во время прошивки? ...подумайте.
Нормально написанный бутлоадер должен после любого типа сброса проверять флаг наличия новой прошивки и начинать прошивку (или продолжать её с момента обрыва) и проводить до тех пор, пока новая прошивка не будет полностью прошита и снят флаг "имеется новая прошивка". И только тогда может выполнять переход на рабочее ПО.
И новая прошивка и флаг "имеется новая прошивка" должны находиться в энергонезависимой памяти.

2. Инициализируется периферия, необходимая для приема прошивки.

пункт 2 замечаний:
При таком алгоритме загрузчик должен быть рассчитан на старт как после обычного аппаратного сброса так и после передачи управления из ПО с произвольным состояние регистров/режима процессора и периферии. Т.е. - инициализация его должна быть более сложной. А на кой ляд?? Почему не привести всё к начальному состоянию и упростить инициализацию при старте загрзучика? Так будет гораздо меньше кода (что для загрузчика очень важно, так как он:
а) часто должен быть как можно меньше;
б) должен быть (обязательно!) как можно более простым, чтобы исключить возможность бага в нём, который потом уже невозможно будет устранить удалённой перепрошивкой.
А в вашем случае получается, что стартовое состояние загрузчика постоянно меняется при изменении основного ПО. Сейчас вы загрузчик отладили и он работает (вроде как стабильно), отправили устройства заказчику, а потом сделали новую версию основной прошивки, которая стала инитить периферию немного по-другому или задействовала новую периферию и ... привет! - загрузчик перестал работать, так как заранее не предусмотрели и не отладили его работу со всеми возможными состояниями периферии/регистров на старте.

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

О каком переключении CPU идет речь? И о каком стеке? После сброса CPU всегда использует основной стек и находится в режиме потока с привелегированным доступом, поэтому загрузчик инициализирует именно MSP.
...
Или Вы о чем?

О том что Вы передёргиваете. Вы писали о передаче управления бутлоадеру без сброса, только поправив некий SP. На что я Вам написал, что кроме SP надо много чего ещё исправить:

Ничего не мешает. Ровно как и ничего не мешает инициализировать указатель стека и перейти сразу на приложение явно.

А после сброса да - состояние МК и стек известны - кто-ж спорит?