flash loader run problem....

[rewolff]

Looks similar to issue #269 but is not.

It seems this is hardware dependent: One board has this issue, the other does not.

About (exactly?) half the times I run a "reset-load-continue", I get:
2015-01-07T17:28:03 INFO src/stlink-common.c: Successfully loaded flash loader in sram
2015-01-07T17:28:23 ERROR src/stlink-common.c: flash loader run error
and then the load/flash fails.

As an extra "hint" as to what's happening: It seems to be NOT booting from SRAM but from my flash: It prints the welcome message on the serial port. On the other hand, the CPU seems halted shortly after booting: I cannot interact with the program.

Any idea how this could come to be? (I have boot0 pulled low: boot from flash... Hmm. It seems I've got "boot0" floating on the board that works.... Never worried about it because it simply works).

[rewolff]

I've added this patch to my own source now:

--- a/src/stlink-common.c
+++ b/src/stlink-common.c
@@ -1823,10 +1823,10 @@ int run_flash_loader(stlink_t sl, flash_loader_t fl, s
/* run loader */
stlink_run(sl);

-#define WAIT_ROUNDS 10000
+#define WAIT_ROUNDS 100
/* wait until done (reaches breakpoint) */
for (i = 0; i < WAIT_ROUNDS; i++) {

•    usleep(10);
  

•    usleep(1000);
   if (is_core_halted(sl))
       break;
  

  }

The "usleep (10)" causes a delay of AT LEAST 10 microseconds, in practise about 2ms. The wait therefore takes about 20 seconds for 10k attempts. By increasing the wait, and decreasing the number of loops, the intent of looping for about a second is achieved. (hmm it seems the intent was to wait only 0.1 sec... Oh wel).

[xor-gate]

Have you tried with latest stlink from master?

[notthetup]

I have seen flash loader run error even on the latest master build (ea6a858).

[xor-gate]

@notthetup, thanks for your feedback. I suggest you should open a new issue with more details (as suggested by the new issue template). Thank you!

[Nightwalker-87]

@rewolff: Is this resolved with Release v1.2.0? Please verify.

[rewolff]

I would say yes.

I installed "latest git" or 1.6.0 (I don't remember which) a few days ago.

I then ran "make stflash" in one of my projects and... it failed. I then checked where it found the "st-flash" binary and it was in another place than where I'd installed the latest version.... So I removed the old one and tried again. More than ten times: No problem!

The issue with the long wait: Not sure what triggered it. But the "flash loader run error" was definitively still present in the older version and no longer in the current version.

[Nightwalker-87]

@rewolff: Have you also tested with 1.2.0? I'd need that info to allocate the ticket correctly in github for maintenance.

[rewolff]

No sorry.
OK. Now I have... Nope not fixed in 1.2.0.

[rewolff]

1.3.0 .... 1.5.0 don't compile (requires libgtk+-3.0-dev which I installed and then got an "invalid number of arguments" error. ) .

[rewolff]

Update: I decided to double check my findings by going back to 1.2.0 again and... now 1.2.0 works too... So... If we trust my observation that it didn't work 10 minutes ago.... I can't reliably reproduce the problem. ten minutes ago it happend, and now it doesn't

Soo.... Not sure if it is fixed in 1.6.0, or if I did something so that the trigger just doesn't happen anymore before I got around to testing 1.6.0 again.

[Nightwalker-87]

Mh, that does not sound very promising...
Can you define your build system and hardware more precisely?
I propose to take a step back do a a clean install of v1.2.0 without any leftovers and look that compilation and libs work well. After that we can take a closer look again.

[rewolff]

Why do you need to know if it works in v1.2.0 when we're now at 1.6.0 (++) and it looks as if it's fixed?

In any case, the bug I actually reported has NOT been fixed. I determined this by "code inspection" (grep -r WAIT_ROUNDS). Under the conditions that triggered that wait-loop, the current code still tries to wait 10 thousand times 10 microseconds, which on many (correct!) unix-implementations turns into 10000 times several milliseconds or about 20 seconds in most cases (100 or 200 seconds on older Unix-like OSes.) Just reducing the number of retries to 100 and aiming for a 1 ms delay or so fixes that.

getafix:~/stm32/stlink.git2> grep -r WAIT_ROUNDS
src/flash_loader.c:#define WAIT_ROUNDS 10000
src/flash_loader.c:    for (i = 0; i < WAIT_ROUNDS; i++) {
src/flash_loader.c:    if (i >= WAIT_ROUNDS) {
getafix:~/stm32/stlink.git2> bc

[Nightwalker-87]

I'm currently actively maintaining the project for the benefit of all and would like to add solved issues to the dedicated milestones. This also ensures that the CHANGELOGs can be updated properly. So far I've already spent quite a few efforts to clean this up. However this requires some help by others/authors where I can't do any verification on build systems and hardware I do not have.

[rewolff]

So... I don't remember what triggered the long waits, but from code inspection we can see that it hasn't been fixed. Do you need a pull request?

[Nightwalker-87]

Ok, so feel free to do so :-)

[rewolff]

Done.