Stm32L443 stable code loading problem

[oguzhansenol]

 

I’m using the STM32L443 in one of my products, and currently, there are around 2,500 units deployed in the field. I’ve been experiencing issues that I believe are related to the firmware programming process during production.

 

The product includes a seven-segment LCD. After programming the firmware and running tests, I noticed that some characters do not display correctly in certain menu screens. I’m confident this is not a hardware issue. Interestingly, when I reflash the firmware on the same board, everything starts working properly — the display shows the correct characters.

 

These are just the visible symptoms. I’ve also observed cases where the firmware seems to get stuck in a specific scenario. For example, there’s a routine that runs every 5 minutes. On the third iteration, the system hangs. Even after a power cycle, it always gets stuck at the same point. However, if I reflash the firmware, the issue disappears.

 

This makes me suspect that the firmware might not be properly programmed during the initial flashing in production. I’m using STM32CubeProgrammer with an ST-Link V2 to load the firmware, and I have the verify options enabled. After flashing, I also lock the code (read-out protection).

 

That said, I’m now unsure whether the firmware was correctly programmed on all units during production.

[Andrew Neil]

The reflashing is almost certainly a coincidence - far more likely a subtle bug - or bugs - in the code.

 

---

@oguzhansenol wrote:

For example, there’s a routine that runs every 5 minutes. On the third iteration, the system hangs. Even after a power cycle, it always gets stuck at the same point. .

---

So have you tried attaching the debugger in this state to see where it's stuck?

https://community.st.com/t5/stm32-mcus-embedded-software/processor-stuck-if-i-run-code-without-debugger/m-p/802267/highlight/true#M63401

 

Add instrumentation to your code so that you can see what's happening; eg, UART output.

Be sure that any error handlers - eg, Hard Fault Handler - give a clear indication when they're hit, and make diagnostic info available.

 

---

@oguzhansenol wrote:

The product includes a seven-segment LCD. After programming the firmware and running tests, I noticed that some characters do not display correctly in certain menu screens.

---

Have you checked the interface with an oscilloscope and/or logic analyser?

Is there noise?

Are the levels correct?

Is the timing correct?

etc ... ?

[oguzhansenol]

Shouldn't we see that the code is stuck somewhere in the code and all of them? Additionally, as I mentioned, I can see that some characters on the LCD aren't working. I even log the number of times the device has been activated. Deleting everything and reinstalling it fixes it, and the device that doesn't work displays a 0. Sometimes, when we reinstall it, it displays a -1.

[Andrew Neil]

You've marked my post as The Solution, but you don't seem to think that the issue is solved?

Instructions to un-mark it here.

 

---

@oguzhansenol wrote:

Shouldn't we see that the code is stuck somewhere in the code and all of them?

---

That's why I said a subtle bug!

Could be multiple (subtle) bugs, so the symptoms only manifest when they all happen to align...

 

---

@oguzhansenol wrote:

the LCD ... displays a -1.

---

That looks more like LEDs ?

---

@oguzhansenol wrote:

I even log the number of times the device has been activated.

---

How, exactly, do you do that?

[mbarg.1]

Move to latest version and make sure you do flash ALL the memory, not just the code.