STM32F303 Production Programming

[George.P]

Posted on May 04, 2015 at 15:38

Hello,

I have a custom board with STM32F303CCT6, firmware generated by CubeMX, compiled on IAR 7.4.Everything runs correctly in debug mode, when attached on Segger JLink and IAR.When I disconnect the debugger and power reset the board, it doesn't reboot, it just stays idle.I have also programmed it with J-Flash (.bin and .hex) on 0x800 0000 and it still stays idle. BOOT0 is low and NRESET is high. The MCU is powered externally (not from jLink) with 3V3.Any ideas on what I should check are greatly appreciated.George #debug #cubemx #printf #assert

[pedro23]

Posted on May 04, 2015 at 17:40

Did you enable IWDG or WWDG? watchdog is usually disabled with jtag connected

[Tesla DeLorean]

Posted on May 04, 2015 at 17:58

Reset not driving high with a push-pull driver though, right?

You'll have to start instrumenting your code from the point it enters the ResetHandler, to main() and beyond. Use GPIO, LED or USART to plot progress to understand what's broken.Pay particular attention to all the clocks, the debugger may enable peripheral clocks that it requires, make sure you enable all those you require.Have a working Hard Fault Handler so you can understand if it got there.

[George.P]

Posted on May 05, 2015 at 07:04

Hello again,

I have found the culprit that caused the different behaviour between debug and production.CubeMX generates asserts for the various peripheral settings, e.g. ADC sample rate.One such assert is 

assert_param(IS_ADC_REGULAR_DISCONT_NUMBER(hadc->Init.NbrOfDiscConversion));

When the assertion fails, it calls the 

void assert_failed(uint8_t* file, uint32_t line)

in which I had inserted a printf, which in turn in debug mode outputs some debug data in IAR's I/O window.Without the debugee to redirect the printf, the assert hang and had the afforementioned results.It's also interesting that the mentioned parameter always fails the assertion, even if I have disabled the dicontinuous conversions. I guess I should have double checked the machine generated code from CubeMX (which makes this post more CubeMX related than MCU).