Advantages of using HSE over HSI

[andre]

Posted on March 30, 2015 at 03:46

I'm developing a project in wich main clock accuracy isn't particurlaly important. I do need to measure time acurately, but I can use the RTC with an external 32.768 KHz crystal for that.

I was wondering about the possibility of using the internal HSI for this particular project, but I am a little concerned about what would be the disadvantages (specially since it seems everyone uses a crystal). Accurancy is an obvious one, but as I said, I'm not concerned about that. What about other disadvantages, are there any? In my particular case I'm interested in power consumption as well. Thanks in advcance, respectfully, Andrew. #hse-hsi-clock-crystal

[re.wolff9]

Posted on March 30, 2015 at 09:17

In a few projects I have put the crystal on the PCBs. However, the software projects that I copied to get started used HSI. I haven't bothered to switch... So.. Not everybody is using HSE. 

I haven't looked into power issues. But I'd guess that it is easier to optimize the HSI clock for power than the HSE: the latter has to work with ''unknown'' crystals. 

[gvigelet]

Posted on March 30, 2015 at 16:16

I am pretty sure using a crystal for either HSE or LSE will increase your power consumption slightly, and gain stability/accuracy since RC oscillators tend to change with temperature.   Also it would depend on peripherals that you are using, some peripherals need an accurate clock.  If you are not in need of the accuracy and want to lower the BOM cost, I would try using the internal oscillator.  

I also believe that all the internal clocks have a faster startup time than the external oscillator options.Thanks,George

[Tesla DeLorean]

Posted on March 30, 2015 at 16:55

For USART/SPI the HSI will be fine. For CAN/USB/Ethernet you want the accuracy afforded by the HSE. For Ethernet you could also go with a single 25 or 50 MHz oscillator for the entire design.

[childresss]

Posted on March 31, 2015 at 03:47

I have a lot of ST32F4xx boards. The one I'm using a lot now, when on the HSI clock yields a baud rate that's too much in error. Just jibberish on the dumb terminal.

[Tesla DeLorean]

Posted on March 31, 2015 at 05:12

And what does the HSI and PLL look like when scoped on MCO(1)? Or the bit timing on the serial data?

[childresss]

Posted on March 31, 2015 at 08:15 Good question ... I chose HSI and in the clock mux, HSI as well, not PLL. The code generator in CubeMX, for other clock freq. changes, recalculated the baud rate divisors. So I assume that for non-PLL, it would as well. But I didn't 'scope the bit times. I decided to use 48MHz off the PLL as the power conservation compromise. The problem I also had is that the startup code that initializes or zeros bss is much too slow at 16MHz, and there's no way I see to get it to run at PLL speeds as it runs well before the PLL is turned on. So the for-now work-around is to tell the linker to 'no initialize' the 50KB or so of RAM buffers. This all comes up due to the need to run app code just a few mSec after power up, and the bss init was taking 60+ mSec at 16MHz. (That 16MHz is for the startup code before the HSE/PLL or HSI/PLL  is enabled.) Lastly, for this embedded system, I didn't want to make a big heap and use malloc().

[re.wolff9]

Posted on November 02, 2015 at 18:13

Before executing the jump-to-application instruction the bootloader in several STM chips tries to reset the HSI calibration register to its reset value, and resets the register to ''all zeroes''.... Except... that's not the reset value. The reset value is 0b10000, halfway in the 5-bit range 0b00000 - 0b11111. (IIRC, that calibrates the HSI to about -8%)

So, that's the case when I've seen the ''all gibberish'' on UART when using HSI.... Are you using the bootloader? 

[Tesla DeLorean]

Posted on November 02, 2015 at 19:11

Most use cases don't have the System Loader (bootloader) touch the device at all. Pulling BOOT0 High and jumping to app code is highly atypical.

The biggest thing to watch for is code in/called-by SystemInit() nuking registers or making assumptions about the entry state. It's gotten better, but if you have a loader/app configuration, you need to be more conscious of the hand over conditions/expectations. If you already have the HSE/PLL functioning, there's no real point to tear-down everything and wait for them to start/lock all over again. Serial data can deal with woeful levels of bit timing error, but as baud rates increase wrt to APB clock, you're starting with a lot rougher granularity.

[re.wolff9]

Posted on November 03, 2015 at 09:33I like the flexibility of the STM chips. I also like ''quick test cycles''. So I edit my source and when I save it, an automatic compile is triggered. I would prefer getting a single-button load-and-start-the-code, but /I/ currently use the debugger to load and start the app. But on AVR I had a hardware boot-to-bootloader button. And why the *** would I have attached a chip in DFU mode when I'm not developing code? So I have a pointer to my ''current'' project and a script on my PC that loads the current application and starts it. So, that's a possible development cycle that would result in the bootloader running before starting the app.....So I mentioned the possibility of that messing with the baud rates. (I have observed the ''gibberish'' UART results with the -8% tuning of the internal clock). Since I have:   RCC->CR = (RCC->CR & ~RCC_CR_HSITRIM) |  RCC_CR_HSITRIM_4;in my source I haven't had any problems anymore... :)