stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.46k stars 1.24k forks source link

Reports 0K of Flash with STM32F205VG #192

Closed wgraba closed 8 years ago

wgraba commented 11 years ago

When connecting to a STM32F205VG, st-util reports that the amount of flash is 0K-

# sudo ./st-util -v99
2013-11-04T16:28:34 DEBUG src/stlink-common.c: stlink current mode: debug (jtag or swd)
2013-11-04T16:28:34 DEBUG src/stlink-common.c: stlink current mode: debug (jtag or swd)
2013-11-04T16:28:34 INFO src/stlink-common.c: Loading device parameters....
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** stlink_core_id ***
2013-11-04T16:28:34 DEBUG src/stlink-common.c: core_id = 0x2ba01477
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** stlink_read_debug32 20036411 is 0xe0042000
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** stlink_read_debug32 412fc230 is 0xe000ed00
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x1ff7a20
2013-11-04T16:28:34 INFO src/stlink-common.c: Device connected is: F2 device, id 0x20036411
2013-11-04T16:28:34 INFO src/stlink-common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0 bytes (0 KiB) in pages of 131072 bytes
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** looking up stlink version
2013-11-04T16:28:34 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2013-11-04T16:28:34 DEBUG src/stlink-common.c: stlink pid     = 0x3748
2013-11-04T16:28:34 DEBUG src/stlink-common.c: stlink version = 0x2
2013-11-04T16:28:34 DEBUG src/stlink-common.c: jtag version   = 0x10
2013-11-04T16:28:34 DEBUG src/stlink-common.c: swim version   = 0x4
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** stlink_reset ***
Chip ID is 00000411, Core ID is  2ba01477.
2013-11-04T16:28:34 DEBUG src/stlink-common.c: *** reading target voltage
2013-11-04T16:28:34 DEBUG src/stlink-common.c: target voltage = 3267mV
Target voltage is 3267 mV.
Listening at *:4242...

Obviously, this is not correct. Any ideas?

As a workaround, adding this code when loading the params works, but might not be the best -

} else if (sl->chip_id == STM32_CHIPID_F2 && flash_size == 0) {
        sl->flash_size = 1024 * 1024;
}
morgoth6 commented 10 years ago

I was hit by the same problem a few days ago with newly buyght STM32F4-Discovery board.

2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink current mode: dfu 2014-02-26T02:08:44 INFO src/stlink-usb.c: -- exit_dfu_mode 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_exit_dfu_mode 2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink current mode: mass 2014-02-26T02:08:44 DEBUG src/stlink-common.c: \ stlink_enter_swd_mode 2014-02-26T02:08:44 INFO src/stlink-common.c: Loading device parameters.... 2014-02-26T02:08:44 DEBUG src/stlink-common.c: \ stlink_core_id 2014-02-26T02:08:44 DEBUG src/stlink-common.c: core_id = 0x2ba01477 2014-02-26T02:08:44 DEBUG src/stlink-common.c: \ stlink_read_debug32 10016413 is 0xe0042000 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_read_debug32 0 is 0x1fff7a20 2014-02-26T02:08:44 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413 2014-02-26T02:08:44 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0 bytes (0 KiB) in pages of 16384 bytes 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * looking up stlink version 2014-02-26T02:08:44 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483) 2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink pid = 0x3748 2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink version = 0x2 2014-02-26T02:08:44 DEBUG src/stlink-common.c: jtag version = 0x13 2014-02-26T02:08:44 DEBUG src/stlink-common.c: swim version = 0x0 2014-02-26T02:08:44 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_reset Chip ID is 00000413, Core ID is 2ba01477. 2014-02-26T02:08:45 DEBUG src/stlink-common.c: * reading target voltage 2014-02-26T02:08:45 DEBUG src/stlink-common.c: target voltage = 2925mV Target voltage is 2925 mV. Listening at :4242...

I wonder maybe the recently released STLink firmware upgrade cause this ? This board have 2.19 version (same as in http://www.st.com/web/en/catalog/tools/PF258194 I think) I can not see anything related in release notes (http://www.st.com/st-web-ui/static/active/en/resource/technical/document/release_note/DM00067813.pdf)

texane commented 10 years ago

I reviewed the changes recently made to the stlink software (ie. not the firmware you mention), and I do not think they are related to your issue.

2014-02-25 19:13 GMT-06:00 morgoth6 notifications@github.com:

I was hit by the same problem a few days ago with newly buyght STM32F4-Discovery board.

2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink current mode: dfu 2014-02-26T02:08:44 INFO src/stlink-usb.c: -- exit_dfu_mode 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_exit_dfu_mode * 2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink current mode: mass 2014-02-26T02:08:44 DEBUG src/stlink-common.c: *\ stlink_enter_swd_mode


2014-02-26T02:08:44 INFO src/stlink-common.c: Loading device parameters.... 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_core_id 2014-02-26T02:08:44 DEBUG src/stlink-common.c: core_id = 0x2ba01477 2014-02-26T02:08:44 DEBUG src/stlink-common.c: \ stlink_read_debug32 10016413 is 0xe0042000 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_read_debug32 0 is 0x1fff7a20 2014-02-26T02:08:44 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413 2014-02-26T02:08:44 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0 bytes (0 KiB) in pages of 16384 bytes 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * looking up stlink version 2014-02-26T02:08:44 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483) 2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink pid = 0x3748 2014-02-26T02:08:44 DEBUG src/stlink-common.c: stlink version = 0x2 2014-02-26T02:08:44 DEBUG src/stlink-common.c: jtag version = 0x13 2014-02-26T02:08:44 DEBUG src/stlink-common.c: swim version = 0x0 2014-02-26T02:08:44 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface 2014-02-26T02:08:44 DEBUG src/stlink-common.c: * stlink_reset Chip ID is 00000413, Core ID is 2ba01477. 2014-02-26T02:08:45 DEBUG src/stlink-common.c: * reading target voltage 2014-02-26T02:08:45 DEBUG src/stlink-common.c: target voltage = 2925mV Target voltage is 2925 mV. Listening at :4242...

I wonder maybe the recently released STLink firmware upgrade cause this ? This board have 2.19 version (same as in http://www.st.com/web/en/catalog/tools/PF258194 I think) I can not see anything related in release notes ( http://www.st.com/st-web-ui/static/active/en/resource/technical/document/release_note/DM00067813.pdf)

Reply to this email directly or view it on GitHubhttps://github.com/texane/stlink/issues/192#issuecomment-36079996 .

morgoth6 commented 10 years ago

For now I add a similar workaround as in first post:

....
 if (params->flash_size_reg & 2)
     flash_size = flash_size >>16;

@@ -472,6 +474,8 @@ int stlink_load_device_params(stlink_t sl) { } else { sl->flash_size = 256 \ 1024; }

Seems to work that way just fine. Not perfect, but works ...

morgoth6 commented 10 years ago

Quick update about the issue. The workaround is not working in 100% as I can now flash or errase the chip. It fails when writing/erasing first block.

But downgrading STLink-v2 firmware from v2.j19.S0 (available on st website) to v2.J17.S0 (from ST-Link Utility 3.3) seems to resolve it for good.

I can normaly erase/write chip using both firmware versions when use ST-Link Utility 3.3

texane commented 10 years ago

Do you mean that downloading a STLINK firmware v2.J17S0 and using a non patched STLINK software solves your issue ? If so, this is great. Could you please close the issue ?

2014-02-26 14:27 GMT-06:00 morgoth6 notifications@github.com:

Quick update about the issue. The workaround is not working in 100% as I can now flash or errase the chip. It fails when writing/erasing first block.

But downgrading STLink-v2 firmware from v2.j19.S0 (available on st website) to v2.J17.S0 (from ST-Link Utility 3.3) seems to resolve it for good.

I can normaly erase/write chip using both firmware versions when use ST-Link Utility 3.3

Reply to this email directly or view it on GitHubhttps://github.com/texane/stlink/issues/192#issuecomment-36172451 .

morgoth6 commented 10 years ago

Hmm, sure it can be closed but the problem still exists.

When using ST-Link V2 firmware 2.17 I can flash board using both st-flash from here (I prefer this method as I normaly work on linux box) or STM provided ST-Link utility.

After upgrade to 2.19 the st-flash refuse to flash the board as it detect the flash size as 0KB. The trick with hardcoded flash size works, but fails when trying to erase first block.

The problem is STM utility works with both FW revisions as I can erase the board and flash it without any problems using 2.19 and 2.17 then I assume the problem is somewhere in stlink.

I will paster logs from st-util run with -v99 using 2.17 and 2.19 maybe this would help to figure out what is wrong.

morgoth6 commented 10 years ago

The log using 2.17 FW, The stlink_read_debug32 log shows it reads flash size.

2014-02-27T01:14:23 DEBUG src/stlink-common.c: stlink current mode: mass 2014-02-27T01:14:23 DEBUG src/stlink-common.c: stlink current mode: mass 2014-02-27T01:14:23 DEBUG src/stlink-common.c: * stlink_enter_swd_mode 2014-02-27T01:14:23 INFO src/stlink-common.c: Loading device parameters.... 2014-02-27T01:14:23 DEBUG src/stlink-common.c: \ stlink_core_id 2014-02-27T01:14:23 DEBUG src/stlink-common.c: core_id = 0x2ba01477 2014-02-27T01:14:23 DEBUG src/stlink-common.c: \ stlink_read_debug32 10016413 is 0xe0042000 2014-02-27T01:14:23 DEBUG src/stlink-common.c: * stlink_read_debug32 400c000 is 0x1fff7a20 2014-02-27T01:14:23 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413 2014-02-27T01:14:23 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes 2014-02-27T01:14:23 DEBUG src/stlink-common.c: * looking up stlink version 2014-02-27T01:14:23 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483) 2014-02-27T01:14:23 DEBUG src/stlink-common.c: stlink pid = 0x3748 2014-02-27T01:14:23 DEBUG src/stlink-common.c: stlink version = 0x2 2014-02-27T01:14:23 DEBUG src/stlink-common.c: jtag version = 0x11 2014-02-27T01:14:23 DEBUG src/stlink-common.c: swim version = 0x0 2014-02-27T01:14:23 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface 2014-02-27T01:14:23 DEBUG src/stlink-common.c: * stlink_reset * 2014-02-27T01:14:23 DEBUG src/stlink-common.c: *\ reading target voltage 2014-02-27T01:14:23 DEBUG src/stlink-common.c: target voltage = 2896mV 2014-02-27T01:14:25 DEBUG src/stlink-common.c: * stlink_run * 2014-02-27T01:14:25 DEBUG src/stlink-common.c: * stlink_exit_debug_mode * 2014-02-27T01:14:25 DEBUG src/stlink-common.c: *\ stlink_write_debug32 a05f0000 to 0xe000edf0 2014-02-27T01:14:25 DEBUG src/stlink-common.c: * stlink_close ** Chip ID is 00000413, Core ID is 2ba01477. Target voltage is 2896 mV. Listening at :4242...

morgoth6 commented 10 years ago

Same board with 2.19 and hardcoded 1024 flash size modification. Anyway stlink_read_debug32 shows it reads the the device ID correctly:

*\ stlink_read_debug32 10016413 is 0xe0042000

But the flash size is read as 0

*\ stlink_read_debug32 0 is 0x1fff7a20

The full log:

2014-02-27T01:21:24 DEBUG src/stlink-common.c: stlink current mode: dfu 2014-02-27T01:21:24 INFO src/stlink-usb.c: -- exit_dfu_mode 2014-02-27T01:21:24 DEBUG src/stlink-common.c: * stlink_exit_dfu_mode 2014-02-27T01:21:24 DEBUG src/stlink-common.c: stlink current mode: mass 2014-02-27T01:21:24 DEBUG src/stlink-common.c: \ stlink_enter_swd_mode 2014-02-27T01:21:24 INFO src/stlink-common.c: Loading device parameters.... 2014-02-27T01:21:24 DEBUG src/stlink-common.c: \ stlink_core_id 2014-02-27T01:21:24 DEBUG src/stlink-common.c: core_id = 0x2ba01477 2014-02-27T01:21:24 DEBUG src/stlink-common.c: \ stlink_read_debug32 10016413 is 0xe0042000 2014-02-27T01:21:24 DEBUG src/stlink-common.c: * stlink_read_debug32 0 is 0x1fff7a20 2014-02-27T01:21:24 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413 2014-02-27T01:21:24 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes 2014-02-27T01:21:24 DEBUG src/stlink-common.c: * looking up stlink version 2014-02-27T01:21:24 DEBUG src/stlink-common.c: st vid = 0x0483 (expect 0x0483) 2014-02-27T01:21:24 DEBUG src/stlink-common.c: stlink pid = 0x3748 2014-02-27T01:21:24 DEBUG src/stlink-common.c: stlink version = 0x2 2014-02-27T01:21:24 DEBUG src/stlink-common.c: jtag version = 0x13 2014-02-27T01:21:24 DEBUG src/stlink-common.c: swim version = 0x0 2014-02-27T01:21:24 DEBUG src/stlink-common.c: notice: the firmware doesn't support a swim interface 2014-02-27T01:21:24 DEBUG src/stlink-common.c: * stlink_reset * 2014-02-27T01:21:24 DEBUG src/stlink-common.c: *\ reading target voltage 2014-02-27T01:21:24 DEBUG src/stlink-common.c: target voltage = 2903mV 2014-02-27T01:21:26 DEBUG src/stlink-common.c: * stlink_run * 2014-02-27T01:21:26 DEBUG src/stlink-common.c: * stlink_exit_debug_mode * 2014-02-27T01:21:26 DEBUG src/stlink-common.c: *\ stlink_write_debug32 a05f0000 to 0xe000edf0 2014-02-27T01:21:26 DEBUG src/stlink-common.c: * stlink_close ** Chip ID is 00000413, Core ID is 2ba01477. Target voltage is 2903 mV. Listening at :4242...

Fahmi-MEGDICHE commented 10 years ago

Hi morgoth6, Could you please tell me how did you downgrade the ST-Link/V2 firmware revision to v2.J17.S0? Thanks

morgoth6 commented 10 years ago

I was unable to locate older version os ST website, but STLink utility 3.3 (http://www.st.com/web/en/catalog/tools/PF258168) comes with this revision. There is option in menu to upgrade firmware.

Fahmi-MEGDICHE commented 10 years ago

Thank you for your response morgoth6. The version 3.3.0 of ST-Link Utility upgrades to revision V2.J19.S0 and not V2.J17.S0. I found the revision 1.12.3 of ST-LINK firmware upgrade which upgrades to revision V2J14S3 and that solved my 0K flash problem. http://www.st.com/web/en/catalog/tools/FM147/SC1887/PF258165?s_searchtype=keyword#

Fahmi-MEGDICHE commented 10 years ago

I ended up finding version 3.0.0 of ST-LINK Utility in some chineese site. This revision can upgrade the ST-Link firmware to V2.J17.S0. I uploaded it to Dropbox since the original site is very slow. https://www.dropbox.com/s/mrhft4ib9jp5myz/STM32%20ST-LINK%20Utility_v3.0.0.7z

morgoth6 commented 10 years ago

ThX for link. Version 2.17 works just fine.

UweBonnes commented 10 years ago

Recent STLink firmware has some changes and without further action, and stlink-texane with this firmware keep Reset asserted. With reset asserted, access to the ARM register works, but not to STM core registerts. So 0 kByte flash is read out and debuggerr doesn't work. Possible workarounds:

B.t.w. I can run the windows stlink programs, e.g. firmware update in wine after writing a replacement dll for the stlinkusbdriver dll in the stlink branch of https://github.com/UweBonnes/wine.git

However getting things up is not for the faint hearted,..

lazureus commented 10 years ago

Hello, I've encountered problem which you're describing here with STM32F405RTGT6 rev.Z. However downgrading or upgrading of st link firmware didn't help. Please note that I'm not trying to connect to the STM32F4DISCOVERY kit but to my own PCB. Connecting with the chip is working smoothly under ST-Link Utility in windows. In windows I got previously old version of the ST-Link however after installing patch from this thread it started working: https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2FSTM32Discovery%2FSTM32F4DISCOVERY%20%20%20Cannot%20connect%20to%20the%20MCU%20device&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=5168

Does this patch missing in current version of texane st link ? If it's not an issue could you please advice me how should I follow up the 2 others workarounds ? Thanks in advance.

lazureus commented 10 years ago

Please find log from st util

2014-09-23T14:23:41 DEBUG src/stlink-common.c: stlink current mode: mass
2014-09-23T14:23:41 DEBUG src/stlink-common.c: stlink current mode: mass
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2014-09-23T14:23:41 INFO src/stlink-common.c: Loading device parameters....
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** stlink_core_id ***
2014-09-23T14:23:41 DEBUG src/stlink-common.c: core_id = 0x2ba01477
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** stlink_read_debug32 10016413 is 0xe0042000
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x1fff7a20
2014-09-23T14:23:41 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2014-09-23T14:23:41 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0 bytes (0 KiB) in pages of 16384 bytes
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** looking up stlink version
2014-09-23T14:23:41 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2014-09-23T14:23:41 DEBUG src/stlink-common.c: stlink pid     = 0x3748
2014-09-23T14:23:41 DEBUG src/stlink-common.c: stlink version = 0x2
2014-09-23T14:23:41 DEBUG src/stlink-common.c: jtag version   = 0x11
2014-09-23T14:23:41 DEBUG src/stlink-common.c: swim version   = 0x0
2014-09-23T14:23:41 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** stlink_reset ***
Chip ID is 00000413, Core ID is  2ba01477.
2014-09-23T14:23:41 DEBUG src/stlink-common.c: *** reading target voltage
2014-09-23T14:23:41 DEBUG src/stlink-common.c: target voltage = 2895mV
Target voltage is 2895 mV.
Listening at *:4242...
UweBonnes commented 10 years ago

"lazureus" == lazureus notifications@github.com writes:

lazureus> Please find log from st util 2014-09-23T14:23:41 DEBUG

Did you have a look at the defintion of the F205 flash size register in the datasheet and in our code? Probably there is something wrong there. Perhaps try to fix yourself...

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

lazureus commented 10 years ago

Hi, Why I should look at definition of the F205 flash size device register when I got problem with STM32F405RTGT6 ? I've checked newest RM0090 rev. 7 what is the address of flash size register and ref says that it is 0x1FFF7A22 (section 39.2). I've compared also this with file :

stlink-common.h line : 199 
SHA1: 3e1ce9e75d4530d248d4661046a9b0e6e3f75b03

and it look as the same register. The weird thing is that it happened a few times that st-util was able to read flash size, then I've connected with gdb and loaded file successfully.

lazureus

UweBonnes commented 10 years ago

"lazureus" == lazureus notifications@github.com writes:

lazureus> Hi, Why I should look at definition of the F205 flash size
lazureus> device register when I got problem with STM32F405RTGT6 ?

Sorry for the confusion. I didn't reread my reply. lazureus> I've lazureus> checked newest RM0090 rev. 7 what is the address of flash size lazureus> register and ref says that it is 0x1FFF7A22 (section lazureus> 39.2). I've compared also this with file :

lazureus> stlink-common.h line : 199 SHA1:
lazureus> 3e1ce9e75d4530d248d4661046a9b0e6e3f75b03

lazureus> and it look as the same register. The weird thing is that it
lazureus> happened a few times that st-util was able to read flash size,
lazureus> then I've connected with gdb and loaded file successfully.

I had a similar problem too. If I remember right, there was some illegal access to the target CPU and afterwards all register accesses failed.

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

lazureus commented 10 years ago

Hi, I think I've found where was my problem, one of the wires was poorly soldered that's why it worked sometimes but most of the time it was not. I'm sorry for bothering you guys. Right now st-util is reading flash size without trouble.

lazureus

diegogeid commented 9 years ago

Hello, it have past long time from the report of this issue and I have not seen changes, can anybody suggest me the best solution? (I need to use my STM32F4-discovery board and my own board in Linux, and I'm experimenting the "Flash: 0 bytes" problem, all the programs in the package reports 0 bytes of flash).

Thanks! (Sorry for my english) Diego

UweBonnes commented 9 years ago

"diegogeid" == diegogeid notifications@github.com writes:

diegogeid> Hello, it have past long time from the report of this issue
diegogeid> and I have not seen changes, can anybody suggest me the best
diegogeid> solution? (I need to use my STM32F4-discovery board and my
diegogeid> own board in Linux, and I'm experimenting the "Flash: 0
diegogeid> bytes" problem, all the programs in the package reports 0
diegogeid> bytes of flash).

Did you have a look at openocd HEAD from git. ST-Link is well supported.

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

hyOzd commented 8 years ago

Those who are trying to program their own boards with stm32f4-discovery kit, remember to remove SB11 resistor as documented in discovery kit user guide (p.15). Otherwise st-link cannot reset your hardware.

ghost commented 8 years ago

\ I believe the st-link downgrading is unreliable fidgeting and to be honest quite ridiculous. **

You have an "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators"? You use UBUNTU 14.04 LTS? Your stm32f103c8t6 FLASH being reported as 0K by st-util giving you a headache? You got yourself OpenSTM32.org (ac6) Eclipse based IDE installed (use the one time fits all installation - not from an existing eclipse installation!!!)?

In your SW4STM32 (ac6) Eclipse go to menu 'Help' -> 'Install new software' then 'add' and use name: 'GNU ARM eclipse' and URL: 'http://gnuarmeclipse.sourceforge.net/updates/ (if it moved look for it by googling 'gnuarmeclipse'. Don't be lazy.). Gnuarmeclipse has the Blinky examples integrated. You'll have both the ac6 and gnuarmeclipse conveniences to start projects and learn something. When you're enough steps ahead you might want to install CubeMX from the ST website. It's not really complete and to my opinion still in beta so that's why I don't quite recommend it.

I have stlink.git and installed it throught the instructions provided in the tutorial.pdf file in the doc/tutorial folder in the st-link texane zip file which I downloaded here: https://github.com/texane/stlink or just from the Github hyperlink directory page itself. If you don't understand what I'm saying here then stm32fxx and github is nothing for you, go back to Arduino ;)

The flash reporting being 0 k I solved by providing the proper power supply. By that I mean 3 volts to the 3volts pin of the China/Ebay/Aliexpress "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators".

You got that? As soon as I did NOT use a 5 volts supply to the 5volts pin of my "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators" and DID NOT ANYMORE connect any reset wires to the the "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators" the flash memory capacity got reported properly.

ADDITIONAL INFORMATION FOR COMPLETION:

I DID NOT use any USB power supplying ti "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators". I used the STM32F407VGT-Discovery board's ST-LINK/SWD pcb section to supply all necessary electric signals to the "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators". That is to say by isolating it first from the the STM32F407VGT + discovery board peripherals. Disconnect ST-LINK jumpers and JP1 of the Discovery board. If you don't understand what I'm writing here go back to Arduino ;)

Connect grounds between Discovery board and "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators".

Connect 3V from Discovery board to 3.3volts pin of the "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators".

From top (Discovery board components up vertically positioned) right the grouped 6 SWD pins the 2nd (CLK) and 4th (DIO) to the CLK-pin en DIO-pin on the "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators".

Don't bother about the jumpers on the "STM32F103C8T6 China Ebay Aliexpress PCB with PWR and PC13 as LED indicators". Leave them as they are provided (default) both on '0'.


In SW4STM32 (ac6) Eclipse IDE make a new C project and choose GNU ARM STM32F1 along the way. Select both 'Debug' and 'Release'. Keep the default settings (make sure the choice Blinky LED! is made.)

In SW4STM32 (ac6) Eclipse IDE go to 'External Tools Configuration'. Look for it yourself, don't be lazy. Hint: It's somewhere in the user interface of eclipse debug/run section - pop down menu.

What you need to do now is instructed starting from when the st-link flash is explained how to be installed: "Getting started ARM cortex M4 STM32 with Eclipse - Debugger" on YouTube.


The LED won't blink for the reason the gnuarm Blinky example is blinking PC12 instead of PC13. Look inside main.c and find your way to make changes. Self learning is the key to progress and independence. Spoon feeding is the path to slavery.

Good luck!


xor-gate commented 8 years ago

Thanks all for your feedback and contribution. It should be fixed and working with v1.2.0 or current master. Feel free to open a new issue when there are still troubles.