ST L151CC algorithm issues

[Mike]

I've attempted to write interface firmware for a new mbed platform. The interface processor is a MK20DX128VFM and the target processor is a STM32L151CC. I've linked to my DAPLink and FlashAlgo repositories.

Currently the drag-n-drop program of the device appears successful. After programming is finished there is no fail.txt file in the USB drive. The target processor does not appear to execute, however. When connecting with a debugger, I see the following message each time I try to continue/run the application:

(gdb) c
Continuing.
stm32l1.cpu -- clearing lockup after double fault

However, if I load the same binary using the debugger or an external programmer (bypassing the interface processor), the device functions perfectly. This fact leads me to believe that the issue is the flash algorithm itself or the state the processor is in after the flash algorithm runs.

The flash algorithm code was taken from an example flash algorithm included with uVision and updated. The original code can be found at C:\Keil_v5\ARM\Flash\STM32L15x.

I have read out the contents of flash via the debugger and it looks the same (MD5 checksums matched) as the original binary.

I am aware that a double fault is usually caused by an invalid vector table, but as far as I can tell the vector table in the application is fine.

I've attached the test binary I've been using. When programmed with the debugger or an external programmer, it works great. When programmed by the interface firmware & flash algorithm, it doesn't work at all. I added the .txt to the binary name so GitHub would let me attach it.

I appreciate any help or advice on this issue.
blink.bin.txt

[Mike]

As it turns out, the binary programmed by the interface firmware doesn't match the original binary, so the flash algorithm needs work.