Missing volatile qualifiers in MCU vendor header files?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Whilst trying to track down an obscure bug, I noticed that ST
header files do not specify volatile for peripheral registers.
In contrast ARM stuff (looking at CMSIS) is religious about volatile.

For example, in stm32f413xx.h there's lots of stuff like
#define TIM2_BASE (APB1PERIPH_BASE + 0x0000UL) // nice hex address
#define TIM2      ((TIM_TypeDef *) TIM2_BASE)  // TIM2-> used throughout

No volatile on the pointer declaration (nor structures wouldn't work for typedef?)

I checked some headers from Freescale/NXP (OK, a few years old), same thing.

Am I missing something, or is this omission completely nuts?
A lot of register access will be intolerant of 'optimization', right?
David B. ?

Thanks in advance,
Best Regards, Dave

Re: Missing volatile qualifiers in MCU vendor header files?
Dave Nadler schrieb:

Quoted text here. Click to load it

Have a look at the definition of the structure (i.e. TIM_TypeDef), where
all the variables have the attribute __IO which should make them volatile.

Tilmann

Re: Missing volatile qualifiers in MCU vendor header files?
On Monday, April 6, 2020 at 2:29:39 AM UTC-4, Tilmann Reh wrote:
Quoted text here. Click to load it

Thanks Tilman! I missed that, from core_cm4 in both these instances...

Re: Missing volatile qualifiers in MCU vendor header files?
On Monday, April 6, 2020 at 9:54:58 AM UTC-4, Dave Nadler wrote:
Quoted text here. Click to load it

PS: Really not where I expected! Better if ptr is volatile, not struct or fields.
Explained well by David Brown here:
https://embeddedgurus.com/barr-code/2012/11/how-to-combine-volatile-with-struct/

Re: Missing volatile qualifiers in MCU vendor header files?
On 06/04/2020 23:36, Dave Nadler wrote:
Quoted text here. Click to load it

Hey!  A cite!  I'm famous :-)

The most important part is to have the volatile /somewhere/.  An extra  
volatile in an access never makes a program incorrect, but a missing  
volatile in an access can make it subtly incorrect.  The "best" place  
depends on how much control you want, how explicit you want to be, how  
much you understand things like ordering between volatile accesses and  
non-volatile accesses (there isn't any), how much you want to fight for  
the last drops of efficiency, and of course how clear the code is.


Re: Missing volatile qualifiers in MCU vendor header files?
On Monday, April 6, 2020 at 6:09:56 PM UTC-4, David Brown wrote:
Quoted text here. Click to load it

We already knew that ;-)

Re: Missing volatile qualifiers in MCU vendor header files?
On 07/04/2020 00:18, Dave Nadler wrote:
Quoted text here. Click to load it

Yes - my name is on tractors around the world, the credits of "Jaws",  
and several dozen Wikipedia entries.  All my work :-)

More realistically, I have made comments about "volatile" in quite a few  
places over the years.



Re: Missing volatile qualifiers in MCU vendor header files?
On 4/7/2020 04:36, David Brown wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it
Remember that fame is volatile.

--  
Best wishes,
--Phil
We've slightly trimmed the long signature. Click to see the full one.
Re: Missing volatile qualifiers in MCU vendor header files?
On Tuesday, April 7, 2020 at 12:30:56 PM UTC-4, Phil Martel wrote:
Quoted text here. Click to load it

Very nice Phil!
We're breathlessly awaiting David Brown's definitive treatise on memory barriers...

Re: Missing volatile qualifiers in MCU vendor header files?
On 7.4.20 11:36, David Brown wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

And the 'DB' in Aston Martins.

--  

-TV


Re: Missing volatile qualifiers in MCU vendor header files?
On 4/7/2020 14:38, Tauno Voipio wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it
and the ubiquitous dB

--  
Best wishes,
--Phil
We've slightly trimmed the long signature. Click to see the full one.
Re: Missing volatile qualifiers in MCU vendor header files?
On 8.4.20 18:20, Phil Martel wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Aston Martins are built by David Brown, but dB is named
after Alexander Graham Bell.

--  

-TV


Re: Missing volatile qualifiers in MCU vendor header files?
On 6.4.20 01:00, Dave Nadler wrote:
Quoted text here. Click to load it


Just stay away from the hardware guys' software, write your own.

I lost 6 weeks of debugging using Atmel's driver mess. The ST
code is not any better.

The CubeMX is good in handling the pin allocation puzzle,
but I'd very careful about the offered software.

--  

-TV


Re: Missing volatile qualifiers in MCU vendor header files?

Quoted text here. Click to load it

Too true.  Software provided by silicon vendors is consistenty awful.
It tends to be bloated and full of errors.  I don't know who they hire
to write libraries and demo apps, but they haven't a clue.

Usually the only thing that can be salvaged are header files with
register offsets and bitmasks.  Even then you have to double-check
them for errors.

--
Grant


Re: Missing volatile qualifiers in MCU vendor header files?
On Mon, 6 Apr 2020 13:21:07 +0000 (UTC), Grant Edwards

Quoted text here. Click to load it

When a new engineer is hired, the first thing he/she has to
familiarize with the company products. Making demo apps is a good way.
Unfortunately, these private demo applications are published without
checks by a more proficient person :-).

Quoted text here. Click to load it


Re: Missing volatile qualifiers in MCU vendor header files?
On Monday, April 6, 2020 at 3:05:47 AM UTC-4, Tauno Voipio wrote:
Quoted text here. Click to load it

Yup, I had to write my own drivers for ST DMA, timer, SPI.

But it gets quite impractical to write one's own drivers for every
ethernet and USB peripheral set etc... And lots of the vendor
stuff absolutely does not work (ST for example).

Now if I could only figure out why my release build works,
but not the debug build (reverse of the usual puzzle!)...
Off to check the timing on the scope!

Re: Missing volatile qualifiers in MCU vendor header files?
On 04/06/20 15:14, Dave Nadler wrote:
Quoted text here. Click to load it

Always write separate header files for the cpu and each of the on chip
peripherals as a first task for every new processor. It's a good
way to get a top level overview of the machine and capabilities.

Had a look at the ST code examples and their obscure header file
mess for cortex years ago. Our way or the highway and unusable
as presented. Code examples were rubbish as well. May be better
now, but still useless if you have a house standard for form and function...

Re: Missing volatile qualifiers in MCU vendor header files?

Quoted text here. Click to load it

I bet they're no worse than NXP.  The header files and demo sources
for the KL03 family were an utter disaster.  The simple "hello world"
and LED flash apps were so huge due to the bloated libraries that they
wouldn't even fit in the flash memory of the smaller members of the
family.

Quoted text here. Click to load it

Probably worse.  AFAICT, uController demos are all written by people
who think a Raspberry Pi 3 is a tiney embedded system and can't do
anything unless there's a button for it in the Eclipse toolbar.

You'll have to excuse me now, those darn are kids on my lawn again...

--
Grant

Re: Missing volatile qualifiers in MCU vendor header files?
On 8.4.20 16:58, Chris wrote:
Quoted text here. Click to load it


At least Atmel and ST made the mistake by attempting to
cover all the processors types with one set of sources.

This led to a sorry mess of conditional code, which is
undecipherable even for a seasoned programmer. (me:
over 50 years of embedded code).

--  

-TV


Re: Missing volatile qualifiers in MCU vendor header files?
On 2020-04-08 Tauno Voipio wrote in comp.arch.embedded:
Quoted text here. Click to load it

Does anyone have experience with Renesas and their Synergy
stuff? Did a workshop a while ago and this all seemed to
work quite good. But ofcourse this was a prepared workshop
example that was bound to work. Did not have a chance to
try it on a project of our own. We nowadays mostly use ST,
so using something else must have huge advantages before we
give it a try. ;-)


--  
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

FORCE YOURSELF TO RELAX!

Site Timeline