Questions surrounding __HAL_LOCK

[matthew2399]

Posted on April 26, 2016 at 00:12

I’m an engineer at Fluke, and we’re using an STM32F4xx seriesmicrocontroller (together with its HAL drivers) as the basis for a newproduct. The HAL contains a “locking�? mechanism, where eachsubsystem—I²C, USB, UART, and so on—has a “locking object�?. My team hasbeen working on the assumption that this mechanism’s goal is to providesome mutual exclusion for memory-mapped hardware registers and relatedstate so that, for example, an interrupt doesn’t modify the same hardware state being manipulated in the main “thread�? of exectution.

What’s confused us, however, is how this is done. The driver code found in stm32f4xx_hal_def.h defines the locking mechanism as follows:[1]

typedef
enum
{
HAL_UNLOCKED = 0x00U,
HAL_LOCKED = 0x01U
} HAL_LockTypeDef;
#if (USE_RTOS == 1)
/* Reserved for future use */
#error ''USE_RTOS should be 0 in the current HAL release''
#else
#define __HAL_LOCK(__HANDLE__) \
do
{ \
if
((__HANDLE__)->Lock == HAL_LOCKED) \
{ \
return
HAL_BUSY; \
} \
else
\
{ \
(__HANDLE__)->Lock = HAL_LOCKED; \
} \
}
while
(0)
#define __HAL_UNLOCK(__HANDLE__) \
do
{ \
(__HANDLE__)->Lock = HAL_UNLOCKED; \
}
while
(0)
#endif /* USE_RTOS */

In summary, “locking�? consists of setting a flag, or returning an error(indicating the system is busy) when the flag is already set.“Unlocking�? consists of unconditionally clearing the flag. What throws us is the immediate return of HAL_BUSY in the case ofcontention. If a HAL lock is providing mutual exclusion between the mainthread and an interrupt handler, what should be done if the interrupt isthe second caller of __HAL_LOCK and gets HAL_BUSY? An interrupt cannotpause its execution and start again when the lock is no longercontended, like a userspace thread could in a multitasking OS. (The bestone can do is have the interrupt schedule the work for some later time,but this is not always feasible.) Additionally, many read-modify-write sequences (such as ORing bits) are performed on hardware registers without any additional protection besides these ''locks''. What is to keep an interrupt (or, if one is running an RTOS, another task) from executing in the middle of one of these sequences? Based on these observations, we tried redefining __HAL_LOCK and__HAL_UNLOCK to be a global “interrupt lock�?, i.e., the former disablesinterrupts and the latter re-enables them. For cases where several callsto these functions nest (whether intentionally or unintentionally), wekeep track of a nesting count. Unfortunately this doesn’t work well withthe I²C driver, since it contains several code paths where, on atimeout, __HAL_UNLOCK is called twice for a single call to __HAL_LOCK,unbalancing our nesting count to disastrous effect. How is the __HAL_LOCK/__HAL_UNLOCK system meant to work? It would seemwe’re not using it according to its design goals. [1] All code is taken from STM32CubeF4, version 1.0 #hal #stm32f4

[Morty Morty]

Posted on May 14, 2018 at 17:05

Any news here? I do get the feeling that the forum is a black hole where user-feedback, and even solutions as below, are dumped in to rot . Even if it _seems_ like it is actually addressed by moderators: As there is no public bug-tracker no one can trace the issue. This is very frustrating, and I got feedback from other developers that they stopped reporting issues due to this.

[Selso LIBERADO]

Posted on May 14, 2018 at 17:16

That's write, no bug tracker, this weak lock implémentation has been continued in the several following cube implémentation.

Why not hosting the code in a repository, I'm still wondering.

[Tesla DeLorean]

Posted on May 14, 2018 at 17:58

>>Why not hosting the code in a repository, I'm still wondering.

Honestly you'd need someone like Linus to yell at people when they push stupid ideas into the repository, then again if they already had someone like that we wouldn't see some of the crap we see in there now.

I think these things are hard to push into large corporate cultures, software teams get more unmanageable with size, and without some clear vision of the architecture and goals, and I suspect things would become overwhelming.

[T J]

Posted on May 15, 2018 at 05:35

' overwhelming ' is an understatement in orders of magnitude.

We are all working with projects with googolplexity of 10-20 dimensions (tools/IDEs/methods)

To be a master of none is quite difficult, most of us are here.

That's why everyone appreciates the forums.

and appreciates the great work of

Turvey.Clive.002

‌

meyer.frank

‌

Waclawek.Jan

‌ and many others that look in.

Thanks for all the long hours you guys spend checking in on us.

We all know, it is impossible to work alone initially.

Thanks for the great support.

Aside on googolplexity;

A product involves end to end engineering crosses 10-20 development tools/platforms.

ie, CanBus Management with nodes and a terminal Ethernet SSH interface to the AWS cloud, including Displays, debug screen structure etc.

Schematic & PCB editors & DRC & gerber & Pick n Place & knowing how to make a power supply quiet.

A cross platform SSH server , Angular II, Type Script. SQLDatabase management,

The browser must graph sensors directly on screen and interface to multiple database structures, staff, products, stores etc..

The server has to report in Excel with data reduction systems to use the Solver to decrypt the Sensors profiles.

With CanBus Node management from the browser, adjusting the config remotely, through the Cloud SSH to terminal, to node.

other than that , life is easy.

[Tesla DeLorean]

Posted on May 15, 2018 at 15:23

>>' overwhelming ' is an understatement in orders of magnitude.

Yes, but having a gate keeper at the front end stops some of the stupid and patently bad ideas getting in and exploding geometrically. I'd estimate 80-85% of the problems on the forum could be significantly mitigated with a little more rigor to the code check-in and testing regimes. If we could cut some of the noise and triage stuff we could focus on real issue and problems.

I can bark and shout here at times, but it is usually to break through the thinking that got people into the situation they find themselves in. Often people are so focused on what they think the problem is they miss the real issues.

Predominantly old white guys...

 

We grew up without safe spaces, people shouted at us, and we had to build things with no money and no resources, and created things that didn't exist before.

[Morty Morty]

Posted on May 15, 2018 at 16:00

I strongly disagree. I have participated in quite a few OSS projects and to my experience it only needed a very few competent people to get the project in the right direction (without any yelling), because they decided what got accepted and what not. Also to my experience bad quality contributions typically that need yelling at typically come from people who get paid to get the code into the project to support some feature. Thus in this case of the HAL there might be a bit of yelling required because the incompetent/paid people probably are the ones who decide what gets accepted (judging from the code quality). But for the frustrated users there would at least be someone to yell at, but the community manager, who has minimal technical background.

BTW: There is sill no reaction from ST on this issue......

[Willem La Grange]

Posted on May 15, 2018 at 17:32

Can we halt this thread please? This tone of these posts does not augurs well amongst educated people. The forum is designed to help engineers building great solutions using STM products and arguments of this nature is off-topic. Please get another forum to voice your dismay. I don't think it is necessary for the whole world to know about your personal views. We would only like to know about your technical views,

[AvaTar]

Posted on May 15, 2018 at 18:37

... to my experience it only needed a very few competent people to get the project in the right direction (without any yelling), because they decided what got accepted and what not.

But according to my experience, technically competent people have often no drive to rise in hierarchies, or become disillusioned by internal intrigues and hostilities. Leadership is frequently manned with a different kind of people.

[Tesla DeLorean]

Posted on May 15, 2018 at 19:21

That and the dynamics of a group of 5-6 technically competent individuals is entirely different from a group of 50-60 where the hiring is more lax, or you inherit a few morons that management favours. The guy that checks in code that breaks everyone elses work, or regularly damages the repository.

And by yelling I'm talking about the type of stuff when someone is about to walk off a station platform in front of the incoming train, and not some Ballmer chair throwing incident.

[SFran.16]

Checked latest version of HAL libs (STM32Cube_FW_L1_V1.8.0 and STM32Cube_FW_F4_V1.21.0). Still not fixed after more then two years. Perhaps a community "fork" of these libs would at least receive fixes...