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

oh, you still use one of these old screwdrivers, that can work without live wifi online connection ?

ok, i am also one of these "ancient" guys, and maybe, if STM keeps following the "new style", we have to look for another manufacturer sooner or later.

It's really annoying to have to login, maybe it's better that the data collection is done as Facebook (Meta) does.

This is how Facebook collects data on you even if you don’t have an account

Hi,

Sorry for the inconvenience. Personally I agree. Rest assured that this is a hot topic internally for the last few weeks.

Coming back to your specific technical issue with the "offline" use case. This should not be a problem.
The user can use the following workflow on an offline computer without having the new authentication blocking him:

1. Manually download the CubeFW packages from st.com
2. Inside STM32CubeIDE use the menus:
   1. Help -> Manage embedded software packages
   2. STM32Cube MCU Packages -> From local...
3. Point to the manually downloaded zip-file, accept the license and install it.

Works on my PC. Please have a try!

Regarding the flash bank swap issue, do you have some ticket reference I can use to follow-up on this case?

Authentication
Users familiar with STM32CubeMX will now notice that the software is requiring them to log in to their my.ST.com account before downloading a package. While users always had to enter their credentials when downloading a piece of software from ST.com, the new version slightly tweaks the experience so everything happens within the software for better cohesion. It’s still possible to use STM32CubeMX without an account. However, by asking for a login and password, like on the website itself but from the software, users enjoy a more cohesive experience.

Older IDE versions (ex. 1.6, 1.7) performed horribly, and now, when the IDE finally was getting good enough, yo implement this? Really?

Please take your "cohesive experience" away, it's a time consuming, annoying, useless step.
How in earth are you calling this "enjoyment". ?

I have an open source project where I used a CubeMX script to build the code automatically, compile and place the output file ready for programming.
It worked perfectly, the users didn't had to mess with the IDE, only install it and then run the script, it was that easy.

Now the login requirement ruined everything!

The enjoyable cohesive experience of datasheet downloads at NXP:

https://www.reddit.com/r/embedded/comments/15uoakm/this_is_why_i_never_give_my_real_info_to_these/

Exactly.

Everyone is asking for personal data, then they screw up, I don't care if it was some evil hacker, the responsability was ultimately yours for storing my data, so you must take care for it.
But looking how their software still has years-long unresolved bugs, guess how the servers are.
Later your email/phone starts getting spammed and receiving strange calls from international numbers.
And your already complicated 15-char password mixing upper and lower case, symbols, numbers and unicorns, impossible to guess, was plainly revealed. Again change them all.
A post-**bleep**up "Sorry" is not enough.

Yes it is possible to unpack and install the Cube firmware libraries manually without logging in. At least it worked before the latest CubeMX/IDE update. But you still have to log in to download them. You can also get most of the released versions from github, without login.

Agree, the forced login is simply uncalled for. There is no clear benefit to the users and no potential benefit to any increase in ease of use or productivity. Please provide a clear advantage to its use or remove it.

Dear @Piranha , all,

As stated in previous post, we are considering your valuable feedback in order to provide best customer experience : Debug and Software tools ecosystems are now key factor for considering an MCU product in next project design at same level as its performance and features. As you can see here from last Embedded Survey - May 2023 with a panel over 600 experienced embedded engineering staff .

STM32CubeIDE is key element for STM32 MCU/MPU ecosystem and we can not ignore your valuable feedbacks. Our Marketing and Technical teams will take it into account in the future roadmap for our customers best experience. 

by the way, very nice nickname “Piranha”- it was the internal project code  name for the very first and famous  MCU STM32F103XB :) I was among the team working on it :)

Cheers,

STOne-32

There are a number of things to consider:

1. The desirability of using a product is related, in part, to the convenience in using it.  Difficult to understand, limited (in terms of function), and administratively limited products have no desirability.
2. ANY and EVERY microprocessor manufacturer MUST have free tools.
   1. Nobody will pay thousands of dollars to experiment with a product that may have no utility.
   2. Limited programs unless you pay money will eliminate "casual" users and may limit you to large corporations.
   3. Large corporations may buy 10000 of your product, but it only takes 1000 people buying 10 of the same product (at a higher cost) to surpass that corporation.  Ignoring the small user has penalties.
   4. Making a comment (by a corporate representative) about how the small user (or anyone) should be grateful that you are providing free tools is extraordinarily counterproductive.  Annoy enough small users and you may well notice it on your bottom line.
   5. Tools need to be as versatile and as easy to use as possible.  Seems simple, but long learning curves are destructive to user learning.
   6. Commented code, WELL commented code, is essential to understanding your product.  The more who understand it, the more uses it will be put to.
3. Those tools must be the foundation of your demonstration code.
   1. Using something like BSP (which seems to be a closed system) says that "we know and you don't"
   2. it also says, the tools we have (MXIDE) don't do what we want it to do.
   3. Examples USING MXIDE will promote the use of MXIDE
      1. Examples that are not well commented will not teach, and those examples that do not teach will be useless.
      2. Knowing YOU know how to make something work is wonderful.  But if you don't, who would?
   4. While ST Micro Nucleo, Discovery, and EVAL boards are wonderful, how do you support the "I buy your processor and put it on my custom board? projects......
      1. There's a remarkable lack of documentation on how to do such projects.
      2. Examples using your own custom hardware become useless when using your own custom BSP drivers.
      3. Do BSP drivers come with a "how to use them"?
      4. do BSP drivers come with a "this is how we designed them?"
      5. NOT looking for how to write software, but DO look for how this software interacts with your custom hardware.
   5. IF you add in things like FreeRTOS, StemWIN, emDOS, TouchGFX
      1. Please pay attention to the above and provide information on how to write drivers.  Not so much the drivers themselves, but
         1. What your software structure expects.
         2. Why you designed it that way
         3. what does that part of the code really do and why?
      2. Note that TouchGFX in particular lacks information
         1. I'm not likely to use it because it seems very limited in how the code works
         2. what the drivers do and when seems to be a problem
      3. Since StemWin seems to be obsolete, it makes itself irrelevant
   6. Having to dig information out of badly commented code is counterproductive.
4. Just because the code works does not make it comprehensible without additional information
   1. EVERY program is written with assumptions on how it is coded, how it is to be used, and even what it ought to be doing
   2. Leaving out that information makes it hard to understand at best, and useless at worst, regardless of how well it demonstrates that "wow!  this is neat!" feature
5. Some things to consider
   1. I do write software
   2. I've done it for a while
   3. Clarity in writing is a good goal