2015-05-12 09:53 AM
Problems getting new STM32 target running
I've developed a project on an STM32F103RB, and am now trying to move it to a F103ZE chip. However I cannot get my code to run.I have changed the linker file to accound for the change in RAM and flash size. I have changed the includes and makefile to point at the stm3210e_eval code instead of stm3210b_eval. In startup_stm32f10x_hd.s the BootRAM is set to 0xF1E0F85F.I have tried copying linker files generated in stm32cube to no avail. When I run more than a simple while(1) loop it seems to fall off the stack. I have been unable to initialise even the systick clock.In the linker script I have seen a couple of variations, with _estack set to either 0x2000FFFF or 0x20010000.It seems like maybe the heap and stack aren't being configured, I have the following in my .ld file:ENTRY(Reset_Handler)
_estack = 0x2000FFFF; /* end of RAM */_Min_Heap_Size = 0; /* required amount of heap */_Min_Stack_Size = 0x400; /* required amount of stack */MEMORY{FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512KRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64K}SECTIONS{ .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) /* Startup code */ . = ALIGN(4); } >FLASH .text : { . = ALIGN(4); *(.text) /* .text sections (code) */ *(.text*) /* .text* sections (code) */ *(.glue_7) /* glue arm to thumb code */ *(.glue_7t) /* glue thumb to arm code */ *(.eh_frame) KEEP (*(.init)) KEEP (*(.fini)) . = ALIGN(4); _etext = .; /* define a global symbols at end of code */ } >FLASH /* Constant data goes into FLASH */ .rodata : { . = ALIGN(4); *(.rodata) /* .rodata sections (constants, strings, etc.) */ *(.rodata*) /* .rodata* sections (constants, strings, etc.) */ . = ALIGN(4); } >FLASH .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH .ARM : { __exidx_start = .; *(.ARM.exidx*) __exidx_end = .; } >FLASH .preinit_array : { PROVIDE_HIDDEN (__preinit_array_start = .); KEEP (*(.preinit_array*)) PROVIDE_HIDDEN (__preinit_array_end = .); } >FLASH .init_array : { PROVIDE_HIDDEN (__init_array_start = .); KEEP (*(SORT(.init_array.*))) KEEP (*(.init_array*)) PROVIDE_HIDDEN (__init_array_end = .); } >FLASH .fini_array : { PROVIDE_HIDDEN (__fini_array_start = .); KEEP (*(SORT(.fini_array.*))) KEEP (*(.fini_array*)) PROVIDE_HIDDEN (__fini_array_end = .); } >FLASH _sidata = LOADADDR(.data); .data : { . = ALIGN(4); _sdata = .; /* create a global symbol at data start */ *(.data) /* .data sections */ *(.data*) /* .data* sections */ . = ALIGN(4); } >RAM AT> FLASH . = ALIGN(4); .bss : { _sbss = .; __bss_start__ = _sbss; *(.bss) *(.bss*) *(COMMON) . = ALIGN(4); _ebss = .; __bss_end__ = _ebss; } >RAM ._user_heap_stack : { . = ALIGN(4); PROVIDE ( end = . ); PROVIDE ( _end = . ); . = . + _Min_Heap_Size; . = . + _Min_Stack_Size; . = ALIGN(4); } >RAM /DISCARD/ : { libc.a ( * ) libm.a ( * ) libgcc.a ( * ) } .ARM.attributes 0 : { *(.ARM.attributes) }}Any help is very much appreciated, as I don't wish to start tearing my hair out just yet. #stm32-stm32f103-stm32f103ze2015-05-12 10:47 AM
Just made some slight progress, if I have the debugger detached then I can light up some debug LEDs, indicating that the code is running.
I don't really want to develop this app with just 3 LEDs to guide me...2015-05-12 12:55 PM
You want the stack address to be even, 4-byte aligned, the processor decrements it before use, so 0x20010000 is an acceptable value, as would 0x2000FFFC
I don't use GNU/GCC a lot, their debugger not at all.If you're looking for templates review the Standard Peripheral Library, and the RIDE tool chain files.Review the .MAP output by the linker to confirm things are where they are supposed to be, and diff the older version of source you have working against the newer stuff that isn't.2015-05-12 01:34 PM
Does your board have a USART? Which one and to what pins?
What pins are the LEDs on?I'll knock together a working template, probably easier than trying to figure out what's going on with yours.2015-05-13 02:32 AM
2015-05-13 05:52 AM
Some slight progress. I found I had VECT_TAB_OFFSET set to 0x6000 as I was previously using a bootloader, but took this out to simplify things. This probably explains some of the initial extreme strange behaviour I was seeing.
Now it's hardfaulting, which I guess is an improvement. I'm going to try a very simple test app next. I've been playing around with the .estack value to see if that makes much difference (it doesn't)2015-05-13 08:35 AM
Attached stand-alone GNU/GCC build for STM32F103ZE
________________ Attachments : f1perf_demo_rev1.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Zn&d=%2Fa%2F0X0000000bbH%2F.D1804BzMMBgUuIDm7Ida90PJyO4tvelhGA4FYl_aOQ&asPdf=false2015-05-13 10:03 AM
Cheers, I'm having problems compiling this:
Linking target: out/stm32f103ze_demo.elf
/opt/arm-gcc/gcc-arm-none-eabi-4_8-2014q1/bin/arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Tstm32f103ze.ld -g -Wl,-Map=out/stm32f103ze_demo.map,--cref,--no-warn-mismatch -Wl,--gc-sections -nostartfiles out/startup_stm32f10x_hd.o out/main.o out/misc.o out/newlib_stubs.o out/stm32f10x_adc.o out/stm32f10x_bkp.o out/stm32f10x_can.o out/stm32f10x_cec.o out/stm32f10x_crc.o out/stm32f10x_dac.o out/stm32f10x_dbgmcu.o out/stm32f10x_dma.o out/stm32f10x_exti.o out/stm32f10x_flash.o out/stm32f10x_fsmc.o out/stm32f10x_gpio.o out/stm32f10x_i2c.o out/stm32f10x_iwdg.o out/stm32f10x_pwr.o out/stm32f10x_rcc.o out/stm32f10x_rtc.o out/stm32f10x_sdio.o out/stm32f10x_spi.o out/stm32f10x_tim.o out/stm32f10x_usart.o out/stm32f10x_wwdg.o out/system_stm32f10x.o -o out/stm32f103ze_demo.elf/opt/arm-gcc/gcc-arm-none-eabi-4_8-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: section .ARM.exidx loaded at [08005e6c,08005e73] overlaps section .data loaded at [08005e6c,0800671f]collect2: error: ld returned 1 exit statusI tried using the pre-compiled elf file but this doesn't seem to do anything either. I need to speak to somebody tomorrow about making a serial cable to check for output there. I really appreciate the help! I'm going to see if I can tweak the linker file to get it compiling. Edit: I found what may be the issue, the new board has what looks like a 25mhz clock, the old board was 12mhz. I'm going to have to confirm this with HW tomorrow2015-05-13 11:14 AM
I can see 25 MHz being a head-ache, this isn't a 105/107 chip. So you'll have some difficult PLL options (HSE, and HSE/2)
I was using GNU/GCC 4.7.2, which I had to hand. Also presuming 8 MHz HSE2015-05-13 11:44 AM
I changed the clock multiplier to 2 (from 6), and things are looking a lot better. I can now run my code, and get lights flashing, and the rest of my code appears to be running.
Will need to verify the exact clock speed tomorrow with the hardware guys, I wish they had mentioned this earlier!Thanks again, I really appreciate all the help. I guess the next problem is figuring out how to turn 25mhz into 72mhz (well 48) so I can get USB running. Worst case I will get them to swap the oscillators out for some sane ones. Update: the 25mhz clock has been swapped out for a 16mhz one. After doing this I was able to get the rest of the app running and USB enumerating. Everything seems to be working now.