STM32f446 Usb Dfu Bootloader Problem at High Temperature

[bymrz]

Hello,

Thank you in advance for your assistance.

I have designed a circuit with STM32F446. I am using an external 25MHz crystal. The main application program runs fine without any issues, and USB communication works. However, on some boards, I am unable to put the processor into USB DFU mode. I have several boards, and most of them enter DFU mode correctly. I am controlling the Reset and Boot pins externally with another microcontroller. I am monitoring the NRST and BOOT0 pins with an oscilloscope, and there seems to be no problem.

I have also tried using a 10MHz crystal with 20pF capacitors, but still couldn't get the processor into DFU mode. I even tried the UART bootloader method by disconnecting the USB cable, but I still fail to get a response from the processor to the 0x7F command.

As mentioned earlier, DFU mode works perfectly fine on many other boards. However, despite checking everything, I am unable to put the processor into DFU boot mode on some boards.

[BarryWhit]

The calibration procedure seems to be the same, but there will be some porting effort involved. I can't give you any family-specific information, except to suggest you read the appnote and see. You can also try to bruteforce your way through adjusting the calibration values and see if it gets you anywhere. That will probably be tedious.

[BarryWhit]

You can also use RCC/Master Clock Output to route HSI16 out to a pin (very easy with CubeMX) and observe with a 'Scope. It may not be as sensitive as the calibration procedure above, but could probably be up and running in a few minutes, best if used for comparing several good vs. bad boards. You need at least a few data points.

[Ugnas]

I did like you said. Routed MCO to pin. Measured 4 working and 2 not working boards:
Working:

16.04 Mhz
15.98 Mhz
15.96 Mhz
16.00 Mhz

Not working:

15.92 Mhz
16.02 Mhz

I have played around with HSITRIM:

  uint16_t CalVal = 16; // middle
  RCC->CR |= (uint32_t)CalVal << 3;

1. I managed to move clock of the first bad board (15.92 Mhz) to 16.01 Mhz and 16.08 Mhz, but DFU from button still does not work.
2. I noticed that I am not able to reduce clock. CalVal = 15. gives me 16.9 Mhz (when CalVal = 16 is 16.02 Mhz).
3. I moved clock up on working boards up to 16.4 Mhz and they were still working.
4. I heated not working board a bit (second one: 16.02 Mhz) - the DFU started working. Then I measured MCO - 16.14 Mhz. The board cooled down. I increased HSTRIM to 16.14 Mhz. DFU - not working.

I am going to play around a bit more with calibration but it looks for me that is is not the problem of HSI...

[BarryWhit]

Good info, thanks.

How did you measure frequency? do you have a fancy DPO, can you measure jitter with any accuracy? unfortunately, with the extra circuity in the way, it's hard to know if this informative or not.

> I noticed that I am not able to reduce clock. 

according to the docs, the calib value should produce monotonic results, there might be someone wrong with your test.

>  but it looks for me that is is not the problem of HSI...

right, since the good/bad seem to overlap, but there's not enough data to be sure. Still, could be the case that this HSI16 error is the issue for bymrz , while you have another. 

Since you say you can reliably get DFU working/non-working with heat, do you have the means to localize temperature differences (aluminium tape/heat shielding, a heat sink, a thermal pad, freeze spray), to try and identify which part in particular is showing the relevant heat-dependent behaviour? is it the STM32 or your crystal?

Do you have a alternative source of crystals (different freq, make, distributor)? Can you source some over-spec crystals and hand solder them with low-melt solder to see if this fixes the board? if it does, it may be the crystal.

I fuzzily recall that some crystals with integrated capacitors actually may still require external capacitors as well in the fine-print, have you been through the datasheet carefully? 

ST's AN2867 is dedicated to working with oscillators, have you gone over that? 

What happens if you swap the crystal for the 15.92 Mhz board with a good one? does one stop and one start working?

Did you check if the problem is with a bad solder joint on the DFU (nBOOT0 I assume you mean) button, rather than anything else?

These are all just shots in the dark. Take your pick.

[BarryWhit]

Hmmm. The difference between 16Mhz and 16.1Mhz period is only about 400ps. Can your test gear really handle that?  Did you use the clock divider available in front of the MCO output (I think it can do /16).

[Ugnas]

That's a good point. I am not very advanced with a hardware. I have a hobby oscilloscope 200 Mhz. It leaves me with 5 ns, so I cannot measure anything reliable here.

Now I have brute forced all possible HSTRIM values from 12 to 32. DFU have not started to work.

I have noticed one more "witchcraft": if I put the finger on the STM and push it firmly it starts entering DFU from the button. I pushed it with a plastic object too, but it did not enter DFU. It can be from the heat of the body, but it is very small difference to make clock actually drift?

I think I faced some meta-stability issues with routing maybe?

[Ugnas]

I found the issue...
It was BOOT1 pin left unconnected. I connected it directly to ground. DFU mode is stable now..

I hope topic author has same, easy issue like me and not all this calibration nightmare :beaming_face_with_smiling_eyes:

[STOne-32]

Hi @Ugnas  ,  Glad to see you solved the issue by connecting the BOOT1 pin .  

Ciao

STOne-32

[BarryWhit]

---

@Ugnas wrote:

I found the issue...
It was BOOT1 pin left unconnected. I connected it directly to ground. DFU mode is stable now..

This is instructive for anyone who brings up boards (or helps others do so, on the forum). Instead of going down a rabbit hole of subtle causes, it's often something very simple. 

I hope topic author has same, easy issue like me and not all this calibration nightmare :beaming_face_with_smiling_eyes:

---

actually, you may have pinpointed their issue as well. BOOT1/PB2 is cut off in the schematic image posted, but it looks like it is used as GPIO, and might not have been grounded. Unfortunately, the original poster seems to be MIA so we may never know. Nor will they, perhaps.