-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
STM32F4 Discovery Unknown Chip ID! 0 - Due to Read Out Protection level 1 #422
Comments
Have you tried |
Hi xor-gate, |
I think we had a miscommunication. With the:
The tools/library version from |
Yes I have the STSW-LINK007 2.27.15 found from: |
The firmware seems good. Could you try with |
The output of the command: |
Probably the stlink programmer is claimed by another application. The probe tool scans all the usb devices and tries to open them. Currently the ones which fail will not be displayed. Please make sure nothing is using the programming. |
I have tried to program the board from several machines (one Windows environment and two Unix environments) could that effect it? I also tried to use the offical ST-Link utility when I was on my windows machine, could that effect it? And is there a way to find which application is claiming the stlink and/or reset the stlink programmer? |
[Update] When I have nothing connected to my computer, I have: |
No claiming means when the usb device is opened by an application. The programmer is located as the first chip on the board with usb connection. I have no clue what your problem is. Maybe you have no permissions to access the device. Could you try to run |
I fixed the issues by removing qstlink2, openocd, and their corresponding *.rules files in /etc/udev/rules.d from my system which was probably the 1 programmer that st-info --probe was detecting. Now when I run sudo st-flash write blinky.bin 0x8000000 I get the following output:
which I saw other users were getting too. Unfortunately, I did not find a definite answer on how to fix this. Any advice? |
Have you tried to mass erase the flash first and then program? As related to: https://github.com/texane/stlink#sometimes-flashing-only-works-after-a-mass-erase |
@tlamb96 could you verify that after mass erase it works? |
@xor-gate My STM32F4 board was shipped with Read Out Protection to level 1 which disables any writing to the memory. As an STM32 novice, this took quite a lot of time to figure out but is now fixed. Thank you for your support and the stlink repo. |
Damn, thats a shame -_-". Good luck, thank you for your contribution. |
I had the same issue. I used the Windows ST-Link utility to do an erase of the chip. (I also updated the firmware, but I don't think this is related.) After this, Is it possible to use this project to do the mass erase like the Windows ST-Link utility does without being able to read out the chip ID and core ID? |
No, not as far as I am aware of. |
st-info
,st-flash
,st-util
A as-detailed description possible of the problem with debug output when available.
I am following the basic tutorial found here: http://makeict.org/wiki/STM32F4_Discovery_on_Linux and when I get to "sudo st-flash write bin/main.bin 0x8000000" the LD1 and COM lights toggle on/off with a blue color and I get the output shown below. I have tried using your tool on other projects and it still doesn't work. Any help would be appreciated :)
Output:
2016-05-24T23:22:01 INFO src/common.c: Loading device parameters....
2016-05-24T23:22:01 WARN src/common.c: unknown chip id! 0
The text was updated successfully, but these errors were encountered: