CubeIDE forcing you to login to ST is complete [...]

[JDoe.2]

I don't care if the title of this post breaks some sort of forum usage rule, I just need to make it absolutely plain that I am sick and tired of every last company on Earth insisting I have an account with them and use it whenever I so much as breathe, drink a glass of water or, Chtuluh forbid ! update a HAL library for a microcontroller.

I believe there are more than enough bugs in CubeIDE, let alone actual necessary features that are missing, to keep your developers occupied forever. You did not need to waste everyone's time forcing people to login to ST. This feature brings nothing, helps no one but yourselves, and was asked by absolutely nobody, ever. So please, may I suggest you rethink this stupid, bordering on evil new addition to CubeIDE, and remove it with the next version ?

FYI, some of us work in companies where our computers are not, must not and cannot be, connected to the internet. It's already tough enough installing some of your HAL libraries (the patches) while being offline, we do not need the additional hassle of a login system that does nothing useful anyway.

A tool has to be convenient. If my screwdriver required an internet connection so as to snitch on how many turns I do in each direction depending on my GPS location, I'd start considering switching to fingernails or rocks.

You are welcome to try and make a case as to why you need me to log in to download updates to stuff you provide free of charge. I do need a good laugh.

Oh and I haven't checked on my last CubeIDE ticket... did you finally fix the bug where CubeIDE is confused when launching firmware on a target with Flash banks swapped ? Because that would sure be of actual use to the legions of programmers doing FOTA.

[LeaveMeAlone]

Login required for every single small thing is so annoying. Want datasheet for our processor? Oh, you need to login.

You need some utility right now when you are on site? Ok, just login. You forgot which email/password you use? Nevermind, just reset your password or create new account. We will answer in few hours.

Oh, You want to download library? You know the drill...

If they are afraid of bots, they should use some captcha alternative.
What will be next? Like and subscribe?

[Oskar_H]

As far as I know, login is not *yet* required to download datasheets, programming manuals or any technical document from Docs & Resources menu. It means that as of today ST is not interested in doing analytics of these downloads. But one day could come where they could have this great idea. You never know, downloading a specific application note would say a lot about your usage of the MCU ! Tracking only a version of a FW pack or peripheral used in a project is not very talkative finally.

Never tested the "Forgot your password ?" thing, so I can't tell...

What's next ? Receiving newletters ? Fill-in a survey at each session ?

Agree with you about other ways to register a user. Maybe they just don't know but the anonymous login is commonly used around.

[Piranha]

The analytics on documentation and other downloads can and already are gathered without a login.

@Oskar_H , a silent opt-in on newsletters are already executed in some cases:

https://community.st.com/t5/feedback-forum/st-marketing-abuse/td-p/596281

@Harvey White , what you are describing with your higher layer drivers is the platform/OS layer depicted as the "Driver" (yellow) layer in this picture:

https://microchip.wdfiles.com/local--files/harmony:overview/harmony.jpg

The HAL belongs to the hardware "PLIB" (red) layer and should provide the interrupt safety, but not the access control. Instead the famous broken "HAL lock" tries to do both, but doesn't actually provide any of those, while simultaneously adding an unjustified way of failure under a basic and completely normal usage. A spectacular failure, which just shows that the developers do not understand what they are doing...

[Harvey White]

Which now (not that it had an explanation before) explains the "HAL_lock".  Apparently a good thing that I managed to wrap the function in my own operating system choice of semaphores. 

Now if we only had a decent explanation of how the rest of it worked, and what they thought they were doing.

I'll agree that task interlocking with semaphores is another level up.  Wonder why we had to go to a rival manufacturer to find that out?

Wonder if a decent explanation of HAL (and LL) drivers might mention some sort of layer model?

It's beyond expectations to teach people how to design software for a manufacturer of chips.  Not their job.  However, a small document that describes software levels and what part their software plays, and where it is, well.......

For a company that espouses Azure as a wonderful solution (and second lines FreeRTOS), if we're doing operating systems.  Somewhere I managed to find some supporting documentation.

Why am I not surprised?

Eventually, documentation will make or kill your product.  Wonderful to have advanced features and "golly gee whiz" hardware.  Now to figure out how to use it (and the application notes are not all that good in places).

[Harvey White]

As a further clarification, I should mention that things are often more complicated than this.  Let's take the example of an INA-219 current monitor chip interfaced with I2C.  The following levels are available:

1. Hardware: connected to chip
2. I2C driver provided by ST.
3. HAL_I2C for each interface used.  Has Semaphores and encapsulates some higher composite functions.  Those functions vary per chip and interface.
4. CHIP driver, using the HAL_I2C composite driver.  Talks to the chip and provides register level interface, functional interface, and chip specific functions
5. SYSTEM_CHIP driver.  Uses CHIP driver.  This allows multiple local chips on multiple I2C interfaces, and depending on the system architecture for the project, allows packet communications over local, NRF, WIFI, serial, or I2C_networking to another processor which contains the interface to the desired chip on another board.
6. APPLICATION PROGRAM, interacts with the SYSTEM_CHIP driver only.  Only needs to talk to a particular chip at a particular node address, the operating system and driver take care of all the rest.

This works for me, structure wise. It's designed for multiple board, multiple processor use in a distributed system

[Tobe]

I think you posted in the wrong thread...

[Beep]

The log-in function in my IDE isn't even working.  It just does nothing.

So now I'm stuck.

ST...  we really don't need this log-in nonsense.

If you really must force it on us, you need to make sure it is 100% reliable - and it ain't.

This is wasting my valuable time.

[Slh]

After a while, a project with STM32. I forced to log-in... I just want to know where is this feature really useful and why we must be log-in?

[CBerg]

@Slh as far as I am concerned: nope, this BS is not usefull at all - at least for the users. It's just annoying.

[SP5LMA]

I found my way here because I was searching for a solution to a bug that this mandatory login is. I hope it was not introduced only to spy on users.

I am academic teacher and so far we've been using STM32CubeIDE successfully in teaching and our scientific research. Many dozens of students learnt STM32 and ARM programming under supervision of my colleagues and mine. Many of them have careers in the industry and build their solutions using STM32. I believe we helped ST quite well over the years by providing free advertisement. We bought your development boards because STM32CubeIDE and HAL were freely available.

However, it seems like these days are coming to an end, unfortunately. I am not allowed to request my students to create external accounts with any company. I consider that as soon as login-free version of STM32CubeIDE will be too outdated to be useful, we will search for another vendor.

I strongly suggest to fix this issue ASAP.

If you want to e.g. lockout competitor IDE from accessing HAL then maybe keys are the solution? We have to login to the website to download Cube anyway so acquiring/deploying keys once per install would be fine. *Github nods and grunts*.