When using JlinkARM.dll versions between 4.54c and 4.56a (inclusive) to flash my device for debugging, the image ends up with one 2KB page of flash remaining erased in the middle of the image.

When I look at the information in the binary produced by IAR (including an Intel HEX format file of the image), it looks like the correct data is produced by the compiler & linker for that page. The page is incorrectly flashed/left erased and no problem is indicated after the verification pass of the flashing process.

The device we're programming is an ST Micro STM32F103ZE; the page the has the problem is 0x08062800 but that will change according to the base address of where the image is loaded (which I did to see if the problem page stayed at the same address or not if the load address was changed).

If I rollback the JLinkARM.dll driver to version 4.34d, the problem goes away.

I have no versions between 4.34d and 4.54c to check where the problem first shows up.

This problem reproduces 100% for my project, but I have no idea what the factor in the project is that causes this problem (other than the version of the JLinkARM.dll). Please let me know if you need more information.

Alex:

I can't dig up an eval board here that has enough flash to hold the image (I've got a STM32-SK, but it only has 128KB of flash). I can pretty easily configure the project for a 256KB board and send you the *.out and *.sim files files generated by IAR, I can also send the image as an Intel hex formatted file.

I won't be able to send the whole project, but all that needs to happen is for the image to be flashed - you don't need to build the project. The page that has been left erased is always the same, so it's easy to verify the problem happening with the new JLink driver (and not happening with the older one). Sould I send a link to the package to download to info@segger.com?

OK, I've sent an email with a link to an IAR project that should reproduce the problem. In preparing the project I've found more information:

While preparing this repro case, I've determined the settings that seem to trigger the problem. The reproduce the problem, you must:

• use a relatively new JLinkARM.dll (I have reproduced the problem with versions 4.54c through 4.56a)
• have at least one breakpoint set.
• have the following IAR project setting enabled/checked:

I noticed the following difference in the Debug log output between JLinkARM.dll v4.34d (which does not have the problem) and JLinkARM.dll v4.56a. I've marked the lines of interest with ">>>":

Thanks for looking into this.

Would it work just as well to uncheck the "Debugger | Download | "Use flash loader(s)" option in the IAR project? Or do we need to do *both* things (uncheck the IAR project option *and* perform the JLink configuration you described?).

I have sometimes wondered about the "Use flash loader(s)" option in the IAR project - I seem to recall that it was turned on way back when because of problems we ran into when it wasn't checked. But that could be my memory playing tricks on me (this is a pretty mature project, so the 'decisions' made for those settings would have been done more than 3 years ago). I've never felt comfortable that I really understood what effect that option had.

--
Mike B