cancel
Showing results for 
Search instead for 
Did you mean: 

Infinite_Loop problem with STM32F030CCT6

Thomas Jespersen
Associate III
Posted on September 18, 2015 at 00:31

Hi all ST users.

We have just replaced the STM32F030C8T6 microprocessor on some of our working boards to upgrade them with the larger STM32F030CCT6. A difference that should be both pin-compatible, periphiral compatible and firmware compatible.

We are using CoIDE for the development where we weren't able to find the STM32F030CCT6 but this should also mainly cause changes with the debugger functionality, where we are using a J-Link anyways, which supports the chip.

We have changed both the Startup file to the proper one, adjusted the linker file to match the changed flash and RAM size and have also changed the DEFINE symbols to match the chip change.

Unfortunately we are experiencing some very wierd issues when programming and debugging the chip.

If we just test a simple blink example from a main loop everything works fine.

But if we use our old original and working project, which includes FreeRTOS, where we were running out of memory which is the reason for upgrading the chips, the chip crashes.

If we only use one task (a blink task) it works and doesn't crash.

But if we include the main processing task the chip will crash into Infinite_Loop eventually. Sometimes it does it right from the beginning (debugging won't even start), other times when stepped thru it will all of a sudden jump to the Infinite_Loop.

In the debugging terminal the only information we get could be this

Program received signal SIGTRAP, Trace/breakpoint trap.WWDG_IRQHandler () at ...\Drivers\CMSIS\Device\ST\STM32F0xx\Source\Templates\gcc\startup_stm32f030xc.s:124

124  b Infinite_Loop

Cannot access memory at address 0xffffffff

0690X000006034ZQAQ.jpg

When programming/debugging this is the information presented in the Console window

monitor flash download = 1

monitor semihosting enable

monitor reset 2

monitor halt

Loading section .isr_vector, size 0xbc lma 0x8000000

Loading section .text, size 0x283e8 lma 0x80000bc

Loading section .rodata, size 0x10ac lma 0x80284a8

Loading section .ARM, size 0x8 lma 0x8029554

Loading section .init_array, size 0x8 lma 0x802955c

Loading section .fini_array, size 0x4 lma 0x8029564

Loading section .data, size 0x8e4 lma 0x8029568

Loading section .jcr, size 0x4 lma 0x8029e4c

Start address 0x800dac4, load size 171596

I hope this description could give you an idea of our problem and maybe ring a bell for a solution.

Thank you in advance.

Best regards

Thomas Jespersen

#stm32f030 #stm32f030cct6
1 REPLY 1
Posted on September 18, 2015 at 01:29

Do you have a watchdog, or do you think that's just a side-effect of it being in the infinite loop and not kicking it?

Quick review of the docs suggest the other differences include 1 extra timer, and 4 extra USARTs. I would probably make sure to define IRQ handlers for all available slots (M0 supports 32 as I recall), and try to see if I could get to something more specific than the general handler code it's falling into now.

Two less GPIO, presumably the supply pins you mentioned in the other thread. Make sure there's nothing special going on with the lost pins.

Double check flash wait state, and prefetch settings.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..