stmicroelectronics / stm32cube_mcu_overall_offer Goto Github PK

One thing that would be great is if ST could have *.svd files for all device families on GitHub. If linked here as well, this could be a one-stop shop to have everything needed source-wise to develop and debug applications on STM32 hardware.

I build one by myself, but fail to score 1000 DMIPS.

My photo is not amazing but ZG is pretty visible - part of STM32F767ZGT6

expected: tools report 1Mb flash
actual result: tools report 2Mb

  12:06:56 : STM32CubeProgrammer API v2.17.0 | Windows-64Bits 
  12:07:04 : UR connection mode is defined with the HWrst reset mode
  12:07:05 : USB speed   : Full Speed (12MBit/s)
  12:07:05 : Manuf. ID   : STMicroelectronics
  12:07:05 : Product ID  : STM32  BOOTLOADER
  12:07:05 : SN          : 20663077464B
  12:07:05 : DFU protocol: 1.1
  12:07:05 : Board       : --
  12:07:05 : Device ID   : 0x0451
  12:07:05 : UPLOADING OPTION BYTES DATA ...
  12:07:05 :   Bank          : 0x00
  12:07:05 :   Address       : 0x1fff0000
  12:07:05 :   Size          : 44 Bytes

Hi,

as the subject states, it would be nice to have some pre-configured PlatformIO project "code" generation from CubeMX.

This is currently some barrier to start tinkering around with Nucleo boards. PlatformIO is used a lot in the Maker community and the STM32 support is really great atm. CubeMX generation PlatformIO projects would be even greater.

This thing: https://github.com/STMicroelectronics/stm32-lan8742
is listed under MEMS category but it is a Ethernet PHY.
Add a separate section for networking components?

Regards,
P.

Hello,

Do you plan to provide a github repo for the i-cube_lrwan library?

https://www.st.com/en/embedded-software/i-cube-lrwan.html

Kind regards,
Steve

Thank you for sharing HAL drivers etc. on Github!
I suggest rename this repo to something more meaningful.

1. Why call it STM32Cube when it is more about HAL?
2. Why call it Overall Offer? Overall implies something generic, non-specific while offer implies it is something for sale or trade exchange. Certainly this name does NOT encourage community participation. Quite opposite - to be honest.

It also makes this repo impossible to find if someone simply looks for STM32 HAL.
IMHO it is a very bad name. I suggest get more opinions, consult it with someone more familiar with Github and English language usage - I am not an expert.

The STM32Cube MCU Packages listed in this repository contain vulnerable usb device middleware.
Multiple usb device classes are affected by buffer overflows allowing successful attacks on devices.
The issue was reported to ST and resolved in march 2021 (https://github.com/stmicroelectronics/stm32_mw_usb_device/, release 2.8.0) but the fixed implementation was not incorporated in MCU specific Cube packages till now. So despite the fixes available users are still creating vulnerable applications for months. Furthermore the corresponding CVE-2021-38541 still was not published. The PSIRT team at [email protected] ignores my questions about updating Cube MCU Packages with up to date middleware and CVE.

Can you please provide some comment on this?

https://github.com/STMicroelectronics/stm32-w25q80ew -> not found

I've noticed that several PDFs are invalid format, ie. they are not displayed by the browser and also cannot be opened by my local PDF renderer. This seems to be a new problem, maybe a month ago, these PDFs were still valid, did you change something in your CDN setup maybe?

Here are the URLs of the invalid PDFs I could find (there may be more that I haven't found).

• AN3311 v1.4
• AN4045 v2
• AN4277 v4
• AN4629 v1
• AN4631 v2
• AN4706 v5
• AN4776 v3
• AN5110 v5
• AN5169 v2
• AN5215 v1
• AN5272 v4
• AN5273 v4
• AN5379 v2.1
• AN5457 v2
• AN5601 v1
• AN5617 v1
• DB2343 v3
• DB4072 v1
• DB4522 v1
• DS10152 v9
• DS10685 v6
• DS10688 v6
• DS10695 v4
• DS10757 v3
• DS10885 v2
• DS10938 v2
• DS12324 v3
• DS12556 v6
• DS12825 v3
• DS12903 v3
• DS12993 v3
• DS13195 v7
• DS13376 v2
• DS13607 v1
• DS13737 v4
• DS5318 v17
• DS6558 v4
• DS9496 v6
• ES0236 v5
• ES0239 v4
• ES0240 v4
• ES0251 v5
• ES0283 v4
• ES0319 v6
• ES0393 v9.1
• ES0523 v4
• PM0056 v6
• RM0390 v6
• RM0410 v4
• RM0434 v9
• RM0461 v4
• UM0919 v2.3
• UM1573 v1.1
• UM1680 v1.2
• UM1790 v1.2
• UM2407 v2
• UM2825 v1
• UM2977 v1

A sub-set of #34 issue

command line tool calls rightly says that sector 0x08060000 is followed by 0x08080000 and calls it 38308 or sometimes 47462

erasing sector 0007 @: 0x08060000 done
erasing sector 38308 @: 0x08080000 done
Download in Progress:

while GUI calls it sector 12 while showing non-existed sector 11 probably related to #35

Worth noting that within same 2.17 CLI and GUI behaviors do not match.

Follow-up to #11 (reported Dec 6, 2021) and #19 (reported Jan 30, 2023)

While clearly there is progress in this area erasing sector 38308 @: 0x08080000 this is still an issue

Executing .\STM32_Programmer_CLI/bin/STM32_Programmer_CLI.exe -c port=usb1 -w "C:\stuff\bundles\rusefi_bundle_proteus_f7\rusefi.snapshot.proteus_f7\console\..\rusefi.bin" 0x08000000 -v -s
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.17.0                  
      -------------------------------------------------------------------



USB speed   : Full Speed (12MBit/s)
Manuf. ID   : STMicroelectronics
Product ID  : STM32  BOOTLOADER
SN          : 20663077464B
DFU protocol: 1.1
Board       : --
Device ID   : 0x0451
Device name : STM32F76x/STM32F77x
Flash size  : 2 MBytes (default)
Device type : MCU
Revision ID : --  
Device CPU  : Cortex-M7


Memory Programming ...
Opening and parsing file: rusefi.bin
  File          : rusefi.bin
  Size          : 623.68 KB 
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 8]
erasing sector 0000 @: 0x08000000 done
erasing sector 0001 @: 0x08004000 done
erasing sector 0002 @: 0x08008000 done
erasing sector 0003 @: 0x0800c000 done
erasing sector 0004 @: 0x08010000 done
erasing sector 0005 @: 0x08020000 done
erasing sector 0006 @: 0x08040000 done
erasing sector 0007 @: 0x08060000 done
erasing sector 24786 @: 0x08080000 done
Download in Progress:
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±± 0%
  2%  4%  6%  8% 10% 12% 14% 16% 18% 20% 22% 24% 26% 28% 30% 32% 34% 36% 38% 40% 42% 44% 46% 48% 50% 52% 54% 56% 58% 60% 62% 64% 66% 68% 70% 72% 74% 76% 78% 80% 82% 84% 86% 88% 90% 92% 94% 96% 98% 100%

File download complete
Time elapsed during download operation: 00:00:21.193



Verifying ...


Read progress:
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±± 50%
  2%  4%  6%  8% 10% 12% 14% 16% 18% 20% 22% 24% 26% 28% 30% 32% 34% 36% 38% 40% 42% 44% 46% 48% 50% 52% 54% 56% 58% 60% 62% 64% 66% 68% 70% 72% 74% 76% 78% 80% 82% 84% 86% 88% 90% 92% 94% 96% 98% 100%

Error: Data mismatch found at address  0x08080000 (byte = 0x00 instead of 0x49)


Error: Download verification failed

Hello STM devs,

I am not sure if this is the best place to write this issue/idea but the only I found.

Firstly thank yo for all the support, hoewer as an end user not much experienced yet, I found examples hard to use (in other words you idea is that your software provided should speed up "production process", however is not). With the Examples you do not provide .ioc file (which would be very useful for further adjustments), secondly the examples are not compatible with code generated by STMCube tools (MX or IDE) which again make things time consuming to make it working.
I also found Cube MX verry buggy (especially clock configurator).

Duplicate of #11

@PierreLeCorre can you please poke whoever is in charge of internal ticket 120183?

I have been using STM32 series for years and I tend to swap between the STM32G0, STM32F0, STM32F4, STM32G4 and now the STM32C0. I have been using drivers but would love to only have a general driver that worked for all STM32xx MCU's they all seem very similar and could be easily done with some macros( #ifdefs and such ) based on configurations of each chip. this would allow validation to be easier since the same code would work for all MCUs and not need to be revalidated. also seems extensive to manage multiple sets of drivers that may get stale and have opputunity to improve the size and speed of code.

Hi we are numerous user of stm32f7, stm32g0, and may be other stm32 familly) to fall in trap that is already solved by ST!
@PierreLeCorre : have a look to :
STMicroelectronics/stm32_mw_usb_host#8
And
STMicroelectronics/STM32CubeF7#74

Historically, device headers, eg stm32F303.h, have lines like this:

#include "core_cm4.h"            /* Cortex-M4 processor and core peripherals */
#include "system_stm32f3xx.h"    /* STM32F3xx System Header */

But in some newer ones, eg stm32L562.h, it is now like this:

#include <core_cm33.h>                      /*!< ARM Cortex-M33 processor and core peripherals */
#include "system_stm32l5xx.h"               /*!< STM32L5xx System */

Putting just the one CMSIS header but not the other in the -isystem search path instead of the -iquote search path is, obviously, crazed. I think they correctly belong in the -iquote search path, and why change from the past?

Please replace #include <core_cm...h> with #include "core_cm...h" everywhere that it got messed up.

It looks like stm32cube programmer does not erase proper page 12/erases non existent page 8 in some corner case of dual bank

I'm having a problem with STM32CubeProgrammer and a 1MB STM32F767ZG configured in dual bank mode. On the left, I tried to flash a 520k bin to the device, over the top of previous firmware.

Expected behavior: erase sectors 0-7, 12, then write 520K bytes starting at address 0x08000000.

Actual behavior: erases sectors 0-8, then write 520K bytes starting at address 0x08000000.

Since it tries to erase the non-existent sector 8, sector 12 (the actual sector at 0x08080000) doesn't get erased and as such the contents of sector 12 get corrupted by the multiple writes without an erase.

See screenshot below: stm32cubeprogrammer tries to erase sector 8 at 0x0808 0000, but in dual bank mode, there is no sector 8!

See https://community.st.com/s/question/0D53W00001EEBXXSA5/stm32cubeprogrammer-incorrectly-erases-on-dual-bank-1mb-stm32f7

This is a duplicate of STMicroelectronics/x-cube-freertos#1 as I am not sure who should look into this...

Board: NUCLEO-U575ZI-Q
IDE: STM32CubeIDE Version: 1.13.1
Problem:

FreeRTOS examples are looking for "X-CUBE-FREERTOS_V1.1.0" which is nowhere to be found...

It can't be installed from anywhere and I can't create the project because it's missing.