[riot-users] Trouble with using STM32F0-Discovery

Hauke Petersen hauke.petersen at fu-berlin.de
Mon May 4 13:06:23 CEST 2015


Hi,

just send you my image via private mail.

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

Cheers,
Hauke


On 04.05.2015 11:26, anand srivastava wrote:
> 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 at gmail.com <mailto:anandsr21 at gmail.com>
>
> thanks and regards,
> -anand
>
>
> On Mon, May 4, 2015 at 2:27 PM, anand srivastava <anandsr21 at gmail.com 
> <mailto:anandsr21 at gmail.com>> wrote:
>
>     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
>
>     On Mon, May 4, 2015 at 1:58 PM, anand srivastava
>     <anandsr21 at gmail.com <mailto:anandsr21 at gmail.com>> wrote:
>
>         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
>
>         On Mon, May 4, 2015 at 1:45 PM, Hauke Petersen
>         <hauke.petersen at fu-berlin.de
>         <mailto:hauke.petersen at fu-berlin.de>> wrote:
>
>             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
>
>
>
>
>             On 04.05.2015 09:33, anand srivastava wrote:
>>             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 = <optimized out>
>>
>>             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
>>
>>
>>
>>
>>             _______________________________________________
>>             users mailing list
>>             users at riot-os.org  <mailto:users at riot-os.org>
>>             http://lists.riot-os.org/mailman/listinfo/users
>
>
>             _______________________________________________
>             users mailing list
>             users at riot-os.org <mailto:users at riot-os.org>
>             http://lists.riot-os.org/mailman/listinfo/users
>
>
>
>
>
>
> _______________________________________________
> users mailing list
> users at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/users/attachments/20150504/7bb5c9be/attachment-0001.html>


More information about the users mailing list