Я пишу серийный загрузчик для MCU Cortex-M4 ( ATSAME51N20A ) на специальной плате. Я в настоящее время прошивать / отлаживать его с помощью Jlink через SWD.
Текущая архитектура : у меня есть сценарий python, который считывает двоичный файл, разбивает его на 512-байтовые куски, отправляет его через UART в MCU и в конце выполняет CRC32 всего этого и проверяет, чтобы убедиться, что CR C на принимающей стороне совпадает. Это все работает нормально, данные отправляются, и CR C на обоих концах совпадают.
Входящий двоичный файл сохраняется по адресу #define APPLICATION_START_ADDRESS 0x8000
. Как только загрузчик получил последний чанк, он вызывает следующий код:
void jumpToApplication(void)
{
uint32_t applicationMainStackPointer = *(volatile uint32_t *) (APPLICATION_START_ADDRESS);
__set_MSP(applicationMainStackPointer);
void (*applicationResetHandler)(void);
uint32_t applicationResetHandlerAddress = *(volatile uint32_t *) (APPLICATION_START_ADDRESS + 4);
applicationResetHandler = (void *) applicationResetHandlerAddress;
applicationResetHandler();
}
Проблема: Приложение не запускается после загрузчика. Я должен увидеть кучу всплывающих Hello, World!
, но ничего не происходит.
Я подумал, что, возможно, переход к приложению с подключенным JLink вызовет проблемы, поэтому я попытался запустить все без подключенного JLink, но он все еще не работает.
Мои вопросы:
Что здесь может пойти не так? Что можно посмотреть, чтобы продолжить отладку этой проблемы?
Я протестировал бинарный файл, который отправляю, перепрошивая его через JLink, однако файл, который я на самом деле перепрошиваю, является .elf
файл. Насколько я понимаю, файл .bin
должен работать так же хорошо, но, может быть, я ошибаюсь?
В Python я форматирую двоичный файл файл, подобный следующему:
data = [x for x in open(path, 'rb').read()]
blocks = [data[i:i + PAGE_SIZE] for i in range(0, len(data), PAGE_SIZE)]
Может ли это повредить двоичный файл?
Любые советы по отладке / советы / идеи приветствуются.