STM32U585 Systick and SVC 2 interrupts stop working on some devices

[h p]

Hello,

We are using STM32U585QII6QTR in our device that is powered via USB and batteries. We observe that some devices do not startup anymore after some time of use. It is unclear which impact causes this. Everything that can be measured outside the MCU looks as expected.
Debugging the device shows that everything is working normally, for example the bootloader checks successfully that a valid firmware is flashed by using HAL_HASHEx_SHA256_Start/Finish.
However, the Systick is not triggered and GetTick remains 0, but SysTick->VAL is counting.
Similartly, when starting the FreeRTOS Scheduler the device crashes when the SVC 2 instruction is called. The SVCHandler interrupt is not called. So, it looks like interrupts are not activated anymore.

I created a no-RTOS project with CubeMX and checked directly after HAL_Init if the Systick is triggered. On a “damaged” device there is no SysTick triggered after HAL_Init whereas on a good device it is as expected.

I attached a dump of important registers of a good and bad device.

I am looking for advice on how to find the root cause.

Many thanks for any help 

hp

[Bob S]

>  bootloader checks successfully that a valid firmware is flashed by using HAL_HASHEx_SHA256_Start/Finish

This is your custom bootloader?

Check all of your power supply connections and bypassing, NRST circuit, etc.  Can’t be of much specific help without seeing the relevant portions of the schematic.

When they fail, are they USB powered or battery powered?  What is the battery voltage?  Check power-on reset with a scope on the NRST and power rails to see if they sag.

 

[h p]

Hello, 

Yes, this our own bootloader that uses HAL_HASHEx_SHA256_Start/Finish to calculate the checksum of the FW.

I just mentioned this to make clear that most parts of the MCU is working as expected. It’s just the Systick that does not trigger even in the most basic usage example (CubeMX generated project, waiting on Systick directly after HAL_Init). Also SCV 2 instruction does not work. Instead if landng in SVC IRQ Handler it crashes badly (Debugger disconnects).  It did not check if other interrupts are working

This is why it looks like the MCU is damaged. I think it is highly unlikely that the MCU would behave like this if just some external circuitry would be damaged.

I have attached the Power Management Schematics of the device.

We checked most of the supply voltage during all use cases. They allare within the range.
We cannot tell which use case causes the damage. But when the damage occurred it is permanent. 

 

I would be important to know if the circuitry for assuring the power requirements are sufficient. 

 

Could there be any power states that prevent the Systick and other interrupts from triggering? Could the MCU fall into such a power state for some reason?

Best regards,
hp

[Bob S]

Going back to your first post - are you sure the “good” and “bad” names are on the correct files?  The “good” file looks like if got a hard fault reading the vector table (SHCSR, HFSR).

What is “after some time of use”?  Minutes? Hours? Days?  Is this an existing production that just started exhibiting this issue, or a new product?  Are these boards all from the same build?  Are the U585’s all from the same manufacturing lot?

Most STM32s do not need an external pull-up on NRST, just a cap to GND.  I don’t know specifically about the U585

[h p]

I am sorry, yes, the files are wrongly named. I repeated the test and added the register status again and summarized the differences of the register values in the table below. Yes, the HardFault is active, but the execution stays in the main loop. 
 

Register	Good	Bad
SCB ICSR	0	0x800	Bad: RETTOBASE is 1: There are no active exceptions, or the currently executing exception is the only active exception.
SCB SHCSR	0	0x4	Bad: HARDFAULTACT
SCB HFSR	0	0x2	Bad: VECTTBL is 1: HardFault on vector table read.
RCC ICSCR1	0x44084a2e	0x44059d26	Different MSICLAL value
RCC ICSCR3	0x100913	0x100912	Almost equal HSICAL vale
RCC CRRCR	0x10e	0xf2	Different factory-programmed HSI48 calibration trim value
RCC BDCR	0x8103	0x8008203	Bad: Reserved Bit 23 is set RTCSEL: LSI oscillator clock selected, whereas good has LSE oscillator clock selected
SysTick  CTRL	0x10007	0x7	Bad: COUNTFLAG not set
SysTick  VAL	0xf5a	0xd98	Differnt count values

 

PRIMASK, FAULTMASK and BASEPI are 0 in both good and bad cases.

The memory browser of the Vector Table shows identical content on both cases. Output attached.

The tests are performed with a CubeMX generated project. It was extended as follows to check if the SysTick is triggered. In the God case the second while loop is reached. In the bad case it stays in the first loop.

int main(void)
{
  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  while(1)
  {
	  uint32_t tick = HAL_GetTick();
	  if ( 10 < tick )
		  break;
  }

  while(1);
  /* USER CODE END Init */

The product is about to be launched. Development on the U585 started 2 years ago. The problem occurred after production within the first hours, after they had initially worked. 2 other devices have been used over several months until the problem occurred. So, it happens on devices of different production cycles. It is likely the same lot of U585, as not many prototypes have been made.

Under the assumption that the U585 is not damaged, I will check if any of the persistent registers have a different configuration that is kept over power cycles.

[h p]

I checked the FLASH registers and the Boot-Address was 0 instead 0x08000000. After setting it back it worked as expected.

During the Update of the Bootloader the Boot-Address is set to the Adress of the Main Firmware. After the successful Update of the Bootloader it is set back to 0x08000000. I have to check what caused it to set to 0.

Thank you very much for your help.