According to Application note AN73617 https://www.cypress.com/documentation/application-notes/an73617-psoc-designer-boot-process-reset-main
There are 4 times involved in the startup of the processor:
When measuring signals on the CYCKIT-62 BLE developer kit, I got the following result:
P13_7 is a pin configured as an output, which is controlled by software: On main start, a startup signature is generated, to identify main has started. It is also set high during the execution of the ADC isr, which means it is able to identify when the fist sample (after boot up) is taken.
Reset is the reset pint status
VProcessor is measured on the BLE power monitor jumper J8.
On a cold boot Vprocessor (red line) rises and is stable for about 7..8ms. Then is trails off slowly to about half the supply Voltage. The reset pin actually follows the same behavior, but I have shown the digital interpretation here. Clear is that when reset goes low, the decline of Vprocessor is much slower, likely because the processor is halted.
Interesting is to see the behavior of output pin P13_7: After 11 ms of high it goes low for about the same time. Then the main start signature is identified (high) followed by the hardware initialization (ADC) and the triggering of the ADC ISR. after a short amount of samples, reset goes low and the processor stops executing.
Reset is kept low (probably by kitprog 3) for about 200ms, after which the power to the processor is raised (to 3.3V) and shortly after the reset follows. This time the output of P13_7 stays high until the main (and later the sampling) starts.
1. Output behavior of P13_7 is different on cold boot. Is that due to the fact that the power supply is not stable?
2. Does the timing specified in a the Application note still apply for the PSOC6 ?
3. Testing with different clock settings ( which should impact T3 and T4, but not T2) I estimate T2 to be around 21ms, which seems to occur after every reset. Keeping the device in reset is therefore not an option when fast response times are required. Would waking up from hibernate eliminate these 21ms and (potentially) allow faster startup-times (with responses within 10ms are required)?