Я использую отличный инструмент мониторинга API Rohitab для мониторинга вызовов DLL, которые Keil uVision делает для JLinkARM.dll Segger, чтобы я мог воспроизвести их в автоматизированной тестовой среде.
В рамках этого я пытаюсь понять механизм, с помощью которого uVision взаимодействует с программой флэш-загрузчика для загрузки отлаживаемого образа.
Я понимаю, что uVision загружает программу флэш-загрузчика в оперативную память целевого устройства, и этот загрузчик взаимодействует с встроенной флэш-памятью, чтобы стереть ее и загрузить новый образ, хотя я изо всех сил пытаюсь увидеть вызовы DLL, которые выполняются из uVision для фактической потоковой передачи изображение во флеш-загрузчик.
Я ожидал увидеть целую кучу вызовов JLINKARM_WriteMem для потоковой передачи данных, но этого не произошло. Я вижу кучу вызовов JLINK_WriteReg и JLINK_ReadReg, но их недостаточно, чтобы составить изображение. Я предполагаю, что они предназначены для наблюдения за процессом перепрошивки. Я знаю, что Jlink поддерживает ряд API-интерфейсов, связанных с загрузкой флэш-памяти, но я не вижу их использования здесь. Я тоже не вижу пройденных путей. Собственный файл журнала JLink здесь также бесполезен. Есть ли какой-то необычный механизм, который мне здесь не хватает?
