Switching MSI to HSI on STM32L1

[JFELI.13]

Hi,

I have a problem: in my soft, initial setup is for MSI mode (this because, in "stop mode" it will return in this mode) but I want to choose STM32L1 mode, in MSI mode (2.097Mhz) or in HSI (16Mhz) mode

When I select HSI mode (after initial MSI setup) everything seem ok (timer 100ms is accurate) ... except when I'm using a delay function: delay become very short ( perhaps 1/3)

I did a register comparison (RCC_CR, RCC_CFGR, RCC_APB1RSTR,RCC_APB1ENR...) between initial HSI or MSI setup but I can't see the problem.

Any suggestion ?

Thanks for help

void STM32L151_HSI()

{

  unsigned int TimeOut=0xFFFF;

   

  RCC_CR.HSION=1;

  while(!RCC_CR.HSIRDY && TimeOut--);

  RCC_CFGR.SW0=1;

  while(!RCC_CFGR.SWS0);

  RCC_CR.MSION=0;

   

}

[TDK]

Okay... what is your delay function?

Why have a TimeOut here? You want to wait until HSIRDY is high, so just do that.

[JFELI.13]

Hi

Thanks for your answer, timeout was just a security, no really need.

I use mikroc sofware

delay function is like that :

delay_ms(1000); // for 1 second

I'm not sure I'm clear:

1) if I initialise set up before programming (so , if MSI or HSI mode) both modes works correctly (timer is accurate and delay_ms too)

2) if I initialise setup with MSI mode and, immediatly after IO setup, I change the mode using STM32L151_HSI to get HSI mode, timer is always accurate BUT delay_ms not

[JFELI.13]

My purpose is to get soft in stop mode after GPS position (this give a MSI wakeup mode) and so, a few minutes after when waked, return to HSI mode.

Everything works except I noticed "delay_ms" became very short.

[TDK]

Post the delay_ms code. It's not a standard function so without knowing what it's doing, it is difficult to add info. Most likely it is caching the clock value somewhere and waiting a certain amount of ticks. When the clock changes, that value also needs to update. If not, the number if ticks is no longer correct for the specified delay and the delay is shorter/longer than intended.

> timeout was just a security, no really need.

Security to ensure that if a bug occurs here, it will be hard to track down?

[JFELI.13]

I'm also pretty sure this is a bug in the soft

I did a "Delaixxx" call and read the ASM file for this (V301 is the name of main), here is it

_Delaixxx:

;V301.c,2032 :: void Delaixxx()

;V301.c,2034 :: delay_ms(100);

MOVW R7, #9043

MOVT R7, #8

NOP

NOP

L_Delaixxx1538:

SUBS R7, R7, #1

BNE L_Delaixxx1538

[JFELI.13]

Sorry, here I'm work with HSI mode preset so delay are OK

Now I will do the same in MSI mode preset ans, after in MSI preset followed by HSI change

[JFELI.13]

HSI mode preset (16Mhz)

_Delaixxx:

;V301.c,2032 :: void Delaixxx()

;V301.c,2034 :: delay_ms(100);

MOVW R7, #9043

MOVT R7, #8

NOP

NOP

L_Delaixxx1538:

SUBS R7, R7, #1

BNE L_Delaixxx1538

NOP

NOP

NOP

NOP

;V301.c,2035 :: }

L_end_Delaixxx:

BX LR

; end of _Delaixxx

MSI mode preset

_Delaixxx:

;V301.c,2032 :: void Delaixxx()

;V301.c,2034 :: delay_ms(100);

MOVW R7, #4362

MOVT R7, #1

NOP

NOP

L_Delaixxx1538:

SUBS R7, R7, #1

BNE L_Delaixxx1538

NOP

NOP

NOP

;V301.c,2035 :: }

L_end_Delaixxx:

BX LR

; end of _Delaixxx

MSI mode folowwed by HSI function STM32L151_HSI()

_Delaixxx:

;V301.c,2032 :: void Delaixxx()

;V301.c,2034 :: delay_ms(100);

MOVW R7, #4362

MOVT R7, #1

NOP

NOP

L_Delaixxx1538:

SUBS R7, R7, #1

BNE L_Delaixxx1538

NOP

NOP

NOP

;V301.c,2035 :: }

L_end_Delaixxx:

[JFELI.13]

It appear delay_ms function is not updated when clock change. Is it the problem ?

[JFELI.13]

Notice:

on MSI mode folowwed by HSI function I did a main modification so delay is after HSI function

  //Delaixxx();

   

  IO_Set();

  #ifndef FreqMSI

  STM32L151_HSI();

  #endif

   

  Delaixxx();

[TDK]

> It appear delay_ms function is not updated when clock change. Is it the problem ?

Sure seems like that would be a problem to me.

I would also use a delay function based on systick or other fixed timer interval rather than one that requires the CPU to be utilized 100% for the duration. With the latter, interrupts during the delay will cause the delay to be longer than intended.