Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flash loader run problem.... #290

Closed
rewolff opened this issue Jan 7, 2015 · 16 comments · Fixed by #882
Closed

flash loader run problem.... #290

rewolff opened this issue Jan 7, 2015 · 16 comments · Fixed by #882

Comments

@rewolff
Copy link
Contributor

rewolff commented Jan 7, 2015

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
Copy link
Contributor Author

rewolff commented Jan 7, 2015

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
Copy link
Member

xor-gate commented May 4, 2016

Have you tried with latest stlink from master?

@notthetup
Copy link

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

@xor-gate
Copy link
Member

xor-gate commented May 5, 2016

@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
Copy link
Member

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

@rewolff
Copy link
Contributor Author

rewolff commented Mar 19, 2020

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.

@rewolff rewolff closed this as completed Mar 19, 2020
@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Mar 19, 2020

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

@rewolff
Copy link
Contributor Author

rewolff commented Mar 19, 2020

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

@rewolff
Copy link
Contributor Author

rewolff commented Mar 19, 2020

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
Copy link
Contributor Author

rewolff commented Mar 19, 2020

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
Copy link
Member

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
Copy link
Contributor Author

rewolff commented Mar 19, 2020

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
Copy link
Member

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
Copy link
Contributor Author

rewolff commented Mar 19, 2020

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
Copy link
Member

Ok, so feel free to do so :-)

@rewolff
Copy link
Contributor Author

rewolff commented Mar 19, 2020

Done.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants