RCC_CR_PLLRDY not set depending on code size?

[Lab Guy]

Posted on April 27, 2018 at 15:43

I'm running into an issue where the program will time out on 

while(READ_BIT(RCC->CR, RCC_CR_PLLRDY) == RESET)

in stm32l4xx_hal_rcc.c:839 depending on how much code compiled in main.c.  The program will execute fine with minimal code, but adding code in main(), even code not yet executed, will cause the time out.

Code was generated using STM32CubeMX 4.25.0, STM32Cube V1.0.  IDE is System Workbench for STM32, fr.ac6.feature.ide version is 2.4.0.201801121207.  Target is Nucleo-L452RE-P.  Tested on multiple boards.

To reproduce:

1. Create a new project in STM32CubeMX
2. Use the board selector to select NUCLEO-L452RE-P
3. Yes to initialize peripherals to default mode
4. Reset PA6 and PA7
5. Enable QUADSPI, Bank1 with Quad SPI lines
6. Generate code, and import into System Workbench
7. In main.c, replace /* USER CODE BEGIN 3 */ ,   /* USER CODE END 3 */ with 

   /* USER CODE BEGIN 3 */

   QSPI_CommandTypeDef sCommand; uint8_t reg; volatile uint8_t err = 0;

   /* Read status register */

   sCommand.InstructionMode = QSPI_INSTRUCTION_1_LINE; sCommand.Instruction = 0x00; sCommand.AddressMode = QSPI_ADDRESS_NONE; sCommand.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE; sCommand.DataMode = QSPI_DATA_1_LINE; sCommand.DummyCycles = 0; sCommand.NbData = 1; sCommand.DdrMode = QSPI_DDR_MODE_DISABLE; sCommand.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY; sCommand.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;

   while (1) {

   if (HAL_QSPI_Command(&hqspi, &sCommand, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

   { err = 1; }

   reg = 0xAA;

   if (HAL_QSPI_Transmit(&hqspi, &reg, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) { err = 1; }

   reg = 0x55;

   if (HAL_QSPI_Transmit(&hqspi, &reg, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) { err = 1; }

   // reg = 0xBB;

   // if (HAL_QSPI_Transmit(&hqspi, &reg, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {// err = 1;// } } } /* USER CODE END 3 */
8. Add break point to main.c:120,  sCommand.InstructionMode   = QSPI_INSTRUCTION_1_LINE;

9. Add break point to stm32l4xx_hal_rcc.c:839, return HAL_TIMEOUT;

10. In Project Properties, set optimization level to none. (Project Properties->C/C++ Build->Settings ->MCU GCC Compiler->Optimization->Optimization Level: None)

11. In Project Properties, enable Parallel Build (Project Properties->C/C++ Build->Benavior: Enable parallel build (checked))

12. Debug the project, and let it run.  It will stop at the break point in main.

13. Stop the debugger, and uncomment :

    // reg = 0xBB;

    // if (HAL_QSPI_Transmit(&hqspi, &reg, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) {

    // err = 1;

    // }

    to

    reg = 0xBB;

    if (HAL_QSPI_Transmit(&hqspi, &reg, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != HAL_OK) { err = 1; }
14. Debug the project, and let it run.  It will stop at the break point in

    stm32l4xx_hal_rcc

    .c

The breakpoint in 

stm32l4xx_hal_rcc.c hits before the uncommented code even executes.  What is going on?

[Tesla DeLorean]

Posted on April 27, 2018 at 16:30

Does seem odd, would probably look at the .MAP, the RAM usage and .LST file of the code the processor is running. Look where it is putting the stack.

Generally here I get the USART/VCP running, along with the Hard Fault Handler, and I can instrument the code and see whats happening.

You perhaps want to dump the RCC registers, and track the execution without breakpoints. Instead of commenting out code put an 'if' around it for a variable that can be set either way.

Perhaps you can try a professional tool chain like Keil or IAR? Got a lot more confidence in the code generation, linker and debuggers there.

[Lab Guy]

Posted on May 22, 2018 at 15:14

Seems to be fixed in Cube 4.25.1 update.

[Tesla DeLorean]

Posted on May 22, 2018 at 17:34

They supposedly fixed a problem on the L4 with respect to the PLLM setting, but not sure it is size dependent.

Local variables can have random data from the stack.