STM32F746ZGT6 problem with custom board [urgent]

[aksulumdeniz]

Posted on July 04, 2017 at 21:00

Dear all,

   We have been developing a custom board featuring STM32F746ZGT6, and we have encountered some problems.

   We are able to program the MCU using the ST-link with no problems, however, the MCU does not do anything! The PCB design was exactly based on the NUCLEO-STM32F746ZG board. We could not spot any differences between the NUCLEO board and our custom designed board (for the essential MCU components).  

   At first, we thought that it was a software problem so we tried the same software with the NUCLEO board and it worked fine. All the clock sources etc. are identical in both the NUCLEO and our custom board. Therefore we suspect that there is a problem with the hardware. It could perhaps be due to EMI?

   We have double checked all the connections and soldering.

   We are in a desperate situation. Do you have any ideas what could be the source of such a problem? 

All help would be appreciated. Please let me know if you need any more information.

All the best,

Mehmet Deniz Aksulu

#stm32f7 #no-response-from-the-target #custom-board

[Tesla DeLorean]

Posted on July 07, 2017 at 11:22

Probably also the address for the Default_Handler, check .MAP file.

What's the last thing you step through before you reach this point? Double check the IRQHandlers are linking properly, ie no C++ name mangling, and that you have handlers for everything being enabled.

[AvaTar]

Posted on July 07, 2017 at 11:38

You could also check that you have the correct startup file for your MCU variant, which uses to include the vector table.

[aksulumdeniz]

Posted on July 07, 2017 at 12:27

After defining the HardFault callback, I have noticed that the MCU is actually stuck in HardFault IRQ.

What could be the cause? The same code works fine on NUCLEO board.

[Tesla DeLorean]

Posted on July 07, 2017 at 13:27

Quit focusing on it being the same code unless you're going to critically analyze what you've done differently at a hardware level.

Step the code or have the Hard Fault Handler describe the exact point at which it fails. 

Look critically at the clock sources and PLL settings.

Allow the part to keep running on the HSI,  output other clocks to the MCO pin and scope them.

[Tesla DeLorean]

Posted on July 07, 2017 at 14:15