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

[Nicholas Yunker]

Posted on July 06, 2017 at 14:16

Does the crystal you are using have the same Load Capacitance as the crystal used on the Nucleo board?  If not, you will have to change the value of the load capacitors you are hanging off the crystal inputs.  There are app notes written by ST on how to calculate these values based on the crystal you choose.

[aksulumdeniz]

Posted on July 06, 2017 at 14:55

We are using the load capacitance values given in the datasheet of the crystal we are using. We have successfully soldered the same crystal (with the same load capacitances) to the NUCLEO board, and it worked OK.

Also, even when we only activate the internal oscillator, the MCU does not work. I doubt that it has anything to do with the crystal.

Thanks

[waclawek.jan]

Posted on July 06, 2017 at 15:13

aksulu.mehmet_deniz wrote:

Also, even when we only activate the internal oscillator, the MCU does not work.

How do you know that 'MCU does not work'?

What do you expect it to do and what does it do?

Did you burn some code into it? How?

Did you measure voltage levels on pins Clive mentioned above?:

BOOTx pins?

Voltages at VCAP pins?

State of NRST?

Are all VCC and GND pins connected properly (including the analog VCC/GND)?

JW

[aksulumdeniz]

Posted on July 06, 2017 at 15:37

Hi,

I can load the code into the MCU but I cannot, for example, clock signal output from MCO1 and MCO2. Also I have tried to just turn on an LED.

The same code works fine with NUCLEO.

All of the VCC and GND connections are OK (including analog VCC and GND).

NRST is at 3.3 V (high).

The VCAP's are at about 1.35 V.

BOOT0 pin is pulled down to GND. There is no BOOT1 for STM32F746ZGT6.

[Tesla DeLorean]

Posted on July 06, 2017 at 16:38

>>

The same code works fine with NUCLEO.

Ok, so you're going to want to focus on how your hardware design is different. The NUCLEO/DISCO boards typically push an 8 MHz clock from the ST-LINK.

Use a debugger, turn off 'run to main()' options, and step the code from the Reset Handler on in. If I were super desperate, I'd code an assembler routine to configure and toggle a GPIO, and have that run as the first code executed.

If you were entirely dead in the water the SWD download would fail.

[Andrei Chichak]

Posted on July 06, 2017 at 17:50

Check all of the solder joints to the processor. Check your power supplies and grounds at the processor pins. Your processor could also be blown.

Andrei

[Steve Krattiger]

Posted on July 06, 2017 at 18:59

I agree with Clive.   If you can program the part, then the CPU is probably functioning OK.

With the ST-Link/V2 hooked up, go into debugger mode and hit run, then stop.   You'll probably find that you're hung up in an Error_handler, or an Assert_handler, or Watchdog is rebooting you before the external clock gets initialized.

Single-step through the code find out what's happening.

SteveK

[Tesla DeLorean]

Posted on July 06, 2017 at 19:51

But right now it is far more probable it is stuck in a while() loop, or faulting, something a bit of debugging would expose very quickly.

[AvaTar]

Posted on July 07, 2017 at 08:34

I agree - break at the reset vector, and single-step.

Most probable candidates are improper clock initialization, incorrect Flash timing, and (for the M7) cache initialization.

[aksulumdeniz]

Posted on July 07, 2017 at 10:58

Dear all,

I have managed to debug the code. The code gets stuck at this place:

I did not enable the WWDG.

Do you know how to solve this?

All the best,

Mehmet Deniz Aksulu