Infinite_Loop problem with STM32F030CCT6

[Thomas Jespersen]

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 thisProgram received signal SIGTRAP, Trace/breakpoint trap.WWDG_IRQHandler () at ...\Drivers\CMSIS\Device\ST\STM32F0xx\Source\Templates\gcc\startup_stm32f030xc.s:124124  b Infinite_LoopCannot access memory at address 0xffffffffWhen programming/debugging this is the information presented in the Console windowmonitor flash download = 1monitor semihosting enablemonitor reset 2monitor haltLoading section .isr_vector, size 0xbc lma 0x8000000Loading section .text, size 0x283e8 lma 0x80000bcLoading section .rodata, size 0x10ac lma 0x80284a8Loading section .ARM, size 0x8 lma 0x8029554Loading section .init_array, size 0x8 lma 0x802955cLoading section .fini_array, size 0x4 lma 0x8029564Loading section .data, size 0x8e4 lma 0x8029568Loading section .jcr, size 0x4 lma 0x8029e4cStart address 0x800dac4, load size 171596I hope this description could give you an idea of our problem and maybe ring a bell for a solution.Thank you in advance.Best regardsThomas Jespersen #stm32f030 #stm32f030cct6

[Tesla DeLorean]

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.