Еще чуть-чуть и можно избавиться от тяжелого наследия (ассемблера) совсем:



P.S. c меткой main все же не получилось?

Кажется, без ответа остался этот вопрос:

Судя по названиям, символы _etext, _data, _edata и т.п. определены в скрипте линкера и обозначают:
_etext - конец секции .text;
_data - начало секции .data;
_edata - конец секции .data;
_bss - начало секции .bss;
_ebss - конец секции .bss.

Дело близится к завершению))

"Программный загрузчик" при запуске слушает сеть, определяет есть ли устройства которые требуют обновления прошивки. Если таких нет передает управление "Рабочей программе". Если есть, то переводит это устройство в режим аппаратного загрузчика (заводской бутлоадер) и прошивает его.
Дальше по идее нужно перезапустить прошитое устройство. Для этого у аппаратного загрузчика предусмотрена команда "GO". Но, она позволяет прыгать только по адресам кратным 0х10! А Reset_handler у меня находится по адресу, не кратному 0х10. Т.е. сейчас он у меня по адресу 0x01ad. Прыгнуть в него командой аппаратного загрузчика "GO" я смогу, только если он будет по адресу, например, 0x1b0.

Keil позволяет использовать атрибут __attribute__((at(0x10000))) расположения переменных по конкретному адресу, но, к сожалению на функции этот атрибут не распростаняется. Откусывать память в линкере могу только кусками кратными 4 байтам, что не выручает.

Есть ли другой способ "подвинуть" Reset_handler в памяти МК?

Не понимаю, зачем переводить устройство в режим заводского загрузчика, если есть свой?


Опять же зачем использовать Go и тп. Не проще ли подать буту команду reset и он запустит Reset_Handler по какому надо адресу, не глядя на выравнивание.


Это Reset_Handler бута или приложения?


Раз можно кратными по 4 байта, то можно и кратно 16 байтам откусывуть.

Добрый День!
Использую 11с24 и работаю с CAN.
Необходимо организовать выдачу без подтверждения приема. То есть на приемной стороне может отсутствовать приемник.
Смотрю пример "CAN on_chip" из примеров KEIL.

msg_obj.msgobj = 1;
msg_obj.mode_id = 0x123 ;
msg_obj.mask = 0xff;
msg_obj.dlc = 5;
msg_obj.data[0] = 'T';
msg_obj.data[1] = 'E';
msg_obj.data[2] = 'S'; //0x53
msg_obj.data[3] = 'T'; //0x54
(*rom)->pCAND->can_transmit(&msg_obj);

Что нужно добавить?

Если в сети только одно устройство (ACK выставить некому) то передатчик будет отправлять сообщение заново и увеличивать счетчик ошибок (пока не дойдет до ERROR PASSIVE), потом просто будет передавать пока не остановишь принудительно или не появится второе устройство.

Если реально надо выдавать разные фреймы (хотя принимать их все равно не кому) Надо сделать Disable Automatic Retransmission, тогда попытка отправки будет тольо одна! Или надо отменять посылку потом.

Сделал DAR. Сначала долго не работало, я засылал посылку один раз и после инициализации
типа так

а теперь сделал

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

Вот как выглядит моя функция отправки 4-ехбайтового сообщения:


Она рабочая

Убираешь строчку
Если подтверждение не требуется

Вопрос по примеру "NXP secondary bootloader" (документ AN10995).
Программный бутлоадер под конец загрузки новой прошивки во флеш в последнюю ячейку флеша записывает контрольную сумму.
В последующем при всяком запуске микронотроллера он вычисляет действительную контрольную сумму флеш-памяти и значение, которое записано в последней ячейке флеша. Если они совпадают, то рабочая программа корректна и программный загрузчик передает управление рабочей программе.
А как быть если рабочая программа заливается не с помощью программного бутлоадера, а программатором с компа. В этом случае контрольная сумма не записывается и программный бутлоадер посчитает, что рабочая программа битая. Как быть?

Посчитать ее при помощи какой-либо внешней утилиты и добавить той же или другой утилитой в прошиваемый программатором файл. Но не совсем красиво хранить контрольную сумму в последней ячейке флеша. По двум причинам:
1) Вне зависимости от реального размера приложения загрузчик вынужден обсчитывать всю флеш, а это время.
2) При очередном обновлении может захотеться добавить эмуляцию eeprom в последнюю страницу флеша, а эта область уже защищена CRC.
Поэтому я делаю так: в первую же ячейку сразу за векторами линкер записывает размер приложения. CRC кладется сразу же следом за приложением. Загрузчик знает, в какой ячейке лежит размер и считает CRC только реально занятой области флеша.
Поскольку у LPC11 перед ремапом вектора копируются и им не обязательно начинаться с адреса, кратного 256 - можно размер хранить перед векторами.

Так и сделал, тем более и Keil рекомендует такое решение.


Как вы это проделываете? Скаттер файл изменяете?

Получается у вас контрольная сумма записывается не в последнюю очередь? Для максимальной надежности механизма логично писать ее в последнюю очередь.

Я использую gcc и делаю это через его скрипт линкера. В Кейле, насколько мне известно, такую функцию выполняет скаттер-файл. Значит менять надо его, да.
Почему вы так решили? В скрипте линкера под контрольную сумму выделается место после кода и данных, после линковки контрольная сумма вписывается в это зарезервированное место сторонней утилитой.

В общем осталась последняя проблема.
Есть функция Х( ). В МАР-файле она расположена по адресам 0х00000175 - 0х00000189.
Когда я прыгаю в ячейку 0х00000175, вызывается эта функция:



Копирую эти адреса в оперативку по адресу начиная с 0х10000300. Эта область "откушена" в настройках проекта и она не затирается при работе. Дебагером смотрю - скопирована точь-в-точь и не затирается.
Но когда прыгаю по адресу 0х10000300. Эта функция не вызывается.
Что я не учел?

Надо пошагать в отладчике. Версии есть, но излагать их довольно долго (предполагаю, дело в способах адресации внутри функции). Попробуйте поискать в документации ключевое слово ramfunc или похожее на него - оно как раз для этих целей.

а где взять переменную "flagMessageTransmitte" и кто ее выставляет
я так понимаю кто то в прерывании эту переменную выставляет 1
покажите весь пример пожалуйста

В прерывании CAN_TX, которое вызывается автоматически всякий раз при успешной отправке сообщения.
В примере устройство каждые 0.5 сек шлет хартбит.
Отправь SDO-запрос: 0х601 40 00 10 00 00 00 00 00, оно откликнется сообщением с ид-ром 0х581.
Отправь любое сообщение с ид-ром меньше - 0х600 загорится светодиод на выводе 2.1

добрый день!
я смотрю пример и вижу , что вы отправляете сообщение через промежутки времени. при "удачной" передаче заходите в прерывание и выставляете флаг - понятно.
Но как быть если передача тыла так сказать неудачная (датчик отвалился) (ведущим так сказать в моем случае будет контроллер lpc ). Он (контроллер) будет пытаться отослать посылку повторно.
Я сделал так перед передачей выставил флаг "DAR" - отключение повторной передачи и выдаю раз в секунду. контроллер зараза первый 16 секунд не выдает (либо выдает но прерывается но пол посылки потому что не видит датчика ) а потом начинает успешно выдавать раз в секунду.
бит DAR - это как я понял отключение повторной передачи. а мне нужно что бы при отсутствии датчика посылка отправилась и только один раз.
== как это сделать я не знаю ===.
в принципе прерывание может возникнуть и при неправильной передаче это можно распознать но как потом отключить передачу (те есть очистить буфер)

Разобрался в чем дело: Если копирую функцию из флеша в ОЗУ, она не запускается. Если изначально "говорю" линкеру расположить функцию в ОЗУ она старутет нормально. Видимо дело в использовании абсолютной адресации в ассемблерном коде функций