[riot-users] Trouble with using STM32F0-Discovery

anand srivastava anandsr21 at gmail.com
Mon May 4 11:26:42 CEST 2015


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

thanks and regards,
-anand


On Mon, May 4, 2015 at 2:27 PM, anand srivastava <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>
> 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/0c8a6ee2/attachment-0001.html>


More information about the users mailing list