EWARM St-Link debug of STM32F4 Discovery board not using .intvec

[Phillips Jr..Clyde]

Posted on June 17, 2014 at 23:59

The PC is always pointing to 0x08000188 (after the .intvec allotment )

So as a workaround I put a B <label> there. The label value is incorrect. This is not using the flash loader. If I use it it fails citing writes to the CCM area. All the generic STM32F4 manual don't mention the 0x08000000 as even being in the memory map. And i can't set the intvec to flash load at 0x0. Is there information about these issues anywhere? Thanks Clyde

[Phillips Jr..Clyde]

Posted on June 19, 2014 at 21:37

Here is a simplified version of my project.

It was created with IAR Embedded Workbench 7.0 It looks as it should to me yet ST-LINK completes code download then bombs complaining of writing outside flash at 0x10000000. The Reset_Handler function in startup_stm32f4xx.s: Reset_Handler B FM3_COLD where FM3_COLD and the CCM allocations are in FISH_STM_M3_SYSTEM.s stm32f407xG.icf is used in the project. stm32f4xx_flash.icf is not, ie an artifact. Thanks Clyde I'm really looking forward to learning what I'm missing ________________ Attachments : STM32F4_Disco.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I01p&d=%2Fa%2F0X0000000bSO%2FPYYFpG.kvGF1xNrOZObTpM0RyeboHC5S8USAZzx.a1k&asPdf=false

[Tesla DeLorean]

Posted on June 20, 2014 at 06:01

The linker appears to be describing a 46685 byte region at 0x10000000, that appears to be zeros and loading. Where as the region at 0x20000000 has no data behind it.

...
 Section Header #4
sh_name 0000001B (A1 rw)
sh_type 00000001 (***_PROGBITS)
sh_flags 00000006 (-AX)
sh_addr 08000000
sh_offset 00000034
sh_size 00000188
sh_link 00000000
sh_info 00000000
sh_addralign 00000004
sh_entsize 00000001
Section Header #5
sh_name 00000021 (P1 ro)
sh_type 00000001 (***_PROGBITS)
sh_flags 00000006 (-AX)
sh_addr 08000188
sh_offset 000001BC
sh_size 0000020C
sh_link 00000000
sh_info 00000000
sh_addralign 00000004
sh_entsize 00000001
Section Header #6
sh_name 00000027 (P2 rw)
sh_type 00000001 (***_PROGBITS)
sh_flags 00000003 (WA-)
sh_addr 10000000
sh_offset 000003C8
sh_size 0000B65D
sh_link 00000000
sh_info 00000000
sh_addralign 00000004
sh_entsize 00000001
Section Header #7
sh_name 0000002D (A2 rw)
sh_type 00000008 (***_NOBITS)
sh_flags 00000003 (WA-)
sh_addr 2000E000
sh_offset 0000BA28
sh_size 00002000
sh_link 00000000
sh_info 00000000
sh_addralign 00000008
sh_entsize 00000001
 ... 

[Phillips Jr..Clyde]

Posted on June 20, 2014 at 06:43

Yes I allocate all 64k of the CCM at 0x10000000. I use DC32 to increment the address counter for the labels I use. The SRAM1 and SRAM2 would not be used by my code until run-time.

The memory being allocated this way has not been a problem. I can flash my code and play with my memory on several other boards. And this code runs in this chips simulator. It's only 40 - 50 lines of assembly code. Load registers to fill CCM with a pattern, initialize 12 words and bomb. All I need of the ST-Link debugger is to run the code after it downloads it. The code loads but then the ST-Link quits with two error messageboxes, showing the message ''Writing outside flash memory at address 0x10000000'' My code is small and not doing this! Can I omit the section and still have my labels link? Do I need to hand calculate and code the labels I reference in my code? Allocating in .noninit for label addresses is what I'm doing here. Am I doing it wrong~) Thanks, Clyde

[Tesla DeLorean]

Posted on June 20, 2014 at 12:52

The problem seems to be with what the linker does, the ST-LINK is just programming the portions it was directed, the J-LINK might recognize the regions as Cortex-Mx memory, but the issue is in the .ELF(OUT) file.

I don't use IAR much, but I think the issue can be resolved in the .ICF file the linker is processing. I'm not sure it recognizes ''.noinit'' as a magic section, it needs attributes, and you could name it anything you wanted as long as the linker script was coherent with the naming. I think this line would be appropriate: do not initialize  { section .noinit };

[Phillips Jr..Clyde]

Posted on June 20, 2014 at 23:30

I tried all the do do not initialize stuff and renamimng the sections etc and none fixed it. If  a section is declared the linker will force you to ''place'' it.

So I thought I had solved the problem by not declaring a section. This places all the DCxx allotments in flash which won't work. But it loads w/o error!. It is looking like ST-Link a mishandling of  any section that is in RAM... Is there a way to strip the section out after the link so the download is fooled? Or set the here ( . ) pointer so the DC allot without a SECTION declaration?

[Phillips Jr..Clyde]

Posted on June 23, 2014 at 22:40 This thread can be closed! I made a rooky mistake and added a few DCx ''variables'' where what I meant was DSx. The DCx created constants that were inappropriate for Ram ( .bss .noinit, etc ) Fixed this and download and debug working fine! Clyde