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 <[email protected]> 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 < > [email protected]> 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 >> [email protected]http://lists.riot-os.org/mailman/listinfo/users >> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.riot-os.org/mailman/listinfo/users >> >> >
_______________________________________________ users mailing list [email protected] http://lists.riot-os.org/mailman/listinfo/users
