Там же ещё надо, одновременно с записью IVSEL = 1 одновременно записать в IVCE = 0.
Так делали?
в даташите написано установить бит IVCE после этого в течение 4 тактов мк установить бит IVSEL. и такой код предалает даташит
void Move_interrupts(void)
{
uchar temp;
/* GET MCUCR*/
temp = MCUCR;
/* Enable change of Interrupt Vectors */
MCUCR = temp|(1<<IVCE);
/* Move interrupts to Boot Flash section */
MCUCR = temp|(1<<IVSEL);
}
я так пробовал. Но это в самом начале пути, может сначала мешала другая проблема , и когда эти строчки не помогли я их убрал. А теперь возможно первые проблемы я устранил и сейчас может отсутствие этих строчек мешает. Вот собираюсь это еще раз добавить в код. И написано , если IVCE не сбросили, он сам это делает в течение 4 тактов
короче мыслей много, что можно проверить , попробовать, сделать. Надеюсь это даст результат
a. Write the interrupt vector change enable (IVCE) bit to one.
b. Within four cycles, write the desired value to IVSEL while writing a zero to IVCE.
a. Запишите бит разрешения на изменение вектора прерываний (IVCE) равным единице.
b. В течение четырех циклов запишите желаемое значение в IVSEL, одновременно записывая ноль в IVCE.
Попробуйте так
алиса говорит:
VCE (Interrupt Vector Change Enable) — бит разрешения изменения вектора прерывания в микроконтроллерах AVR.
Этот бит используется для разблокирования возможности изменения бита IVSEL. IVCE должен быть установлен, чтобы разрешить изменение IVSEL.
Некоторые особенности работы бита IVCE:
Очищается аппаратно через четыре цикла после установки или при установке бита IVSEL.
Установка бита IVCE отключает прерывания. Они остаются отключёнными до перехода к инструкции, следующей за инструкцией записи в IVSEL.
в даташите это тоже есть .
но попробую конечно и сам занулить
Попробовать не помешает.
Читая даташит , всё вроде просто и должно работать.
Возможно, проблема в другом, или даже не одна))
На кой хрен загрузчику прерывания ??? Посмотрите уже на код других загрузчиков - приход байтов отслеживается через регистры состояния…
Так это же весь код переписывать)
Использование прерываний в области загрузчика подразумевает изменение ivsel сначала в одну, а потом в обратную сторону - иначе основной код будет использовать неверную таблицу векторов.
Если идет отказ от инициализатора ардуино, то и прерывания надо разрешать самому - SEI…
Листинг то выложит кто-нибудь ???
Можно мнение? Спасибо!
Писать в загрузчик поддержку CAN выглядит очень смелым решением.
Гораздо лучше делать режим загрузки прошивки в рамках работы МК, а в загрузчик просто добавить код обновления.
Самое простое - добавить в устройство флэш микросхему, на i2c, загрузить в нее прошивку и положить в тот же ЕЕПРОМ флаг. Перезагрузиться и загрузчик, увидев флаг, перезальёт прошивку. В таком варианте не нужно писать стек КАН в загрузчике, или таблицу прерываний в режиме загрузки рисовать, там добавить то мелочи сущие надо - поддержку и2ц через регистры. И устройство усложнить восьми-ногим чипом, двумя резисторами и конденсатором.
При этом запись прошивки во Флэш делать в рабочем режиме, в котором, как я понимаю, стек КАН и так поддерживается для основной работы.
1 лайк
Не. Оно так не работает. Флаг SPIF в любом случае выставиться после приёма байта. Короче восемь клоков и не важно что было на линии, нули или единицы. SPIE разрешает вызвать обработчик, оно вам не надо.
ну как бы никакой хотелки и нет сделать на прерываниях. Пока просто ищется причина проблемы. в процессе этого поиска скилл растет, который поможет написать код возможно и без библиотеки .
доберусь до компа , выложу
я настроил загрузчик по RS485 , который тоже на лету прошивку заливает. Мне тоже не рекомендовали так делать. Однако в полевых условиях оказалось что все работает идеально. Лет 5 так обновляю прошивки в сети из 12 МК . Раз 50…60 точно обновлял. Ни разу в середине не обрывалось. Скорость 38400. думаю, и с can ом также должно быть . Удобство такого подхода в том, что со стороны компа , схема прошивки почти ничем не будет отличаться от обычной ардуины. за исключением выбора адреса Нода через терминал , который будем шить . С каном будет также. Из иде открыл монитор порта , выбрал адрес МК, он вернул тебе систем инфо (модель мк частота cpu), ты выбрал нужную плату в иде в соответствии с этим и нажал “прошить”. И это работает на RS485 отлично. Да, согласен надежности так меньше. Но я космические корабли не строю. И ежели прошивка на середине все же и оборвется , то до нода можно и физически добраться. Но повторяю, мне ни разу не приходилось .
А ради эксперимента?
Я помню эти обсуждения. Это норм. Для 485 нет нужды что-то сложное поддерживать. А КАН это все-таки приличный стек. Но в целом тоже ничего особенного. Просто делай поддержку руками, без библиотеки. Хотя и библиотеку можно частично использовать.
проверил теорию о неправильно принятых байт по SPI - не подтвердилось ! В функции mcp2515_readRegister , где считываются данные по SPI, вывел в отладку регистр SPDR. считанный байт совпадает с тем, что мы увидели по логаналазиатору на MISO (MCP → atmega) .
думаю дальше
я изначально хотел так, но, полистав библиотеку SPI и поверх нее mcp_can.h, запутался нафиг , там стопицот функций, последовательно вызываемых, одна в другой в другой и т.д.
А сейчас, когда лог SPI обмена данными рабочего варианта есть, можно действительно и самому попробовать рулить MCPшкой
Какая в сраку библиотека spi, это вонючий сдвиговый регистр, что записал то и вывалилось с восьмью клоками по sck. И всё, ниче мудреного там нет. И данные, как видите, сами прилететь не могут, их надо “запрашивать“.
проблема не библиотеке SPI - она простая , MCP для меня сложная. То что данные надо запрашивать , америку не открыли .
А как hex прошиваете? Вставляете копипастом по нужным адресам? Я “подкинул” код #13 и #14 в Arduino IDE, ложится с 00х0000 адреса.
Но функция main вроде как привязана к секции…
Может, правильней, чтобы лиинкёр сам положил куда надо?