Incorrect address of TIM1 in STM32NUCLEOF302R8

[deepakelango05]

Recently while using the TIM1 feature in NUCLEOF302R8(DOCUMENT NUMBER:DS9896), I've found that the address was wrong in the datasheet but the address of TIM1 in SFR is correct when I tried the address in SFR's It worked.

 

I'll list the findings that I've found while comparing the SFR's and features of the NUCLEOF302R8.

 

CORRECT:

1. The address of the available peripherals in NUCLEOF302R8 are correctly mentioned in SFR.

 

INCORRECT:

• The number of timers in NUCLEOF302R8 is 5 but in SFR's window there are nearly 10 timers.
• The number of SPI is 2 but in SFR's window there are 4 UART's.
• Similarly, there are many deviations between the peripherals of NUCLEOF302R8 and SFR's.

 

     

 

 

[Sarra.S]

Hello @deepakelango05 and welcome to ST Community

 

The address of TIM1_CR1 of the SFR is indeed in the interval mentioned in the datasheet (0x40012C00 is indeed below the boundary 0x40012FFF)

>> The number of timers in NUCLEOF302R8 is 5 but in SFR's window there are nearly 10 timers.

Actually there are 9 timers ; one 32bit timer, one 16bit advanced timer, three 16bit timers with IC/OC/OCN or PWM, deadtime gen, one 16-bit basic timer, 2 watchdog timers and the systick timer.

>> The number of SPI is 2 but in SFR's window there are 4 UART's.

I am not sure I get the point here, there are 2 SPIs and 3 UARTs

>>Similarly, there are many deviations between the peripherals of NUCLEOF302R8 and SFR's

If there is a mismatch between ST documentation and registers in SFRs it is more likely that the registers in SFR are the faulty ones 

[Tesla DeLorean]

I think the complaint here is the sloppiness of some of the documentation, and that it shouldn't be customers pointing out internal inconsistencies with data sheets and register files.

The TIM1 peripheral decode should be 1K wide between 0x40012C00..12FFF

If there is a void space between EXTI and TIM1 that should be a Reserved space, or the shadowing/replication of other registers. The hole would likely be due to spaces for peripherals that are implemented in other richer die from the F3 families. Say F373xC or F378xX with an ADC1 but no TIM1 ?

There's also perhaps frustration at understanding what peripherals exist in what die, and can escape from what physical packages. CubeMX / CubeIDE can help with that, but they in turn are dependent on the driving data files and register list to be correct.

 

[deepakelango05]

@Sarra.S  and @Tesla DeLorean  Thanks for your Support