Serial Numbering by Script

[MR87]

Hi,

recently in STM32CubeProgrammer was introduced the Serial Numbering feature, which is much appreciated.

However, it's limiting because the serial number is assigned manually, setting a starting value that is progressively incremented.

In a production site with multiple test stations, it becomes difficult to synchronize the various stations on the SN to be used.

Hence my request: it would be very useful if the Serial Numbering section were integrated with a "Script" field, in which the user can enter the filepath of a custom "C-style" script (or in the programming language of ST choice) whose return value is the SN to be programmed. The script (customizable by us) will provide the correct return value, based on the logic the end company wishes to use to assign the SN to its devices (e.g., databases, *.csv, etc.).

Hoping for a future update, I look forward to hearing from you.

Best regards,

Matteo

[Andrew Neil]

---

@MR87 wrote:

In a production site with multiple test stations,

---

Is CubeProgrammer really intended for such situations ?

[MR87]

Hi Andrew,

Thank you, that's a fair question! STM32CubeProgrammer may not have been designed for production in mind originally, but the introduction of the Serial Numbering feature itself tells a different story: ST clearly recognized that there is a production/manufacturing use case, otherwise why add it at all?

The problem is that the current implementation only covers the simplest scenario: a single station sequential numbering. The moment you scale to even two stations, the feature becomes nearly unusable without external coordination (which defeats its purpose).

My request doesn't ask for a full MES integration but just asks for a small, elegant extension: let the user provide a script that returns the SN. This keeps things simple for ST to implement, while giving production engineers the flexibility to plug in whatever backend logic they already have (a shared DB, a CSV, a REST call, etc.).

The feature already targets production use. My suggestion just makes it actually viable in real production environments.

[Pavel A.]

>  let the user provide a script that returns the SN.

This makes sense.

[Maxime_BELAVAL]

Hello Matteo, thank you for sharing this feature request.

Following up here as well, in line with my comment in the other discussion focused on making the automatic mode more flexible: https://community.st.com/t5/stm32cubeprogrammer-mcus/your-voice-matters-help-us-improve-stm32cubeprogrammer-usability/m-p/890881/highlight/true#M9999.

First, a quick reminder about the purpose of STM32CubeProgrammer: it is a development programming tool, not intended for production programming, as indicated in the license and detailed here: https://dev.st.com/stm32cube-docs/stm32cube-getting-started/1.1.1/en/markup/Ecosystem_Code_Programming/Ecosystem_Code_Programming.html#development-programming-and-production-programming.

For production use, STMicroelectronics recommends working with ST Partners or other specialized programming companies: https://www.st.com/content/st_com/en/partner/partner-program.html?country=country.

Regarding the automatic mode specifically, its original target is development scenarios (for example, integration and validation engineers working with several boards, from a few to several dozen) where it helps assign unique identifiers to targets in a sequential manner for tracking and reference purposes.

That said, we are aware that STM32CubeProgrammer is also used in production contexts, and we understand why requests such as yours arise.

I therefore echo Andrew’s and Pavel’s comments, which tie back to my initial question: how should the automatic mode evolve overall?

From your point of view, would it be more convenient to have:

• a single input file containing all programming settings, or
• multiple, more granular input files, each handling specific aspects (e.g. one for serial numbering, one for option bytes, one for pre- and post‑programming operations, etc.), with each of them being optional?

We are considering an improved “rendering” of the programming journey to make it easier and more efficient for you, our users. This will cover both manual programming (the first section) and the automatic programming (located below the manual programming). However, this enhancement is not planned for the short or medium term, which gives us the flexibility to collect all feedback without time pressure.

Wish you all a nice day,

Max

[MR87]

Hello Maxime,

thank you for your reply to this post.

In a production context, we typically rely on the CLI version, setting command-line parameters launched from our LabVIEW-based test program. However, for small batches or pre-production runs, it's easier to use the STM32CubeProgrammer. An automatic SN assignment system would also be useful here, especially to avoid human error.

From my point of view, would it be more convenient to have a single input file cointaining all programming settings (including the Serial Numbering script reference).

Having a sort of programming "project file" would allow to customize the programming process for a specific product. And in a production context, each product would have its own project file. In this way would also be useful for tracing the programming settings used for a specific product/batch or production version and for maintaining a backup of those settings.

Have a nice day,

Matteo

[Pavel A.]

@Maxime_BELAVAL 

> From your point of view, would it be more convenient to have:

The settings file is good for automation, it definitely can contain address and size of the serial number patch, if any.

But the numbers themselves of course should come from separate source, and this source is simpler to do as a process/script, to avoid dealing with position in a file. The first thing that comes to my mind is ascii string of hex bytes ("AABBCC..."), the max. length can be specified in the common settings.

Of course, ability to run user-specified programs can be exploited ...

In C++something like...  

#include <cstdio>
#include <array>

string get_raw_sn_string(const string user_cmd) {  
  std::string result;
  std::array<char, 256> buffer{};
  FILE* pf = popen(user_cmd, "r");
  if (pf && fgets(buffer.data(), buffer.size(), pf) != nullptr) {
    result = string(buffer.data()).trim();
  }
  pclose(pf);
  return result;
}

Or same with the Qt library:

#include <QProcess>
#include <QString>

QString get_raw_sn_string(Qstring cmd, Qstring arg) {
    QProcess proc;
    proc.start(cmd, {arg});
    proc.waitForFinished();
    QByteArray output = proc.readline();
    QString firstLine = QString::fromUtf8(output);
    return firstLine.trimmed();
}

( However, in our projects we don't use the CubeProgrammer CLI or GUI for production, and implement serial numbers in a different way )