STM32F334 bootup issue with HSI oscillator.

[Manu Abraham]

Posted on January 29, 2017 at 19:09

Hi,

On a STM32F334 breakout board which is derived off the discovery board,

attached schematics and crystal side board layout and test code.

I am having troubles getting it running.

Programmed the F334 breakout board with the F407 discovery board's onboard STLINK.

I can successfully erase and download to the target F334 flash without problems.

Debugging the unexpected outcome, the thought of an oscillator startup problem with the HSE,

made me look at the HSI oscillator.

But with HSI also, the test code to blink a LED fails. I was of the thought that the HSI should

not fail unlike HSI

Any ideas how to proceed further in debugging the issue ?

Thanks.

#stm32f334-bootup-with-hsi-oscillator

[Tesla DeLorean]

Posted on January 29, 2017 at 20:30

The part will not even start if the HSI is non-functional.

Have SystemInit() do nothing, the system will continue running with the HSI it started with.

Add code close to ResetHander? Turn off 'run to main()' and step the code.

When attaching files, ZIP up an archive of all the files you want to attach, and then just attach one file.

[Manu Abraham]

Posted on January 29, 2017 at 21:44

Hi,

Sorry, I am new to this forum.

Changed SystemInit() to do nothing, moved the code from system_stm32f30x.c to Test.c to keep things simple.

I couldn't follow '

Add code close to ResetHander?'

Turned off run to main() and stepped the code. The debugger got stuck trying to enter main,

I guess it was stuck in the reset handler ? it says type void f()

Something, I am missing here ?

Attached images of the debug session and the code.

________________

Attachments :

F334_Debug.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyy6&d=%2Fa%2F0X0000000bEZ%2FwvCClicUuGmIwShrDsBS8q6Al3nholoNhqAZvsRNTyw&asPdf=false

[Tesla DeLorean]

Posted on January 29, 2017 at 22:51

It means if I was really lost I'd add assembler code into the Reset_Handler to bring up LEDs and USARTs. The CPU however does appear to be functional, and clocking from the HSI.

The __main function is Keil's static initialization routine, it subsequently calls your main() function.

If __main is failing it suggests you have the memory map set up incorrectly, and it is having a problem using the SRAM.

If you Stop execution in the debugger where does it stop? In the Hard Fault Handler?

I would recommend you start by using the standard system_stm32f3xx.c and startup_stm32f3xx.s files, moving the code and breaking SystemInit() doesn't seem like a good plan.

At a minimum you want SystemInit() to enable the FPU, and set the vector table address into the SCB->VTOR register.

void SystemInit(void)

{

  /* FPU settings ------------------------------------------------------------*/

  ♯ if (__FPU_PRESENT == 1) && (__FPU_USED == 1)

    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */

  ♯ endif

  /* Configure the Vector Table location add offset address ------------------*/

♯ ifdef VECT_TAB_SRAM

  SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */

♯ else

  SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */

♯ endif

}

[Nemui Trinomius]

Posted on January 30, 2017 at 03:37

I think it should not route any signal under clock/X'tal line.

It disturbs X'tal oscillation stability.

For more detail,see Oscillator design guide.

http://www.st.com/resource/ja/application_note/cd00221665.pdf

[Manu Abraham]

Posted on January 30, 2017 at 11:19

Thanks for pointing it out. I must pay a bit more closer attention, while doing the PCB. It's a pain to move around the traces from the PORT P4. Fortunately, the HSI seems to be working now. It appeared to be an issue with the code that the device was not working with the HSI Internal oscillator.