STM32L100 - DFU bootloader from HSI & missing errata pdf

[pa2]

Posted on January 31, 2014 at 16:56

I'm planning to use some of new STM32L100 most probably in one of RB or R6 version mcu in upcoming project.

1) Does anybody know, when will ST release errata notes to those versions (there is only errata pdf for RC version - is it supposed to be same for others as well). 2) Regarding errata I already ported the project from STM32L151RBT6 to STM32L100RBT6 and everything is working all right, but from RC errata sheet I'm afraid about RCC peripheral limitation where some delay should be inserted after enabling peripheral, but the code seems to work even without this modifications, does anybody now, If I can just ignore this errata or should I implement workaround even if the code is working? 3) Most important for me. In application I'm planning to use very precise 26MHz TCXO oscillator and I need to use USB DFU bootloader. From datasheet, it seems, that I can't use internal HSI oscillator for driving USB, but from clock configuration utility I understand, that I can't use external 26MHz neither. Does anybody have some idea, how to solve this, or am I wrong with these assumptions? thank you a lot for any advice

[os_kopernika]

Posted on January 31, 2014 at 22:53

Ad.3.

You want to use a TXCO 26MHz to clock the uC but you need an 96MHz clock for USB.

1. Divide 26MHz externally to get 2MHz output / buy adequate oscillator. Then use PLL.
2. use 26MHz to clock uC and feed HSI*6 to USB. With reference clock you can tune HSI a bit (not tested but seems doable for volume > 1k).
3. Connect both crystal and TXCO+fet to OSC pins. If fet is off the crystal swings. If fet is on, crystal won't disturb low impedance TXCO drive. This is either or. Not both.

[pa2]

Posted on February 03, 2014 at 13:38 Thank you for your ideas! 1) I like this solution, only doubts I have are about how the TCXO precision would be affected, if I externally divide 26MHz to 2Mhz and then with PPL I multiply it back to around 24 up to 32 MHz for application purpose? Will I ''destroy'' 0.5ppm frequency stability? I guess no, but am not sure about this... 2) This sound nice as well, here I'm not sure if after the HSI trimming, HSI precision will guarantee the USB functionality. 3) Yes, this one we could implement as well, but I would like to keep low number of components... anyway, thank you again for your response!