cancel
Showing results for 
Search instead for 
Did you mean: 

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

Phillips Jr..Clyde
Associate III
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

This discussion is locked. Please start a new topic to ask your question.
15 REPLIES 15
Phillips Jr..Clyde
Associate III
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
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
 ... 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Phillips Jr..Clyde
Associate III
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

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 };
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Phillips Jr..Clyde
Associate III
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
Associate III
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