Hi I have made a header board for STM32L152VD after every restart it takes few seconds for the board to start running. I use HSI clock. what do you think the problem is?
I think you should provide a bit more information.
How do you measure the startup time of your system. Did you set a breakpoint to the main function?
How do you restart your system?
I was not interested to know an exact startup time, but when I saw that my LCD starts to display with a delay of 2,3 or some times 4 seconds, I got to ask for your help to find the problem. I used the same program to run on STM32L152RC discovery board but I had no problem. No I did not use a breakpoint to the main function, if it helps please let me know what should I do next. I restart the system by shutting off and on the main power to the board.
You should evaluate how long NRST is held low, and how quickly the supplies rise.
The walk through the code looking for loops waiting for hardware to come ready, or introduce delays while programming/configuring.
Turn off "run to main", in fact ideally benchmark this without a debugger using a scope or logic analyzer.
Evaluate what code you have in SystemInit() bringing the clocks and hardware up. You could use GPIO pins to waypoint your progress through the code.
Consider profiling the code so you understand where it's spending it's time.
Yet I have not been able to overcome this problem. I have written a simple code to light an LED on GPIOA Pin3 When my STM32L152VD starts to run after power on, the LED starts flashing rapidly for few seconds (between 2 to 10 seconds) then LED becomes steadily on. in scope I see spikes in GPIOA Pin3 like noise. NRST is high during LED flashing. when running debug it alarms: cannot access target shutting down debug session.
Yes, debugging hardware is unlikely to transition a power down of the target.
You could check DBGMCU setting with respect to debugging and powering.
Perhaps you can ask more senior staff or professor/supervisor for assistance?
Really have no idea here what code you're running, or why it would power down after several seconds. If active/dynamic analysis isn't helping, perhaps you can do some more through static analysis of the code, and the startup process.
If you leave main() or exit()/abort(), expect the system to collapse into failure.
-> after power on, the LED starts flashing rapidly for few seconds (between 2 to 10 seconds) then LED becomes steadily on.
I encountered similar problem before.
The LCD of our device shares the same pins with a FT240X USB Chip, our device has a Lithium battery and a USB charging circuit. I encountered similar problem as you, so I discuss this problem with my hardware colleague, he did a full hardware analysis, and told me that this hardware needs a few seconds to become stable after power on. Since hardware can't be modified, he asked me to do a Sleep_Mode_IO_Config() immediately after power on, then wait for a while, then start to do the Runtime_IO_Config() and the real work. After this software modification, the problem doesn't disappear, but under our control.
Sleep_Mode_IO_Config(): He checked and decided each GPIO pins should be configured as In or Out, if it is an output pin, it should be high or low.
int main(void) { int i; static uint8_t Wait_PC_Connect = 1; LPC_SYSCON->PDRUNCFG |= (1u<<3); /* Set BOD Power-Down bit */ GPIO_OutInit(); Enable_Timer32B0(); Sleep_Mode_IO_Config(); delay_in_ms(50); GPIOSetValue( LPC_GPIO0, 7, 1 ); // En_OP_Power - ON Blink_Delay(8); Runtime_IO_Config(); ADC_Init(); SSP_Init(); I2C_Init( LPC_I2C, 400000 ); UART_Init(115200); delay_in_ms(10); LCD_Init(); delay_in_ms(10); GPIOSetValue( LPC_GPIO2, 10, 1 ); // LCD_BKL - ON
After this software modification, the few seconds (between 2 to 10 seconds) becomes a fixed number, let's say at most 5 seconds.
Dear John Thanks for your advise. I found that my problem is from the firmware since I tried with earlier versions of the firmware and modified it to new version. Now this problem has disappeared. I am trying to find out what are the differences that has made this problem.
Hamed Adldoost Posted 29-Jun-2015 16:30 GMT I used the same program to run on STM32L152RC discovery board but I had no problem.
So, it was not the same program?