CubeMX 4.26 - new problems with STM32L4 USB device

[gbm]

Posted on June 11, 2018 at 16:58

I tried to re-create my 4 well-tested USB device demos with 4.26. While HID mouse and MSC work flawlessly, two others do not work:

CDC - COM port shows in device manager but cannot be opened in terminal; same basic code (just a simple echo) works ok with 4.25.1 and 4.24 (broken PLL programming in 4.25).

HID keyboard - no data received.

I noticed that 'custom HID' used for keyboard was heavily changed in 4.26, and the changes ar not good - DataIn callback was removed - bad

:(

.

[Sven Köhler]

Posted on June 12, 2018 at 03:33

Shouldn't you also mention the version of the STM32L4 package that you use? After all, you can use STM32CubeMX with various version of the STM32L4 package.

I have a project using STM32L4 1.8.1: USB works on Windows and Linux (kind of, data ist lost here and there)

I have a project using STM32L4 1.12.0: USB works on Linux but not Windows 

STM32CubeMX 4.26.0 gets stuck on generating code on Windows while it works fine on Linux.

I can't downgrade cause I don't find old version for download.

[Khouloud GARSI]

Posted on June 12, 2018 at 10:33

Hello,

Mazur.Grzegorz

‌, thanks for your feedback. This is now under check. We will update you ASAP.

sven.koehler

‌, with the current version of STM32CubeMX version , the STM32L4 Cube package V1.0 should be used. This is mentioned in the

http://www.st.com/content/ccc/resource/technical/document/release_note/b2/02/4b/e3/81/32/49/c4/DM001076pdf/files/DM001076pdf/jcr:content/translations/en.DM001076pdf

.

Khouloud.

[Sven Köhler]

Posted on June 12, 2018 at 14:05

So I shouldn't use 

STM32L4 

1.8.1 with recent CubeMX? You cannot expect me to upgrade all my projects, especially since there are bugs with the most recent version of 

STM32L4

. Do I have to keep multiple versions of CubeMX? Will using recent CubeMX together with old 

STM32L4 package versions result in broken code?

[Khouloud GARSI]

Posted on June 13, 2018 at 12:00

Hi

sven.koehler

‌,

The current version of CubeMX is compatible with firmware package L4 V1.0. Using an old firmware version with a recent version of the tool may cause incompatibility issues.

especially since there are bugs with the most recent version of

STM32L4

.

-> Could you please precise the bugs you're seeing. We will check them and correct them if confirmed.

Khouloud.

[Sven Köhler]

Posted on June 13, 2018 at 18:09

Dear Khouloud,

your advice to use old firmware packages with older versions of CubeMX does not agree well with the fact that old version of CubeMX are not available for download from st.com. On this forum, some users provided links to their Google drive. So I could download old CubeMX versions after all. However, there are a few issues with that:

• Redistributing CubeMX might be illegal. So I hope ST's legal department doesn't go after the users who offered CubeMX downloads via their Google Drive
• I do not know these users, and I don't know whether the downloads they offer are authentic. There could be viruses, trojan horses, cryptominers, etc. included with the versions they offer. 

ST must offer downloads of old CubeMX versions. If ST doesn't do this, your advice leaves a bitter taste on my tongue.

Also, one of your colleagues here on the forum said, that users should simply keep the old installers on their harddisk. However, if I simply hit the 'upgrade' button in CubeMX in the past, I might not even have an installer on my harddisk - and certainly not in my download folder.

If you have no leverage over the people who manage the available downloads, that's a bad situation for all of us.

Could you please precise the bugs you're seeing. We will check them and correct them if confirmed.

I reported the bug in another thread already. It's a bug with the USB middleware/driver code.

[Khouloud GARSI]

Posted on June 25, 2018 at 13:42

Dear

sven.koehler

‌,

your advice to use old firmware packages with older versions of CubeMX does not agree well with the fact that old version of CubeMX are not available for download from st.com.

->Agree! But, what I meant was to use the updated CubeMX tool with the updated firmware packages. Each new version contains some enhancements and bug fixes. So it's better to use the most recent one.

I know that, sometimes, there are some regressions and that's why my colleague suggested to keep the old version installer on your machine.

Also, one of your colleagues here on the forum said, that users should simply keep the old installers on their harddisk. However, if I simply hit the 'upgrade' button in CubeMX in the past, I might not even have an installer on my harddisk - and certainly not in my download folder.

->If you want to keep old installers on your local machine and do not loose them after the upgrade, please download the updated version from ST website and do not do it through CubeMX tool. The tooloverwrites the previous version when installing a new one.

Khouloud.

[taraben]

Posted on July 12, 2018 at 19:48

Hello,

what is the workaround to this problem?

I upgraded a project to recent CubeMX 4.26 and L4-1.12 and now it shows that symptom.

USB COM port visible in Windows but not connectable.

I can reproduce this on an NUCLEO -L476RG.

connecting DP to A12, DM to A11, GND to GND.

So sad.

Any hints on this?

Regards, Adib.

[taraben]

Posted on July 12, 2018 at 20:05

I found that for my NUCLEO L476RG board it helps to 'downgrade' to L4-1.11 library version.

I can do that by manually edit the .ioc file.

I will test with my other application.

Please ST: fix this problem. Also it would be very helpfull you provide a list with known problems of the current version.

regards, Adib.

[Jerome Godbout]

I have the same issue with 1.12, I move from 1.8 to 1.12 and my usb composite (CDC Virtual COM and HID) are showing all kind of weird behavior (long hang when doing descriptor fetch with USB Tree View or when opening the COM port under TeraTerm, bad descriptor most of the time, sometime it work but most of the time it failed, but the firmware did answer the descriptor and the data seem valid). 1.12 seem riddle with bug on my end, same descriptors byte array and same application. I was trying to update to see if one of the bug we see was fix, but it did bring more bug then it solves so far. It make our device unusable.

If anybody have a stable version, would be nice to know which one is, thanks. I will try 1.11 to see if it does work properly.

BTW, my bug under 1.8 was the hid report I ask to send a single byte, but once in a while (every 8 minutes or so) it send a 5 byte report even if application layer asked for a single bytes (made a runtime assert of this without problem). The faulty packet was observed with a hardware USB tracer.