Mbed-os: ublox_evk_odin_w2 need to drag and drop twice in order to flash properly

[LiyouZhou]

Description

• Type: Bug
• Priority: Major

ublox_evk_odin_w2 need to drag and drop twice in order to flash properly

Bug

Target
ublox_evk_odin_w2

Toolchain:
GCC_ARM

DAPLink version:
0221

[0xc0170]

cc @andreaslarssonublox

[andreaslarssonublox]

@andreaspeterssonublox

[JanneKiiskila]

Any updates on this? There seems to be some issues with the STLINK used in these ST-based boards. Linux firmware updates are a hit or miss, sometimes they work - sometimes it fails completely due to "no space on disk" and even with Windows based host it eventually fails. This is very problematic to the CI systems.
@andreaslarssonublox @andreaspeterssonublox

[marcuschangarm]

I've run into a new problem in addition to those reported above which are still present:

I don't know the exact breakage point, but my 1.7 MiB test image fails to program properly no matter how many times I try. Smaller images are fine, but at some point the image becomes too large.

[andreaslarssonublox]

Hi, I have tried to reproduce the issues in Windows 10 and here are my findings.

I compiled the blinky example and tried to drag and drop it to the drive ~15 times. It worked all times. I'm using Windows 10.
Therefore it would be valuable to get some more info.

@LiyouZhou

1. Do you know how often this happens?
2. What OS are you using and what version of that OS?
3. What ST-Link version is used on the board?. Latest is V2.J28.M18. Use this app to check and upgrade http://www.st.com/en/development-tools/stsw-link007.html.
4. How big files are you using in bytes when flashing?

@JanneKiiskila Since this seems to be an issue with the ST-Link that is used on many other boards I suggest that you tag it with ST as well.
I tried it on the NUCLEO_F429 board and I can verify that if I flash a file(modified blinky) that is 1 856 624 bytes ten times in a row in Windows 10 cmd prompt it fails quite quickly with the log below.
The same behavior is seen with the UBLOX_EVK_ODIN_W2. However if I add a delay of 5 sec between each copy it seems to work(at least 10 times in a row).

C:\git\ARMmbed\_issues\4247\mbed-os-example-blinky>copy 
BUILD\UBLOX_EVK_ODIN_W2\GCC_ARM\mbed-os-example-blinky.bin d:\
    1 file(s) copied.

C:\git\ARMmbed\_issues\4247\mbed-os-example-blinky>copy 
BUILD\UBLOX_EVK_ODIN_W2\GCC_ARM\mbed-os-example-blinky.bin d:\
The volume for a file has been externally altered so that the opened file is no longer valid.
    0 file(s) copied.

C:\git\ARMmbed\_issues\4247\mbed-os-example-blinky>copy     
BUILD\UBLOX_EVK_ODIN_W2\GCC_ARM\mbed-os-example-blinky.bin d:\
The request was aborted.
    0 file(s) copied.

C:\git\ARMmbed\_issues\4247\mbed-os-example-blinky>copy 
BUILD\UBLOX_EVK_ODIN_W2\GCC_ARM\mbed-os-example-blinky.bin d:\
    1 file(s) copied.

C:\git\ARMmbed\_issues\4247\mbed-os-example-blinky>copy 
BUILD\UBLOX_EVK_ODIN_W2\GCC_ARM\mbed-os-example-blinky.bin d:\
The volume for a file has been externally altered so that the opened file is no longer valid.
    0 file(s) copied.

@marcuschangarm I could not reproduce the error with ST-Link V2.J28.M18 or V2.J28.M16 with the modified blinky of 1 856 624 bytes.

1. I can see in the release notes of the latest ST-Link firmware that there have been problems with the size after Windows 10 has added files(http://www.st.com/resource/en/release_note/dm00107009.pdf). Might this be the issue?
2. Can you send me your binary or try to upgrade ST-Link just to make sure you're not using an old version?
3. What is the exact size of your binary?

1. Could someone at ST reproduce it with their board e.g. NUCLEO_F429?
   I can attach supersized blinky if needed.
   @bcostm @lmestm

[teetak01]

@andreaslarssonublox @bcostm have you tried flashing from Linux? For me, if I try to flash the same board (Any ST-board) twice, it will fail with out-of-disk-space error. This is completely broken in linux-environment. Windows is somewhat stable.

[JanneKiiskila]

@0xc0170 - yes, this is an common STLINK Issue, perhaps the ST-label could be added. Please be aware of this case @adustm.

The Linux flashing support is very important to us due to CI machines mostly being Linux.

[teetak01]

@andreaslarssonublox we are using this version: V2.J28.M18RC2

[bcostm]

Could someone at ST reproduce it with their board e.g. NUCLEO_F429?
I can attach supersized blinky if needed.

Yes can you please ? We'll try to reproduce it.

[andreaslarssonublox]

@bcostm that sounds good. Here's the main.cpp:
main_cpp.zip

[screamerbg]

@JanneKiiskila @teetak01 have you tried updating to firmware V2.J29.M18?

[andreaslarssonublox]

I can confirm that it does not work to flash twice in linux. Do you have any updates @bcostm?

[schstm]

Hello,
I tried on my side with a Nucleo-F429 (firmware V2J28M18) to program by drag&drop an application (1.8 MB) several times both on Windows 10 and Ubuntu 14, and found no issue.
Note that one must wait some time at the end of the first programming, in order to have the mass storage interface refreshed (bin file 'disappeared', available size back to 2MB), before attempting a new programming. Otherwise, depending on when the second attempt is done, either the system may return an error because of not enough size available on disk, or some other error is possible because during approximately 1 second after the end of programming, the ST-Link answers "Not ready" to "Test unit ready" request from host mass storage driver. This is the mechanism implemented in order to 'refresh' the disk after a programming, allowing to program "indefinitely" on a disk with a limited size ...
May you please try to add a delay (minimum: 1.1s) between consecutive programming and see what happens ? May you try 'manual' drag&drop programming in order to eliminate any other issue with the host environment ?

[andreaslarssonublox]

I tried it on Ubuntu 16.04 with the 1.8M blinky, firmware V2J28M18 and still have the same problem with NUCLEO_F429ZI. Also when flashing with "cp" on the CLI. I waited ~10 sec after the blinky application started to blink but get the error message "No space left on device". It looks like the device is never refreshed automatically. However after trying to copy the second time and it fails, it usually refreshes after a couple of seconds. So a third attempt usually succeeds.

[bcostm]

What is the status of this issue ? Did you check with latest version V2.30.21 ?

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-344

[jeromecoutant]

@andreaslarssonublox @LiyouZhou
Any updates ?
Thx

[LiyouZhou]

there hasn't been any fw update since V2J28M18 so no change i guess.

[jeromecoutant]

there hasn't been any fw update since V2J28M18 so no change i guess.

?
Could you try V2J30M21?

Thx

[bcostm]

Latest version is now V2.J31.M21

[LiyouZhou]

the latest version seems to be better. Thanks. BTW the st link tools doesn't make it easy to upgrade your st link firmware. StLinkUpgrade.jar doesn't check online for new versions, hence i thought V2J28M18 was the latest. Then if you want to download a new stlinkupgrade.jar, it is onfusingly named and hard to find on st's web site. Then when you actually want to download it, it ask you to register an account........

[bcostm]

StLinkUpgrade.jar doesn't check online for new versions

@schstm Is there something planned ?

[schstm]

No, the online check is not currently planned, moreover the single application (with a single version)contains several firmwares (with each one his own version). We can evaluate instead the possibility to add the URL to the web page in the application in order to at least find it easily. The version displayed for STSW-LINK007 in the web page is the one of ST-Link/V2-1 firmware for STM32 (V2JxxMyy).

[jeromecoutant]

Maybe we can close this issue ?
Thx

ST_TO_BE_CLOSED