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

[Tesla DeLorean]

Posted on June 18, 2014 at 01:43

Not sure I fully understand the complaint. The PC never gets set to the bottom of memory, 0x08000188 is likely the ResetHandler address that the STM32 loads when it starts, ie SP @ +0, PC @ +4

The memory that gets shadowed at zero will depend on the BOOTx pins. The address the image get built for is determined by the linker, and it's script or .ICF file.

[Phillips Jr..Clyde]

Posted on June 18, 2014 at 03:45

I agree with all you showed me here. Both boot jumpers are on. My ST-link download shows my intvec is located at 0x08000000. Yet it does not set the sp according to intvec+0 or set the pc to intvec+4. The pc starts at 0x08000188 ( right after the complete intvec ) The sp is unset.

This is an asm only project, if that makes a difference. When I run in the simulator it does start up correctly.

[Phillips Jr..Clyde]

Posted on June 18, 2014 at 23:20

I've made progress editing the .icf file.

now my issue seems to be that I allocate data with dc32 in a .noinit section and the download now aborts with the ''Writing outside flash memory at address 0x10000000, which is defined as RAM in the .icf This entry in the .icf triggers that abort message: place in RAM { section .noinit }; If I don't place the .bss or .noinit the linker complains: no block or place matches ....''rw data section .noinit in myapp..''

[Tesla DeLorean]

Posted on June 19, 2014 at 00:39

I've had this conversation before, but can't find the thread right now.

I'm not an IAR user, so I'll couch this in Keil terms. When you put code in to FLASH, part of that code needs to copy constants/structures into RAM as it starts. The C compiler and linker normally handle this by grouping up the statics and placing them after your code in FLASH, when the start up code runs it copies these into RAM, and zeros other BSS space that is defined. When you use DCD or DC32 in RAM the linker script (scatter file, or ICF file) needs to describe this as part of the FLASH Load Region. The debugger's FLASH algorithms only write into FLASH, and not SRAM or CCM. In IAR this copy/zero code, and the tables generated by the linker, are processed by code in __iar_program_start prior to it calling the C main() subroutine. You will have to replace this functionality, or manage the RAM and the copying of initialization values, prior to running your own code. If things are truly constants, load them as literals, and let the assembler put them in a ''literal pool'' in the slack space after a function or unconditional branches. In Keil you can side step the FLASH loaders by using debugger initialization scripts, which can load an .AXF/ELF file directly into assorted RAM regions.

[Phillips Jr..Clyde]

Posted on June 19, 2014 at 01:43

I'll conclude this thread by acknowledging that this seems to be generic linker / flash loader stuff, and my situation probably need to be resolved by IAR or a IAR guru type.

However I use this same code with the same .icf setting in a NXP project with segger J-Link w/o issues. I have no need to initialize the static DC32 .noinit section. I only need the linker to link the labels at their . relevant addresses. This seems to be a bias in the linker re: c vs assembly code. I have no ''initalize by copy'' or ''do not initialize'' directives. And the linker require I use a ''place in RAM_region { section .noinit };'' Which is useless to me since it is just allocated space with address labels my code refer's to. If you or anyone can explain why allocated .noinit data with labels to link when referenced by code causes the linker to complain it's writing outside of flash i am interested to know! I'll create a new thread as the .icf file is the controlling input to ST-Link USB to the STM32 Discovery Board. Cheers, Clyde

[Tesla DeLorean]

Posted on June 19, 2014 at 02:21

If it we me, I'd inspect the .ELF object file to understand exactly what the linker had generated and why it was there were some references to RAM (0x10000000, or 0x20000000) that the debugger seemed to want to push out. That way I'd know if the linker had done something stupid, or if the ST-LINK DLL from IAR was behaving in a materially wrong, or inconsistent way, compared to the J-LINK. My guess would be it's the linker (wanting some directives you've elected not to use), or the DLL failing to recognize zero length, or noinit sections.

The ST-LINK has historically been a bit of a half-assed solution, but IAR, KEIL, etc are responsible for the interface layer to their tools. Either way, I'd suggest you package up a project template, including the .ICF, .MAP and .ELF(out, whatever), so that others might inspect and replicate your experiment.

[Phillips Jr..Clyde]

Posted on June 19, 2014 at 04:27

Thanks, Clive.

The .map and and .sym files look great, just what I need it to be. the code does load and stores to the CCM but none of the .noinint allocations have any sort of initializers. To share the project would I zip it and attach it here? Thanks, Clyde

[Tesla DeLorean]

Posted on June 19, 2014 at 04:47

Yes, you could attach a ZIP file here, it's tolerant of most content/sizes

[Phillips Jr..Clyde]

Posted on June 19, 2014 at 05:29

I'll post it in @ 16 hours. I'm away.

Getting to load and step to entry is all I need. Thanks again!