[proposal] Public STM32CubeMX issue tracker

[Jan Breuer]

Posted on December 14, 2017 at 13:10

There are lot of bugs in STM32CubeMX and its components. Having public issue tracker will simplify the situation with reporting all issues and tracking their status.

Idally, having public source code of STM32CubeMX can also atract community to fix these issues and send Pull Requests to ST developers. Waiting more then year (or forever) for fixing a bug is not ideal situation.

What do you think, ST?

#bug #stm32cubemx

[Jeanne Joly]

Posted on February 23, 2018 at 09:55

Hello

Breuer.Jan

,

Thanks for taking time to share your point of view on the ST forum.

I agree thatit is not normal when it took more than a year to fix a correction however, as you may know, the delay of a fix could depend on the complexity, the project priorities, the marketing decisions and of course, the availability of the development team. And you can be sure that we do our best to have a reliable solution and a CubeMX tool that evolve according to customer requests .

Regarding your point on public source, a study to have the FW library on github is in progress. However, I can't give you anymore details for the moment.

It is a first step that do not fully answer your request but we keep your idea in mind and we are in the way to have some changes regarding the availability of the source code.

BR. Jeanne

[Jan Breuer]

Posted on February 23, 2018 at 15:08

Hello

Joly.Jeanne

‌,

I understand the situation and the priorities and it was just a suggestion.

So I'm surprised and very happy to hear that you are really doing that study.

BR. Jan

[henry.dick]

Posted on February 23, 2018 at 16:16

It helps to have a publically accessible bug submission mechanism. it can be hosted off ST's website for example.

giving the public the ability to view the bugs submitted would be a dead weapon your competitors can use against you (as a chip maker).

If I were NXP/TI/'you-name-it chip maker', my first market slide would be a link to that report of bugs,

[henry.dick]

Posted on February 23, 2018 at 16:12

'

the delay of a fix could depend on ....'

all the factors driving the delay for a fix are internal, which is probably NOT what should be primary drivers for your decision making.

with that said, my 2 cents:

1) it may serve ST and its customers better if you take a step back from the bug fixes and really think about your software strategy. Having multiple libraries out there confuses people, spreads your resources thin,  creates tons more work for your teams, and may contribute to the churn of your library development efforts, which in turn deters people from investing in your libraries and developing on your chips.

it pays to have a consistent strategy and stick to that strategy.

2) it may help by understanding where your customers' needs are before doing anything. I do not know of ONE (1) commercial account that uses the OEM libraries (SPL/Cube/LL/...), or dictate the use of such software.

Your investment in those libraries may be drawing a lot of demands for your software resources but not for your chips. So this whole thing could mount to a giant nothing burger.

It may make sense for ST to go to its largest customers to see how they use the chips and software, before deciding how ST should move forward. 

The current situation on your software side is unlikely sustainable.

for one, i like your chips and hope you prosper long-term.

[Jan Breuer]

Posted on February 23, 2018 at 16:40

There are at least two points of vew.

From the marketing point of view, it is sad, that many decisions about used chips are done by managers and not with cooperation with developers. So many dumb managers will listen just to buzzwords and understand this as weapon againts ST. This is reality, it is sad and I understand your opinion.

From developer point of view, it will be always weapon against ST's competitors. Like 'Hey, they have bug tracker with 1000 bugs but 980 from them are already solved. Thats great and really impressive!'

[henry.dick]

Posted on February 24, 2018 at 02:00

'There are at least two points of vew.'

i'm sure. but the fact that noone is doing it should be enough to make you think really hard as to why it is smart for you to buck the trend.

'From developer point of view, it will be always weapon against ST's competitors. Like 'Hey, they have bug tracker with 1000 bugs but 980 from them are already solved.'

let's say that you do run up two otherwise identical chip makers, one usually has an errata of 20 items in it, and another usually has 1000 bugs (99.9% fixed however, by now). you think you are going to go with the guy with 1000 bugs consistently on its chips?

if it becomes known that a vendor often has 1000s of bugs in its chips (early release), any sane person would say 'let's go with somebody else', or if you really want to go with this guy, 'let's wait for them to work out most of those bugs'.

a public bug submission is great; a public bug report is suicidal.

[Jan Breuer]

Posted on February 24, 2018 at 11:11

You are mixing many things.

• HW vs. SW bugs
• Released vs. Unreleased

Vendor will probably never release early unfinished chips to the public. The small amout of partners using this unfinished chips will probably not use this tracker, because they has tighter connection to the vendor. We have tested some early ADC design for ST when I was at the university and we have reported everything back to responsible person at ST. Public is not interested in this - in bugs of unreleased and unused peace of hardware and software.

On the other side, I have reported HW bug many years ago (7+) which is in HSE in all lines of STM32 causing frequency jumps when using with any crystal. ST confirmed my finding but it never appear in any errata and it was never fixed. I don't have frequency counter to verify this bug now, but I suppose it is still in newest chips. I would like to see this somewhere.

So, if there is 1000 SW bugs and 99.9% is fixed, it is completely OK.

If there is 1000 HW bugs and none is fixed or does not have known way to overcome the issue, then it is bad for the vendor, because it is producing bad chips. This is not what ST do, because many HW bugs in STM32 have software or external hardware solution.

As Jeanne told us, they are thinking about starting public development of firmware libraries which completely make sense as good starting point. It is not for reporting HW bugs. Community can report SW bugs and even propose immediate fixes.

[T J]

Posted on February 24, 2018 at 12:21

We have been working around bugs, since forever.

ST, HAL and the CUBE, seems a good team,

Stable and robust after the misunderstandings subside.

The substructure of HAL-ARM interface seems ultra reliable

disfunction()

{

    I don't want to mention the wife.

    My advice is : Be careful what you wish for and be thoughtful how you ask.

    Flowers work.

:}

ST is better to wait for a good idea to come along.. ( does that sound like my wife or what ?)

I would suggest ST has a keen ear for you all.       ( she is listening from a mile away)

We need some flowers to get real progress

[henry.dick]

Posted on February 24, 2018 at 13:03

'

they are thinking about starting public development of firmware libraries'

that makes perfect sense actually, as I wrote in a separate post: ST needs to rethink of its software strategy globally. My personal experience suggests that its software offerings have limited appeals to its large commercial users.

if that issue is structural, they will realize that the resources they spend on software are not pulling in much chip sales, and have minimum return on their investment there.

then open-sourcing the development to the user community makes perfect sense.

but before they do that, they better think really hard as to why they are in where they are software-wise. I think without strong software support, your hardware side is exposed to poaching.