Cannot load .elf onto STM32F0-Discovery

[szczys]

Cannot load .elf onto STM32F0-Discovery

[texane]

Hi,

thanks for your email.

sorry for the late reply, I am quite busy until the week end. I have a
F0 kit waiting to be
tested at home, but no time so far. I may have a look this week end.
Regarding the error
and the output log, I would start by putting a few debugging printfs
in the RAM loading
function, which is easily locatable in the source code...

Keep me updated if you make any progress, and I will have a look this week end.

Cheers,

Fabien.

2012/5/31 szczys
[email protected]:

I just got the new discovery board (STM32F0-Discovery) which has an STM32F051 chip on it. It still uses the ST-LINK version 2, and I can get st-util to connect. From the arm gdb I can continue and halt the firmware on the board, but I cannot load the blink example. It gives me "Load Failed".

I did alter the Makefile and main.c of the blink example to include the compiler flags and register mapping for this chip. I think the issue is with st-util talking to the chip. Below you'll find outputs from it, as well as the GDB session. It looks like the chip id is reading 00000000 which is a problem and I'm wondering if there is memory mapping issue? I don't mind lending a hand to bring support for this chip but I'm at a loss as to what to do. Any advice? Thanks!

st-util output:

mike@krusty:~/compile/stlink.git$ ./st-util
2012-05-30T21:50:25 INFO src/stlink-common.c: Loading device parameters....
2012-05-30T21:50:25 WARN src/stlink-common.c: unknown chip id! 0
Chip ID is 00000000, Core ID is  0bb11477.
KARL - should read back as 0x03, not 60 02 00 00
init watchpoints
Listening at *:4242...
GDB connected.
recv: qSupported:multiprocess+;qRelocInsn+
query: Supported;multiprocess+;qRelocInsn+
send: PacketSize=3fff;qXfer:memory-map:read+
recv: !
send: OK
recv: Hg0
send:
recv: ?
send: S05
recv: Hc-1
send:
recv: qC
send:
recv: qAttached
query: Attached;
send:
recv: g
send: 060000003817000018000000000000c00a000000010000000100000038170000ffffffffffffffffffffffffffffffffffffffffe80300206f010008f6010008
recv: qXfer:memory-map:read::0,fff
query: Xfer;memory-map:read::0,fff
Xfer: type:memory-map;op:read;annex:;addr:0;length:4095
send: m<?xml version="1.0"?><!DOCTYPE memory-map PUBLIC "+//IDN gnu.org//DTD GDB Memory Map V1.0//EN"     "http://sourceware.org/gdb/gdb-memory-map.dtd"><memory-map>  <memory type="rom" start="0x00000000" length="0x0"/>  <memory type="ram" start="0x20000000" length="0x0"/>  <memory type="flash" start="0x08000000" length="0x0">    <property name="blocksize">0x0</property>  </memory>  <memory type="ram" start="0x40000000" length="0x1fffffff"/>  <memory type="ram" start="0xe0000000" length="0x1fffffff"/>  <memory type="rom" start="0x00000000" length="0x0"/>  <memory type="rom" start="0x1ffff800" length="0x10"/></memory-map>
recv: qXfer:memory-map:read::26d,d92
query: Xfer;memory-map:read::26d,d92
Xfer: type:memory-map;op:read;annex:;addr:621;length:3474
send: l
recv: m80001f6,4
send: a1483817
recv: qTStatus
query: TStatus;
send:
recv: vKill;a410
send: OK
recv: ?
send: OK
cannot recv: -2
mike@krusty:~/compile/stlink.git$

arm-none-eabi-gdb output:

mike@krusty:~/compile/stlink.git/example/blink$ arm-none-eabi-gdb
GNU gdb (Sourcery G++ Lite 2011.03-42) 7.2.50.20100908-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>.
(gdb) tar ext :4242
Remote debugging using :4242
0x080001f6 in ?? ()
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb) load blink_F0.elf
Loading section .text, size 0x48 lma 0x20000000
Load failed
(gdb) disconnect
Ending remote debugging.
(gdb)

diff of the blink example files:

diff --git a/example/blink/Makefile b/example/blink/Makefile
index cf7221d..60fab84 100644
--- a/example/blink/Makefile
+++ b/example/blink/Makefile
@@ -12,8 +12,9 @@ DEF_CFLAGS+=-Wl,-Ttext,0x20000000 -Wl,-e,0x20000000
 CFLAGS_VL=$(DEF_CFLAGS) -mcpu=cortex-m3 -DCONFIG_STM32VL_DISCOVERY=1
 CFLAGS_L=$(DEF_CFLAGS) -mcpu=cortex-m3 -DCONFIG_STM32L_DISCOVERY
 CFLAGS_F4=$(DEF_CFLAGS) -mcpu=cortex-m4 -DCONFIG_STM32F4_DISCOVERY=1
+CFLAGS_F0=$(DEF_CFLAGS) -mcpu=cortex-m0 -DCONFIG_STM32F0_DISCOVERY=1

-all: blink_32VL.elf blink_32L.elf blink_F4.elf
+all: blink_32VL.elf blink_32L.elf blink_F4.elf blink_F0.elf

 %.bin: %.elf
       $(OBJCOPY) -O binary $^ $@
@@ -24,6 +25,8 @@ blink_32L.elf: main.c
       $(CC) $(CFLAGS_L) $^ -o $@
 blink_F4.elf: main.c
       $(CC) $(CFLAGS_F4) $^ -o $@
+blink_F0.elf: main.c
+       $(CC) $(CFLAGS_F0) $^ -o $@

 clean:
       rm -rf *.elf
diff --git a/example/blink/main.c b/example/blink/main.c
index b70a136..26fcca0 100644
--- a/example/blink/main.c
+++ b/example/blink/main.c
@@ -58,6 +58,26 @@ static inline void setup_leds(void)
       (1 << (13 * 2)) | (1 << (14 * 2)) | (1 << (15 * 2));
 }

+#elif CONFIG_STM32F0_DISCOVERY
+
+#define GPIOC 0x48000800 /* port C */
+#define GPIOC_MODER (GPIOC + 0x00) /* port mode register */
+#define LED_PORT_ODR (GPIOC + 0x14) /* port output data register */
+
+#define LED_BLUE (1 << 8) /* port C, pin 8 */
+#define LED_GREEN (1 << 9) /* port C, pin 9 */
+#define LED_ORANGE 0
+#define LED_RED 0
+
+void _tmain(void) {
+       main();
+}
+static inline void setup_leds(void)
+{
+  /* configure port 8 and 9 as output */
+  *(volatile uint32_t*)GPIOC_MODER |= (1 << (9* 2)) | (1 << (8 * 2));
+}
+
 #else
 #error "Architecture must be defined!"
 #endif /* otherwise, error */

---

Reply to this email directly or view it on GitHub:
#85

[szczys]

Well, here's something. The CPUID for the F0 chip is different that what stlink is looking for. Below is a diff file which allows me to read the correct chip address. Now I'm trying to figure out how to craft a set of parameters for the device[] array in stlink-common.h

diff --git a/src/stlink-common.c b/src/stlink-common.c
index 29640fd..5cc21f7 100644
--- a/src/stlink-common.c
+++ b/src/stlink-common.c
@@ -394,6 +394,7 @@ uint32_t stlink_core_id(stlink_t *sl) {

 uint32_t stlink_chip_id(stlink_t *sl) {
     uint32_t chip_id = stlink_read_debug32(sl, 0xE0042000);
+    if (chip_id == 0) chip_id = stlink_read_debug32(sl, 0x40015800);   //Try Corex M0 DBGMCU_IDCODE register address
     return chip_id;
 }

UPDATE: corrected address for DBGMCU_IDCODE

[texane]

Thanks, merged.

Unfortunately I am unable to progress on the F0 this week
end. I will asap.

Fabien.

2012/6/3 szczys
[email protected]:

Well, here's something. The CPUID for the F0 chip is different that what stlink is looking for. Below is a diff file which allows me to read the correct chip address. Now I'm trying to figure out how to craft a set of parameters for the device[] array in stlink-common.h

diff --git a/src/stlink-common.c b/src/stlink-common.c
index 29640fd..5cc21f7 100644
--- a/src/stlink-common.c
+++ b/src/stlink-common.c
@@ -394,6 +394,7 @@ uint32_t stlink_core_id(stlink_t *sl) {

 uint32_t stlink_chip_id(stlink_t *sl) {
    uint32_t chip_id = stlink_read_debug32(sl, 0xE0042000);
+    if (chip_id == 0) chip_id = stlink_read_debug32(sl, 0xE000ED00);   //Try Corex M0 CPUID register address
    return chip_id;
 }

---

Reply to this email directly or view it on GitHub:
#85 (comment)

[szczys]

I got it working! At least the example program runs from RAM, I haven't tested anything else.

The DIFF that previously posted in this issue thread was not good. I was reading the Corex M0 CPUID and should have been reading the DBGMCU_IDCODE register.

To avoid confusion this is fixed in my pull request

[texane]

Hi,

I merged your pull request, thanks for this great work!

Cheers,

Fabien.

2012/6/3 szczys
[email protected]:

I got it working! At least the example program runs from RAM, I haven't tested anything else.

The DIFF that previously posted in this issue thread was not good. I was reading the Corex M0 CPUID and should have been reading the DBGMCU_IDCODE register.

To avoid confusion this is fixed in my pull request

---

Reply to this email directly or view it on GitHub:
#85 (comment)

[Nightwalker-87]

Fixed in #86.