[riot-users] Trouble with using STM32F0-Discovery

anand srivastava anandsr21 at gmail.com
Mon May 4 10:57:19 CEST 2015


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>
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> 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 listusers at riot-os.orghttp://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/30433afc/attachment.html>


More information about the users mailing list