Failure to flash for MTB_ADV_WISE_1570 target

[mirelachirica]

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Bug
• Priority: Blocker

Bellow commit is causing problem to flash binary built for MTB_ADV_WISE_1570 target.

---

Bug

Target
MTB_ADV_WISE_1570

Toolchain:
GCC_ARM

Toolchain version:

mbed-cli version:
1.1.1

mbed-os sha:
02b2b01 Change STM32L475/76/86 GCC_ARM linker files to have HEAP in SRAM1 and stack in SRAM2 (after the interrupt vector)

Expected behavior
Copy/Flash succesfully.

Actual behavior
FAIL.TXT
DETAILS.TXT
"The transfer timed out."

Steps to reproduce
Build. Copy binary to daplink drive.

[0xc0170]

@kivaisan Have you experienced any issues with flashing?

@mirelachirica I assume this target uses ST Link, thus the issue is debugger related.
What firmware are you using? This is vital to see if there is newer version or what version is having a problem. Have you tried to update to the latest firmware via st link firmware updater?

Edit: The details.txt contains the firmware version, daplink used.

[0xc0170]

I missed the sentence that this is pointing to the #6172.

The commit 02b2b01 is one to blame? Withtou this commit, all works, with this it breaks?

@adustm Are you aware of this? How can the PR 6172 break the flashing? It touches RAM section only

[0xc0170]

Looking at the changes there. Two targets we have in the codebase are STM32L486xG but they do not define two RAM regions, why? The PR specifies that L486 should define it but they don't. Is that correct?

Still failing to see how the 02b2b01 breaks the flashing.

[0xc0170]

ARM/IAR should be functional, please use these two toolchains in the meantime while this gets resolved

[0xc0170]

I have NUCLEO_L476RG that is included in that change, tests working on master as of today. Isn't this related to the firmware? where is the firmware coming from for MTB_ADV_WISE_1570 ?

[kimlep01]

Mirela and Kimmo V left to big picture but here is the contents from details.txt:

DAPLink Firmware - see https://mbed.com/daplink

Unique ID: 0460000007b7dd7e00000000000000000000000097969902
HIC ID: 97969902
Auto Reset: 0
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0244
Git SHA: 5da52ab81752fad4122d7559bf7a01844d4a366e
Local Mods: 1
USB Interfaces: MSD, CDC, HID
Interface CRC: 0xc112d35e
Remount count: 1

[0xc0170]

I referenced my local fix, but can't test as I do not have this target. @kimlep01 can you or anyone else to test for me this commit 0xc0170@32348e0 , if it fixes it?

@c1728p9 Can you review this issue (how daplink could have a problem with 2 RAM sections? Am I missing there a change that can affect flashing ?)

[c1728p9]

DAPLink uses the initial stack pointer in the vector table of .bin files to check if the target image is valid. For the binary file to be considered valid the initial stack pointer must reside within the primary ram region. In the case of the stm32l486jg on the MTB_ADV_WISE_1570 DAPLink is expecting this to reside in the range 0x20000000 to 0x20018000.

As a fix I recommend configuring the MTB_ADV_WISE_1570 to create .hex files rather than .bin files. Hex files don't need a valid vector table, as the hex format is used to validate the image rather than the raw flash contents.

[0xc0170]

DAPLink uses the initial stack pointer in the vector table of .bin files to check if the target image is valid. For the binary file to be considered valid the initial stack pointer must reside within the primary ram region. In the case of the stm32l486jg on the MTB_ADV_WISE_1570 DAPLink is expecting this to reside in the range 0x20000000 to 0x20018000.

That would explain the failures

As a fix I recommend configuring the MTB_ADV_WISE_1570 to create .hex files rather than .bin files. Hex files don't need a valid vector table, as the hex format is used to validate the image rather than the raw flash contents.

Will check and can propose a fix

[kimlep01]

I tested the commit mentioned above but it didn't fix the issue. ARM compiler works but IAR doesn't. Looking at the original pull request that caused this issue the same changes have been added to IAR toolchain already.

Edit: I have tested that this issue is fixed with PR #6346