2024-11-19 02:46 AM
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;
}
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.
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.
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:
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
Solved! Go to Solution.
2024-11-22 09:39 AM
I'm just describing what I see in the disasm. I am not ARM/Keil so can't explain their decisions... ;)
I'm not sure the described phenomenon can be explained without having deep access into the 'C0's innards. I was asking for the chip revision because of the "first SRAM access may fail" erratum, although the erratum is not clear about what constitutes the circumstances of failure and what exactly are its consequences. But regardless of that erratum, one of the mechanisms I can envisage is, that after poweron reset a hardware process runs, which performs some operation across the whole SRAM array, and thus the first SRAM access is delayed by some time - well say it precalculates the parity, one word per cycle, 6kBytes at 12MHz would take around 130us...
The difference between the "with gpio" and "without gpio" is, that in the former the first access to RAM is the push which happens *before* the observed pin is pulled low, i.e. the lengthy RAM operation happens before the pin is pulled low and thus the pulse has the expected length; whereas in the latter (without gpio) the first access to RAM is the first zero write for the initialization, which is *after* the pin is pulled low, thus prolongs the observed pulse.
This is just a theory and could be proven or disproven by a carefully crafted test (possibly in asm), where one pin edge would be generated before the first access to SRAM, and another edge (either on the same or other pin) after that access. I don't have a 'C0 to experiment.
In any case, the total time between the moment when POR releases the processor and the moment when the observed pin is pulled high at beginning of main() should be roughly the same in both cases. This could be proven or disproven by powering the circuit from a source which can go from 0V to 3V quickly enough (in a few us).
JW
2024-11-19 02:55 AM
Confirm if GPIOB is linked to other peripherals (e.g., alternate functions or shared clocks) that might be influencing startup time.
2024-11-19 03:37 AM
According to datasheet of STM32C011x4/x6, GPIOB pin 7 could setup with various things by setting up alternate functions but that's not the case for the demo code above.
2024-11-19 03:54 AM
For me this looks like:
- During Voltage rise CPU starts to work
and then loops
- Watchdog triggers reset
- New Startup sequence
What behaviour do you expect?
2024-11-19 04:08 AM
@Uwe Bonnes I expect the time takes to startup from power up would not be affected by setting GPIOB pin direction. Or if there is an explanation, as I asked in the original post, I'm all ears.
2024-11-19 04:54 AM
Sorry, I did not read carefully enough. As I read the scope picture, the long first period happens well below 2.0 Volt. HSI48 is only characterize from 2.0 to 3.6 Volt. I expect HSI48 to be much slower below 2.0 Volt.
Perhaps route HSI tp MCO and measure HSI frequency at voltages that low.
2024-11-19 05:40 AM - edited 2024-11-19 05:41 AM
Which chip revision?
Show disasm of the program for both cases.
JW
2024-11-20 12:30 AM
Hello @ah2 ,
Is it possible to also probe the NRESET pin (If there is a capacitor on the NRESET pin please remove it) to see when it is released by the MCU after the Power On Reset ?
Best regards,
Simon
2024-11-20 01:26 AM
@Uwe Bonnes That's actually how we initially discovered the behaviour. We wanted to measure whether HSI has become stable but the test point of MCO was not available so we used PB7 with alternate function setting to TIM16_CH1, PSC being 0, ARR bring 120, and CCR1 being 60 so we expected to see 99,174 Hz.
By changing the PB7 direction, we are also seeing the startup time from power up accelerated to be the same as the rest of IWDG reset.
Together with the frequency measurement, attached scope pictures below.
1st reset at power up
2nd reset at power up
99kHz
2024-11-20 01:31 AM
Chip revision is STM32C011F4U6TR, not sure if there is more I should share. Please let me know.
I generated the disasm with the following command and attached for both cases.
fromelf.exe --text -a -c --interleave=source --output=without_gpio_asm.txt .\test.axf