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

Flashing does not work in deep sleep (stop) mode #428

Closed
andyg24 opened this issue Jun 6, 2016 · 6 comments · Fixed by #430
Closed

Flashing does not work in deep sleep (stop) mode #428

andyg24 opened this issue Jun 6, 2016 · 6 comments · Fixed by #430

Comments

@andyg24
Copy link

andyg24 commented Jun 6, 2016

First, thank you very much for developing this tool. It works great most of the time, and is orders of magnitude faster than OpenOCD for programming STM32 microcontrollers.

One issue I ran across is that st-flash does not seem to work when my CPU (stm32l031k6) is in stop mode. A workaround that I found is to press and release the reset button at exactly the same time as running the st-flash command; this doesn't work every time though.

I am on Linux (Ubuntu Trusty), have fresh st-flash (compiled from the latest snapshot in git), and am using a Nucleo STM32L031 board. I can attach a simple bin file that demonstrates the problem if it's helpful.

The command that I use is

st-flash --reset write bin/test.bin 0x8000000

The output that I get is

2016-06-06T12:39:08 INFO src/common.c: Loading device parameters....
2016-06-06T12:39:08 WARN src/common.c: unknown chip id! 0

but only if the CPU is in stop mode. Otherwise everything works as expected.

Apologies if this is a known issue and I haven't done enough searching to find it.

@xor-gate xor-gate added this to the Unplanned (Contributions Welcome) milestone Jun 6, 2016
@xor-gate
Copy link
Member

xor-gate commented Jun 6, 2016

I have seen this kind of issue before, which is reset-related and based on the state of the core. This needs to be investigated and reproduced, and of course fixed.

@andyg24
Copy link
Author

andyg24 commented Jun 6, 2016

Thank you for the quick follow up. I am not familiar with the code, but could it be that you try to read chip ID prior to a JTAG reset? If so, that would explain the error, as the DBG interface is disabled in stop mode. A proposed fix then is to do a reset prior to reading the chip ID.

@andyg24
Copy link
Author

andyg24 commented Jun 7, 2016

Thanks, that helps. Looks like the fix is to replace

usb.c, L879

    if (reset) {
        stlink_reset(sl);
        usleep(10000);
    }

with

    if (reset) {
        stlink_jtag_reset(sl, 2);
        stlink_reset(sl);
        usleep(10000);
    }

Please see PR #430

@xor-gate
Copy link
Member

xor-gate commented Jun 7, 2016

Seems good to me, @texane what do you think?
There are also some other reset-related issues still open:
https://github.com/texane/stlink/labels/error%2Freset

@xor-gate
Copy link
Member

xor-gate commented Jun 9, 2016

@texane ping? :-).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.