Перейти к содержанию
    

Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

Должен, но он этого не делает!

Все программаторы, если они хотят счтитать или проверить первые 64 байта флеша, при помощи команд ISP грузят в ОЗУ подпрограмму которая мапит флеш на адрес 0! После этого все работает как ожидается.

 

Да и кстати это, по крайней мере не у всех серий, не ROM - а флешь. У первых серий это вообще была последняя страница флеша. Для некоторых серий NXP выкладывал апгрейд бутлоадера.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Все программаторы, если они хотят счтитать или проверить первые 64 байта флеша, при помощи команд ISP грузят в ОЗУ подпрограмму которая мапит флеш на адрес 0! После этого все работает как ожидается.

Ну что-ж - вполне правдоподобно. Значит ТС может сделать то же самое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кроме того если нужно ускорить прошивку. можно загрузить в ОЗУ подпрограмму которая принимает данные из UART по другому протоколу - например просто принимает напр 4 кб данных и возвращает контрольную сумму для проверки и возвращается в бутлоадер, а программатор потом вызывает команду записи флеша, потом опять подпрограмму загрузки для следующей старницы и т.д.

Причем подпрограмму можно грузить один раз ни бутлоадер ни IAP не портят память, они используют те области которые указаны в даташите.

 

Ускорение полезно для больших прошивок, особенно когда к чипу через USBUART идет подключение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну что-ж - вполне правдоподобно. Значит ТС может сделать то же самое.

 

Поподробнее, если можно....пока что не понимаю как конкретно пошагово это делать...какие команды и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

загрузить в ОЗУ, например по адресу

0x40000200

24 байта

(0x0C, 0x00, 0x9F, 0xE5, 0x01, 0x10, 0xA0, 0xE3, 0x00, 0x10, 0x80, 0xE5, 0x0E, 0xE0, 0x81, 0xE1, 0x1E, 0xFF, 0x2F, 0xE1, 0x40, 0xC0, 0x1F, 0xE0,)

 

Потом дать бутлоадеру команду

"G 1073742336 A"

 

код этот не очень "красивый", взят ЕМНИП снифером из первого филисовского программатора.

     LDR     R0, =0xE01FC040   
     MOV     R1, #1            
     STR     R1, [R0]          
     ORR     LR, R1, LR        
     BX      LR

 

но тут оптимизации не к чему :) Работает вроде на всех LPC2xxx.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

но тут оптимизации не к чему :) Работает вроде на всех LPC2xxx.

На всех, у которых ROM-код исполняется в Thumb. :-)

 

ЗЫ: Его можно оптимизировать по размеру, переписав в Thumb. :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На всех, у которых ROM-код исполняется в Thumb. :-)

 

ЗЫ: Его можно оптимизировать по размеру, переписав в Thumb. :-)

А у всех LPC ARM7 boot код в THUMB, а что IAP (который часть boot rom) в THUMB - так явно в даташите указано.

 

Инструкция

ORR LR, R1, LR

лишняя, если конечно в какой то версии бутлоадера не было баги в реализации команды G.

 

А так можно смело в THUMB запускать, кстати удобно тесты железа запускать еще до прошивки.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Думал что на этом эпопея закончится, ан нет...

 

Новый виток: перед тем как шиться выполняю из оперативной памяти код, который скинул форумчанин KRS, получаю всю память в FF как и желаю, пишу первый блок в 256 байт, он записывается как положено, потом дописываю все остальное (всего чуть больше килобайта). Записываемая программа должна моргать диодом с периодом в 1-2 секунды. Что происходит по окончании прошивки: диод начинает моргать циклично, но период увеличен раз так в 10-20, и после выключения-включения питания первые 64 байта опять переписываются как им удобно и код перестает работать.

 

Что здесь можно предпринять?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

и после выключения-включения питания первые 64 байта опять переписываются как им удобно и код перестает работать.

Именно переписываются? Или все таки это бутлоадер туда отмаплен?

 

Контрольная сумма векторов прерываний посчитана?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если контрольная сумма векторов прерываний не посчитана, чип будет переходить в бутлоадер в любом случае!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Именно переписываются? Или все таки это бутлоадер туда отмаплен?

 

Контрольная сумма векторов прерываний посчитана?

 

Я думал, что в готовой прошивке все должно быть посчитано....

 

Вот что в даташите написано по этому поводу

post-84635-1428480740_thumb.png

 

Как в таком случае самому подсчитать и записать куда надо эту контрольную сумму?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При записи по 0 адресу:

        uint32_t s;
        s=((uint32_t*)buf)[0]+
            ((uint32_t*)buf)[1]+
            ((uint32_t*)buf)[2]+
            ((uint32_t*)buf)[3]+
            ((uint32_t*)buf)[4]+
            //((uint32_t*)buf)[5]+ !!skip!!
            ((uint32_t*)buf)[6]+
            ((uint32_t*)buf)[7];
        ((uint32_t*)buf)[5]=-s;

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...