RM0367 (STM32L0x3) discrepancies

[waclawek.jan]

Posted on January 10, 2017 at 06:53

&sharp1

RM0367 Rev.5, Ch. 6.1.6  Dynamic voltage scaling configuration requires to

Poll VOSF bit of in PWR_CSR. ait until it is reset to 0.

twice. The note at the end of the same chapter says,

During voltage scaling configuration, the system clock is stopped until the regulator is

stabilized (VOSF=0).

Now how could (and why should) the processor poll for VOSF if it's effectively stopped?

JW

#wtf

[waclawek.jan]

Posted on January 10, 2017 at 07:01

#2

The description of the VOSF bit in 6.4.2  PWR power control/status register (PWR_CSR) says:

This bit is reset when VOS[1:0] in PWR_CR register change.

It is set once the regulator is ready.

and just below these lines:

0: Regulator is ready in the selected voltage range

1: Regulator voltage output is changing to the required VOS level.

So is it reset (which IMO means zeroed) after VOS changes, or set to 1?

JW

[Igor Cesko]

Posted on January 10, 2017 at 13:54

This is mistake in Reference manual. Correct is:

This bit is set when VOS[1:0] in PWR_CR register change.

It is reset once the regulator is ready.

So practically is VOSF read always as zero.

[Andrew Sund]

Posted on November 02, 2017 at 18:07

I have a weird crash when executing this line of code in the standard ST startup code while debugging that seems related to being executed from flash or the alignment of the instructions. Without getting too into that as I have a couple threads to track down, I would like to rule out one of those threads...

Is it possible that the debugger is doing something unsafe within the system while the processor clock is paused during this time? Unfortunately I'm not very knowledgeable about the debugging features other than loading an image and stepping through some breakpoints, but of course it has access to the processor and system bus. When I say 'unsafe', I mean doing something that would be considered synchronized during normal processor execution, but when it's paused while the oscillator stabilizes, assumptions about the processor don't hold? I guess my analogy would be along the lines of concurrency problems with shared memory, as I'm more on the firmware side than hardware...

Also, could it be possible for the debugger to be interacting with unstable flash memory while execution is paused and acting on it erroneously?

[waclawek.jan]

Posted on January 10, 2017 at 07:11

#3

In 7.3.1  Clock control register (RCC_CR), Bit 2 HSI16RDYF description says:

 This bit is set to ‘1’ only if the HSI 16 MHz oscillator is enabled by HSI16KERON or by IP request.

I have set RCC_CR.HSI16ON which IMO is not any of 'enabled by HSI16KERON or by IP request' and then RCC_CR.HSI16RDYF read as 1.

Why?

[Igor Cesko]

Posted on January 10, 2017 at 15:08

This is mistake in Reference manual. It should be written in a more clear way.

Correct description is in the Chapter '7.2.2 HSI16 clock':

The HSI16RDY flag in the RCC_CR register indicates whether the HSI16 oscillator is stable

or not. At startup, the HSI16 RC output clock is not released until this bit is set by hardware.

[waclawek.jan]

Posted on January 10, 2017 at 07:14

#4

In 7.3.1  Clock control register (RCC_CR), Bit 2 HSI16RDYF description, please specify what exactly means  or by IP request (list related IPs which can request HSI16ON, and/or link to related chapters where such request is described).

[Igor Cesko]

Posted on January 11, 2017 at 17:08

The IPs are those IPs which can be set for clock source from HSI16: see RCC_CCIPR register description in Chapter: '7.3.20  Clock configuration register (RCC_CCIPR)' . There are peripherals which can be clocked from HSI16 (and can wakeup device from Stop mode):

LPTIM

I2C1, I2C3

LPUART

USART1, USART2

[waclawek.jan]

Posted on January 10, 2017 at 07:19

#5

In 7.3.1  Clock control register (RCC_CR), Bit 1 HSI16KERON description says:

High-speed internal clock enable bit for some IP kernels

but the text below appears to indicate that if RCC_CR.HSI16KERON is set, HSI16 stays on in STOP mode unconditionally, i.e. regardless of any IP being on or not. If this is really the case, I would remove any mentions of 'IP kernels' to avoid confusion.

[Igor Cesko]

Posted on January 11, 2017 at 17:12

This is just the short name of the bit. The HSI16KERON description is deeply explaining its functionality (HSI16KERON always active in Stop mode).

We modify this bit description to be more clear.

[waclawek.jan]

Posted on January 10, 2017 at 07:46

#6

In A.8.1 Calibration code example, ADC_CR.ADEN is checked prior calibration and if on, it is attempted to be switched off by clearing it. But according to the RM, it can't be cleared directly and ADC_CR.ADDIS has to be used for this purpose.

This is similar to what is in

https://community.st.com/0D50X00009XkaBBSAZ

.

I did not check the L0Snippets.

[Igor Cesko]

Posted on January 11, 2017 at 18:02

Yes - this is mistake in the example - it will be corrected.

[waclawek.jan]

Posted on January 16, 2017 at 10:39

Hi Igor,

Thanks for the replies and explanations.

If your time permits, can you please comment also on the remaining two questions ( ♯ 7 and ♯ 8)?

Thanks again,

Jan

[waclawek.jan]

Posted on January 10, 2017 at 08:18

#7

In 14.4.5  Configuring the ADC, first, proper treatment of ADCAL, ADEN, ADSTART and ADDIS bits in ADC_CR is described, then this section follows:

For all the other control bits in the ADC_IER, ADC_CFGRi, ADC_SMPR, ADC_TR,

ADC_CHSELR and ADC_CCR registers, software must only write to the configuration

control bits if the ADC is enabled (ADEN = 1) and if there is no conversion ongoing

(ADSTART = 0).

However, for several items in the registers' description (e.g. ADC_CFGR1.RES, ADC_CFGR2.CKMODE, ADC_CCR.PRESC) it is explicitly prescribed that they must not be changed unless ADEN = 0 (and possibly other conditions apply). In fact, in the registers' description the only item requiring ADEN = 1 is ADC_CALFACT.

Please clarify.

[Igor Cesko]

Posted on February 09, 2017 at 15:02

This ia a mistake in documentation - the 'incorrect' sentence will be corrected.

[waclawek.jan]

Posted on January 10, 2017 at 08:41

#8

 

I suggest to add a comment after Calibration software procedure in 14.4.2  Calibration (ADCAL), explaining that ADCAL can remain to be set for some time even after EOCAL has been set, and that that may prevent subsequent setting of ADEN (or other related 'trigger' bits).

JW

[Igor Cesko]

Posted on February 09, 2017 at 15:42

This note will be added to documentation - it is useful. Thanks.

[waclawek.jan]

Posted on February 09, 2017 at 15:44

Igor,

Thanks for your time and patience ;)

Jan

PS: Any chance meeting you at some of the hw-list gatherings in Bratislava? I owe you a beer or any other beverage of your choice...

[Andrew Neil]

Posted on December 01, 2017 at 18:16

Another discrepancy: 

https://community.st.com/0D50X00009XkbSBSAZ

  ?

[waclawek.jan]

Posted on March 04, 2018 at 19:51

There is a note in Auto-off mode (AUTOFF) chapter saying

Please refer to the Section Reset and clock control (RCC) for the description of how to

manage the dedicated 14 MHz internal oscillator. The ADC interface can automatically

switch ON/OFF the 14 MHz internal oscillator to save power.

This is obviously a copy/paste error, there is no 14MHz internal oscillator in the 'L0x. This text can be found in RM0091 for 'F0x though, where it's valid.

However, it may well be that this *is* valid for HSI16 in the L0x. Unfortunately, there is no mention of HSI16 being controlled by ADC, not in ADC chapter nor in RCC chapter.

(Whatever the truth is, I here again repeat my request for better Interconnections chapter in the RMs).

Not spotted by me - this appeared in a

https://list.hw.cz/pipermail/hw-list/2018-March/506740.html

, in the parallel RM for the 'L0x2 - obviously all related RMs are affected.

JW