Underclocking a STM32L496RGT3

[DCarr.1]

Hello all

I have a custom STM32L496RGT3 based board which I've configure to run at 64MHz off the HSI using CubeIDE:

void SystemClock_Config(void)
{
  RCC_OscInitTypeDef RCC_OscInitStruct = {0};
  RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
 
  /** Configure the main internal regulator output voltage
  */
  if (HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1) != HAL_OK)
  {
    Error_Handler();
  }
 
  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
  RCC_OscInitStruct.HSIState = RCC_HSI_ON;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
  RCC_OscInitStruct.PLL.PLLM = 1;
  RCC_OscInitStruct.PLL.PLLN = 8;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
  RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    Error_Handler();
  }
 
  /** Initializes the CPU, AHB and APB buses clocks
  */
  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
 
  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != HAL_OK)
  {
    Error_Handler();
  }
}

I'm getting some very strange behaviour though: on some boards my firmware runs fine, on others it fails quite early - usually in some banal non-pointer related code (there's actually no pointers or arrays anywhere in the code) - jumping off outside the program to address 0x1fff093e. I get the get the same behaviour running from the debugger, but not if I single step through the code.

I was wondering if there's any special flash latency - or anything else - set up required?

[TDK]

You can increase flash latency to see if that fixes it. Doubt it will.

When it's outside of program code, what does the call stack look like?

Sounds like a hardware issue. Is VDD stable? VCAP sufficient and stable? Can you monitor NRST line to see if issue corresponds to an NRST pulse?

[DCarr.1]

I just tracked the problem down.

Running on a 1,2V lab power supply everything's fine. It turns out that some of the batteries are a little bit border-line in terms of charge, and it's only those ones that fail.

The symptoms seem a little strange, but I'm putting the whole thing down to a weedy power supply.

[Tesla DeLorean]

Make sure your design pulls BOOT0 LOW

That SCB->VTOR maps to your code base in FLASH

After programming flash, power cycle the board

[Tesla DeLorean]

It will go into the ROM if the state of BOOT0 is indeterminate at reset, ie looks to float high rather than low, with a sketchy supply, or one rising slowly.