Trouble with using STM32F0-Discovery

Help archive
1

Hi All,

I am trying to use Riot for an internal project.

I have tested Riot on native. I am stuck on the STM32F0-Discovery, which I expected to be pretty stable. I have the latest code from the repository.

I have flashed the STM32F0-Discovery board with make flash utility, based on the instructions given at https://github.com/RIOT-OS/RIOT/wiki/Getting-started-with-STM32F%5B0%7C3%7C4%5Ddiscovery-boards

I got the following output from openOCD, which seems normal enough to me.

/media/linux-space/anand/Work/IoT/riot/RIOT/dist/tools/openocd/openocd.sh flash

Flashing Target

Open On-Chip Debugger 0.9.0-rc1-dev-00001-gabd7ad0 (2015-04-25-11:22) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 1000 kHz adapter_nsrst_delay: 100 none separate srst_only separate srst_nogate srst_open_drain connect_deassert_srst Info : Unable to match requested speed 1000 kHz, using 950 kHz Info : Unable to match requested speed 1000 kHz, using 950 kHz Info : clock speed 950 kHz Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 2.901302 Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints TargetName Type Endian TapName State

0* stm32f0x.cpu hla_target little stm32f0x.cpu halted target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x0800020c msp: 0x20000b98 target state: halted target halted due to debug-request, current mode: Thread xPSR: 0xc1000000 pc: 0x0800020c msp: 0x20000b98 ** Programming Started ** auto erase enabled Info : device id = 0x20006440 Info : flash size = 64kbytes target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000003a msp: 0x20000b98 wrote 15360 bytes from file /media/linux-space/anand/Work/IoT/riot/RIOT/examples/hello-world/bin/stm32f0discovery/hello-world.hex in 0.900809s (16.652 KiB/s) ** Programming Finished ** ** Verify Started ** target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000b98 verified 14808 bytes in 0.205989s (70.202 KiB/s) ** Verified OK ** shutdown command invoked Done flashing

The board seems to be stuck in reset_handler

Reading symbols from /media/linux-space/anand/Work/IoT/riot/RIOT/examples/hello-world/bin/stm32f0discovery/hello-world.elf…done. Remote debugging using :3333 reset_handler () at /media/linux-space/anand/Work/IoT/riot/RIOT/cpu/stm32f0/startup.c:61 61 for (dst = &_srelocate; dst < &_erelocate; ) { (gdb) p dst

$1 =

The USB to Uart converter has been connected to the prescribed ports TX=PB6 RX=PB7 GND=GND, but is not getting any output, probably because the board is stuck.

I am sure I am missing something pretty basic, but I have no clue as to what it is. The code looks proper enough. Thanks for any ideas on how to move ahead.

regards, -anand

2

Hi,

just checked, the example is running just fine for me. I am using: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch and Open On-Chip Debugger 0.9.0-dev-00415-g2d4ae3f-dirty (2015-04-20-15:09)

Did you cross the pins for your UART converter (TX stm board -> RX UART converter)?

Otherwise it would be helpful if you could state the details on your toolchain and openocd version.

Let’s fix this!

Cheers, Hauke

3

Hi Hauke,

Thanks for the prompt response.

I have

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150303 (release) [ARM/embedded-4_9-branch revision 221220]

Open On-Chip Debugger 0.9.0-rc1-dev-00001-gabd7ad0 (2015-04-25-11:22)

I have checked the RX/TX pins several times now :-).

Also the debugger should not connect at that point.

I guess I should try with the older GCC.

regards, -anand

4

Hi,

I have tried with the older GCC, still getting the same result.

Is it possible that the problem is with the memory layout that is being produced by the compiler.

(gdb) p &_etext $2 = (uint32_t *) 0x8003790 (gdb) p &_erelocate $3 = (uint32_t *) 0x20000070 <uart_rx_mutex> (gdb) p &_srelocate $4 = (uint32_t *) 0x20000000 <heap_top> (gdb) p &_szero $5 = (uint32_t *) 0x20000070 <uart_rx_mutex> (gdb) p &_ezero $6 = (uint32_t *) 0x20000718 (gdb) p &_sstack $7 = (<data variable, no debug info> *) 0x20000718 (gdb) p &_estack $8 = (uint32_t *) 0x20000918 (gdb) p &_sfixed $9 = (<text variable, no debug info> *) 0x8000000 <interrupt_vector> (gdb) p &_efixed $10 = (<text variable, no debug info> *) 0x8003790

What is the expected memory layout? Is there a page for that?

regards, -anand

5

Hi Hauke,

Those addresses seem to be proper. Checked in include/stm32f051x8.h

Is it possible to send me the image that is being built at your end.

I will try to run that one here. That will tell me whether the problem is with the compiler or the OpenOCD.

That file zipped should be about 100kb. You can send it to me directly anandsr21@gmail.com

thanks and regards, -anand

6

Hi,

just send you my image via private mail.

The memory layout seems to be correct as I see it, interesting…

Cheers, Hauke