STM32U585 rev W don't work as rev X

[Aurelien1]

Hello,

We have a product that works well with the STM32U585AIIXQ rev X.

In the latest batch, some boards have the STM32U585AIIXQ rev W, and the application no longer works (the power consumption is as expected).

The application starts by transmitting some data over UART/I2C/SPI and refreshing the screen using TouchGFX before stopping.

When the application halts, I can no longer access the MCU using ST-LINK in SWD mode (tested in both DEBUG and HOT PLUG modes).

The application is based on ThreadX and utilizes analog functions, UART, I2C, SPI, DMA, USB, TouchGFX, GPIO, and PWM.

I read the latest errata, but I didn't find anything that could explain the problem.

I checked the electrical parts (power rails and reset) and observed nothing unexpected or unusual.

The MCU is mounted on a dedicated board (all the other boards in the product are working as expected).

When the code is compiled with -O3, it fails, but with -Og it seems to work (for more than a day).

 

Does anyone at ST have more information about the internal differences within the chip between the two revisions that could explain this?

How is it possible that the SWD bus becomes disconnected when the failure occurs?

I cannot share the code.

Thanks for your help.

[mƎALLEm]

Hello,

All the revision differences are listed in the errata of the product.

A a part of screenshot:

 

[TDK]

Consider the possibility that the revision is not at fault here.

Debug the problem normally, observe what "doesn't work", investigate it, understand why.

> When the code is compiled with -O3, it fails, but with -Og it seems to work (for more than a day).

Generally indicates a code bug, and it might be hard to find.

[Aurelien1]

I agree with you about the code bug.

What I can't explain is why the same binary works for the X revision but fails for the W revision (and disconnects the core from the SWD bus).

It is difficult to find what 'doesn't work,' as we can no longer access the SWD, and many events are environment-dependent. Therefore, we continue to investigate.