Misprint in F4/G4 Programming Manual (Bitband)

flyer31 · ‎2021-07-19

There is a misprint in your PM0214 Programming manual "The Cortex M4 processor" in the chapter chapter 2.2.5 "Bit-Banding", above figure 9. Bit-Banding is nicely described there, but of course all bit addresses have to end by "00"... Your first example address there says "0x23FFFFED" - but this is WRONG, this must please be corrected to "0x23FFFE0". (As your calc formula is correct, this error is quite evident to anybody looking deeper into this ... but anyway quite disturbing for many people I think...).

(in PM0214 Rev10 this is on page 33/262)

waclawek.jan · ‎2021-09-01

> Concerning your question at 2: I just used my "standard bit band macros",

Can you please prepare and post an absolutely minimal but complete compilable example exhibiting this behaviour? Perhaps just enabling a peripheral in given range, writing to its register using BB and then reading it back?

I don't have a 'G4, but I believe ST would be more willing to look at this if you prepare them a clean example.

JW

flyer31 · ‎2021-09-01

I just looked up in my current project to search for occurence my SetBitMskAtomic / ClrBitMskAtomic, and it is NOT used very often, only in my I2C module (but this in fact is my only module producing interrupts so far).

In this I2C interrupt module I use for two applications:

for some "internal status bit assembly of about 20 status bits" - but this is inside SRAM at some 0x20000000 address, so here no real question
for the TIMEOUTEN bit in TIMEOUTR register, so then this uses my bit macro above like

SetBitMskAtomic( I2C2->TIMEOUTR, I2C_TIMEOUTR_TIMEOUTEN);

My questions referred to the currently more "hypothetical" question, whether I could use this also for AHB2 peripheripherals, which are in the address range 0x48000000. But this is not COMPLETELY hypothetical, as all the AHB2 peripherals, though not many, are really quite important and basic: GPIOA...GPIOG, ADC1..ADC3, DAC1..DAC4. Until now I did not need here any atomic bit access in my interrupts, but if I need this, then this question would appear very easily of course.

It is quite a time now that I tested this (this post is quite old already...), but if I remember correctly, I tested e. g. the GPIO->ODR register, e. g. by

SetBitMskAtomic( GPIOA->ODR, GPIOA_ODR_O1);

... and then I was happy when I saw that this works... . (of course for this application it is hypothetical again, as here of course I would use the GPIOA->BSRR register and this does NOT need bit processing of course, but it was somehow most easy to test, and I was happy to see it working ... just it is outside the bit mask range specified in the the programming manual, so I just was curious whether this was some "accidential lucky event", or whether the programming manual could be updated such, that the AHB2 peripheral address range 0x48000000 ALSO is included into this bitband functionality... ).

flyer31 · ‎2021-09-02

This post of me is quite old now, so a bit difficult to remember :).

I just searched my current project for use of this macro SetBitMskAtomic. I find it only in my I2C module, but this is also the only module in my project where I use interrupts.

There I use it for two applications:

- setting about 20 status bits in some own-defined SRAM variable, but this covers only SRAM range 0x20000000 and here all clear... .

- Setting/Clearing the TIMEOUTEN bit in I2C2->TIMOEUTR register, e. g. by

SetBitMskAtomic( I2C->TIMEOUTR, I2C_TIMEOUTR_TIMEOUTEN);

This also should work without problems / well specified, as the TIMEOUTR register I think does NOT contain any bits under hardware control / no status bits, and it is in the "normal peripheral address block" 0x40000000.

Just when I did this macro, I was mixed up by the "valid peripheral address" spec in PM, which specifies 0x40000000...0x400FFFFF ... of course this is nice range, but AHB2 is in range 0x48000000. So my question was more "hypothetical" as I was wondering about this upper range... .

But it is not TOO hypothetical, this AHB2 peripheral range is small but contains really very important peripherals as GPIO, ADC, DAC. If I remember correctly I tried GPIOA->ODR with e. g.

SetBitMskAtomic( GPIOA->ODR, GPIO_ODR_OD1);

and then I was happy to this that it worked perfectly with my SetBitMskAtomic macro (specified above...) .

So my question is just, whether this was some "lucky day result" or whether bitband really SHOULD work also for this 0x48000000 address range by design... . (in this case it would nice if STM could please update the PM bitband chapter to include also this 0x48000000 address range as valid range for bitband...).

Currently this question is a bit hypothetical as I do not use interrupts for GPIO/ADC/DAC in my project. But as soon as I would use interrupts mainly for ADC or DAC, this of course could easily be important for me (though then mainly for very basic enable bits and not any "hardware conflict status bits" of course ... for GPIOx->ODR of the example above of course in my code I would use the recommended way with the GPIOx->BSRR register, which of course does NOT need bitband access then).

waclawek.jan · ‎2021-09-02

> Setting/Clearing the TIMEOUTEN bit in I2C2->TIMOEUTR register, e. g. by

> SetBitMskAtomic( I2C->TIMEOUTR, I2C_TIMEOUTR_TIMEOUTEN);

Can you please verify this works as expected? I.e. place a breakpoint before this statement, verify the bit is not set, execute the statement and verify the bit is set.

JW

flyer31 · ‎2021-09-02

Well, this OF COURSE works as expected (my complete project is running vey nicely - I2C is working perfectly nicely - if this would NOT work, I would recognize VERY immediately... it handles about 100 IC2 transfers per second in a full I2C multimaster environment).

Why do you think that this should NOT work?

(my question refers only to this other range 0x48000000... this I2C TIMEOUTR register is inside the "normal 0x4000000" 1MB block, where bitband works, and yes, of course I tested that it works, I clearly can confirm this).