cancel
Showing results for 
Search instead for 
Did you mean: 

Undocumented behaviour STM32C011F4U6TR

ah2
Associate III

Hi,

We notice the startup time from power up can be affected by setting one GPIOB pin to input. The startup time here refers to the time from SystemInit() until main(). Basically it contains scatterload and __rt_entry to my understanding.

Specifically, the sample code below, built with ARM Compiler 6.16 Tool, would demonstrate that

#define MEASURE_PIN 5 int main(void) { IO_SET_PIN(GPIOA, MEASURE_PIN, 1); // Enable IWDG IWDG->KR = 0xCCCC; // Enable write access IWDG->KR = 0x5555; // Set prescaler IWDG->PR = 0; // Set reload IWDG->RLR = 1; // Wait for the registers reload while (IWDG->SR) { } // refresh the watchdog. IWDG->KR = 0xAAAA; while(1); return 0; } void SystemInit(void) { // enable GPIOA clock RCC->IOPENR |= RCC_IOPENR_GPIOAEN | RCC_IOPENR_GPIOBEN; // set GPIOA pin5 to output IO_SET_PIN_DIR(GPIOA, MEASURE_PIN, 1); // set GPIOA pin5 to low IO_SET_PIN(GPIOA, MEASURE_PIN, 0); // Set GPIOB pin7 to input // GPIOB->MODER &= 0xffff3fff; }
View more

Basically GPIOA pin 5 is toggled to low and high for the time between SystemInit() and main() to be measured.

main() also has IWDG setup and ends with a while loop so that IWDG reset happens periodically since power up.

On the oscilloscope it looks like the screenshots below.

powerup_time_without_gpiob_input.png2nd_iwdg_reset_without_gpio.png

Respectively from the screenshots, it can be observed that the 1st startup(power up) takes 254 μs while the 2nd startup (IWDG reset) takes 132 μs.

Now if uncommenting this line GPIOB->MODER &= 0xffff3fff; and redo the measurement, we get the results below.

powerup_time_with_gpiob_input.png

We can see that having the GPIOB pin 7 set to input reduces the startup time from 254 μs to 132 μs and the rest startup remains taking the same time.

Could you please confirm the following:

  1. What causes the differences between 1st and 2nd startup?
  2. Why setting GPIOB ping 7 to input would affect the startup timing?

Just in case, this is how Reset_Handler looks like in our startup file. It is basically without any customization.

; Reset handler routine Reset_Handler PROC EXPORT Reset_Handler [WEAK] IMPORT __main IMPORT SystemInit LDR R0, =SystemInit BLX R0 LDR R0, =__main BX R0 ENDP

  Anta

30 REPLIES 30

> Push on the stack? Does SystemInit even need stack?

It's a normal C function.

While in this particular case the registers wouldn't need to be preserved, there's no guarantee that that is the case generally.

> Would marking the function as _Noreturn or __attribute__((noreturn)) help?

It's a normal C function which does return.

> I think we need to ask the engineers who designed the chip

Developers with the required knowledge are highly unlikely to turn up here. The OP may ask ST directly, but I wouldn't hold my breath.

> They should know what conditions trigger this behavior and perhaps how to avoid it.

Most probably power-on reset triggers it. Maybe RAM_PARITY_CHECK option bit is involved. I don't have a C0 to try and also I am not interested in this that much; OP may try to check this.

You can also try to write your program so that it won't touch RAM for quite some time (e.g. initialize clocks, peripherals meantime), if you really need every microsecond of powerup startup latency.  Note, that t RSTTEMPO = typ.270us max. 500us.

JW