Wrong interpretation of shadow register?

[Kristof Mulier]

Posted on January 23, 2017 at 19:26

I believe that the STMicro reference manual on the STM32F7xx microcontrollers handles a wrong interpretation of the term shadow register.

I've posted a question on StackOverflow with more information:

http://stackoverflow.com/questions/41812800/does-stmicro-wrongly-interpret-the-term-shadow-register

http://stackoverflow.com/questions/41812800/does-stmicro-wrongly-interpret-the-term-shadow-register

#stm32f7 #shadow-register

[Tesla DeLorean]

Posted on January 23, 2017 at 20:31

I think you try of interpret it in an overly rigid sense. The 'shadow' here is a register you can't see, but is used by the hardware to limit the period of the counter, when it gets to the update point for the shadow, the active/visible register you are messing with gets loaded into the internal/shadow register.

The purpose here is that you don't cause the timer to change at some random point in the cycle. The timer doesn't have to be clocking anywhere near as fast as the bus (observe prescaler, which you can't see the counter for). It also stops you causing a race condition, you have near 100% of the cycle to change the period for the next cycle, so some slight latency in handling the Update IRQ doesn't result in unpredictable behaviour. If the cycle is ridiculously short consider using DMA triggered by the Update Event.

[Kristof Mulier]

Posted on February 02, 2017 at 11:13

Thank you

Turvey.Clive.002

‌

The answer I got on StackOverflow is also interesting:

'The problem is that the term 'shadow register' does not have a specific and architecture-independent meaning. ... In general, the term is used to refer to multiple hardware resources that you can address the same way. Which one of them is the 'real' register and which is the 'shadow' register is not consistent across architectures and vendors'

[waclawek.jan]

Posted on February 02, 2017 at 19:17

Kristof Mulier, quoting from stackoverflow:

'The problem is that the term 'shadow register' does not have a specific and architecture-independent meaning.

Sure, but that can be said of much of, if not the majority of the terms used in mcu-related electronics and programming. Add 'localization' issues wherever applicable (Kristof surely knows and experiences this facet of the problem too).

Nonetheless, I personally understand 'shadow register' more as 'auxilliary rather than the main working', and it confused me at my initial reading of TIM chapter, too. I also agree that the depiction of shadows in the overall TIM scheme suggests that those are the interfacing-only NOT the working registers. Note also, that the registers' description of TIM chapters avoids the 'shadow register' denomination (it's used only once, but not directly in a 'shadowed' register description. For example, 'ARR is the value to be loaded in the actual auto-reload register.', or 'PSC contains the value to be loaded in the active prescaler register...' or 'CCR1 is the value to be loaded in the actual capture/compare 1 register (preload value).'

Note also, that there are various schemes of 'working/interfacing', 'user-visible/transparent' registers used throughout the various peripherals, often with inadequate description. The DMA in 'F4/F2/F7 are notorious to use mixed approach (address registers are purely interfacing, never-to-be-read-back-from-working; contrary, NDTR exposes the working register but that has an invisible backup refreshed only when written from the bus and sourcing the working on autoreload in circular), causing much confusion, especially since they are poorly described.

And this also concludes my comment: the whole TIM chapter(s) is (are) rather messy, so clearing up a single confusing thing doesn't really help overall...

JW