Unable to get STM32F103ZE chip working

[GregMusic]

Posted on May 12, 2015 at 18:53

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 = 512K

RAM (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-stm32f103ze

[GregMusic]

Posted on May 12, 2015 at 19:47

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...

[Tesla DeLorean]

Posted on May 12, 2015 at 21:55

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.

[Tesla DeLorean]

Posted on May 12, 2015 at 22:34

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.

[GregMusic]

Posted on May 13, 2015 at 11:32

There's a test port on USART1. 

There's 3 LEDs on GPIOE, pins 2, 3, 4. 

It looks like the code is failing to initialise stage (my systick interrupt doesn't look like it's being called), but I can set the LEDs. 

We're using SWD on the new board, so I don't know if this will affect it. I'm not sure if it's a side effect of something else that the app fails to run at all under the debugger. 

I'll take a look at the mapping now, and it's useful to know about the alignment, I was caught out by something similar when writing a bootloader. I did think it a bit odd that stm32cube was generating this value, other examples I've seen use 0x20010000

Cheers

[GregMusic]

Posted on May 13, 2015 at 14:52

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)

[Tesla DeLorean]

Posted on May 13, 2015 at 17:35

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=false

[GregMusic]

Posted on May 13, 2015 at 19:03

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 status

I 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 tomorrow

[Tesla DeLorean]

Posted on May 13, 2015 at 20:14

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 HSE

[GregMusic]

Posted on May 13, 2015 at 20:44

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.