Missing volatile qualifiers in MCU vendor header files?

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

Reply to
Dave Nadler
Loading thread data ...

Dave Nadler schrieb:

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

Reply to
Tilmann Reh

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
Reply to
Tauno Voipio

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
Reply to
Grant Edwards

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 :-).

Reply to
upsidedown

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

Reply to
Dave Nadler

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!

Reply to
Dave Nadler

PS: Really not where I expected! Better if ptr is volatile, not struct or fields. Explained well by David Brown here:

formatting link

Reply to
Dave Nadler

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.

Reply to
David Brown

We already knew that ;-)

Reply to
Dave Nadler

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.

Reply to
David Brown

Remember that fame is volatile.

--
Best wishes, 
--Phil 
 Click to see the full signature
Reply to
Phil Martel

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

Reply to
Dave Nadler

And the 'DB' in Aston Martins.

--

-TV
Reply to
Tauno Voipio

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...

Reply to
Chris

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.

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
Reply to
Grant Edwards

and the ubiquitous dB

--
Best wishes, 
--Phil 
 Click to see the full signature
Reply to
Phil Martel

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

--

-TV
Reply to
Tauno Voipio

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
Reply to
Tauno Voipio

We agree. In the end we wrote a (sort of) parser for ARM's SVD file format to produce our header file equivalents. Several others have gone down this route too.

Stephen

--
Stephen Pelc, stephen@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.