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.

 

[Uwe Bonnes]

I see few if any pull resistors on the other pins related to bootloader entry. Maybe some floating pin is toggling and some other bootloader mode is entered.

[bymrz]

Hi Dear Bonnes. I've double checked the bootloader relative pins. And I pulled high CAN2 Rx pins already to be ensure.

But I've noticed today that the MCU does enter DFU mode when the temperature is low. If I heat the MCU by using hot air, it doesn't enter DFU and UART bootloader. 

I had doupts about external crystal. Bu I read the document and it says the MCU use internal OSC when it doesn't detect USB cable and enter into uart bootloader. 

Even if I try to enter UART bootloader, the mcu doesn't reply to 0x7F when the ambient temperature is high. After a while and make the mcu cool, it can enters into DFU and UART bootloader...

[Uwe Bonnes]

Maybe the crystal has sloppy tolerances and only is inside the USB spec with low board temeratures? Does the crystal oscillate at all or does it start up very slow? Are the 10 pF load for the crystal what is calculated  or is that some standard value you use(AN2867)? Cold solder joints? Some supply voltage at an exteme end?

[STOne-32]

Dear @bymrz @Ugnas @Uwe Bonnes ,

 

This behavior is mainly due to a wrong Bootloader detection of the external crystal frequency for exemple detection =24Mhz where it is 25MHz and so baudrate of UART and USB using asynchronous clocking will be faulty.  This behavior is described here 

https://www.st.com/resource/en/application_note/dm00425536-how-to-optimize-stm32-mcus-internal-rc-oscillator-accuracy-stmicroelectronics.pdf

 

to confirm this hypothesis, please try a crystal of 8MHz or 4MHz and let us know .

Hope it helps .

STOne-32

[Ugnas]

Sorry, I forgot to mention that I am using 8 Mhz crystal with internal load capacitors (P/N: CSTCE8M00G52-R0 ). I tried to re-solder crystal from working boards and switch them hoping that it will help, but the result is the same.

Is there any more ways to confirm that?

 

[BarryWhit]

@bymrz, you seem to be producing a commercial quantity of boards and can perhaps put some engineering towards resolving this issue for others as well.

1. Are you able to put together a small program that measures the HSI frequency of your "good" and "bad boards"?

AN4067 describes how to do it, See for example STSW-STM32132  for a code library which does this for the STM32F0x. (or STSW-STM32076 for L1, or STSW-STM32021 For F10x).

2. Can you confirm that your "good" and "bad" boards can be distinguished by the result of this test?

3. Can you resolve the issue by adjusting the calibration values (as described in AN5067, which STOne-32 suggested)?

[Ugnas]

Thank you for the time providing all the information.
I noticed that all the documentation is provided for different family STMs. Is procedure the same for F4 family? Can the same timer (TIM14) be used to connect directly to the HSI?

[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: