(programmed) STM32F030 stucks in the startup (xx.s ) forever. defective batch ??

[AScha.3]

the hole batch of F030C6T6 has same behavior :

can access with ST-Link , program, verify - all ok. read core registers, option bytes...ok.

but then no program start ! chip stays in startup here:

10 tested boards ihave identical behavior. chips coming from PCB assembler , as usual.

I replaced one with a (suspect source , from aliexpress dealer) F030 , then board running as it should.

• can i do anything, to get these boards running?
• if chips have all same defect, how is it possible to passing the wafer test ??

[ONadr.1]

I would try to connect MCU to Cube Programmer and process complete erase of MCU. I suppose you dont use some HW which is not in C6 version.

[AScha.3]

ok, mass erase, full chip erase, prog. verify ok. nothing different.

stall in startup. :sad_but_relieved_face:

[ONadr.1]

Could you send registers values table in infinite loop?

[AScha.3]

see in my post from yesterday, registers at loop. (in black area)

[ONadr.1]

But they are from another bin file. We need from new bin file (for C6 MCU).

[AScha.3]

aaa. ok. BUT : now cpu is running !!

debug waits at program start in "main" , as usual.

just i dont know why...i set optimizer on -O2 (was -O0 );

i tried some times...now again stall in startup.

registers :

 

confusing...

[ONadr.1]

It si weird. Stack pointer (sp) has value 8160byte. Like there is 8kb memory set.

[Tesla DeLorean]

Check linker script (.LD)

Top-of-Stack needs to be 0x20001000 (4KB) or below. Check first vector.

Right now you're faulting directly out of reset, and perhaps into a catch-all handler everything points too.

[AScha.3]

from .LD :

>>>

/* Entry Point */

ENTRY(Reset_Handler)

/* Highest address of the user mode stack */

_estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */

_Min_Heap_Size = 0x200 ; /* required amount of heap */

_Min_Stack_Size = 0x400 ; /* required amount of stack */

/* Memories definition */

MEMORY

{

 RAM   (xrw)   : ORIGIN = 0x20000000,  LENGTH = 4K

 FLASH   (rx)   : ORIGIN = 0x8000000,  LENGTH = 32K

}

/* Sections */

SECTIONS

{

 /* The startup code into "FLASH" Rom type memory */

 .isr_vector :

 {

   . = ALIGN(4);

   KEEP(*(.isr_vector)) /* Startup code */

   . = ALIGN(4);

 } >FLASH

<<<

and in IDE shows:

 

looking ok for me.... or not ?

[Tesla DeLorean]

Expand the isr_vector so we can SEE the content, ie what the processor is actually loading into it's registers at startup, and what over handlers are pointing too.

Check the _estack symbol

That is typically loaded by the processor, and often loaded a second time into SP in ST's startup.s code.

Processor will fault the first time anything pushes onto the stack, ie PUSH LR and then the processor's going to have all kinds of issues because it will try an push context onto the stack, basically double faulting.

[waclawek.jan]

As Clive said above: show beginning of vector table i.e. first couple of words after 0x0800'0000.

But that may be inconclusive, too, the startup code may change SP at its will. It probablyy comes from some "magic" in the startup code, which is given by your toolchain. I wouldn't be surprised if it is result of setting the particular STM32 model in some well hidden window of the IDE.

JW