Psoc6 bootup timing

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Pava_1191361
Level 3
Level 3
First like received First like given Welcome!

According to Application note AN73617 https://www.cypress.com/documentation/application-notes/an73617-psoc-designer-boot-process-reset-mai...

There are 4 times involved in the startup of the processor:

CypressT1-T4-boot.PNG

When measuring signals on the CYCKIT-62 BLE developer kit, I got the following result:

pastedImage_2.png

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.

Questions:

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)?

0 Likes
1 Solution
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Pava_1191361

There is a weak function, Cy_OnResetUser, that you can override and provide your custom logic required for the high speed tasks. Note that when this API is executed, many system components are not initialized, including clocks.

I was able to execute a code in this space in the CM0+ core within 19 ms of system start.

pastedImage_0.png

The Red waveform indicates XRES and the blue line indicates a GPIO that was toggled in the Cy_OnResetUser API.

Note that for a normal application, there are boot codes that run in this 19ms and it is not possible to bypass that

Best regards,
Hari

View solution in original post

0 Likes
6 Replies
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Pava_1191361

Can you please clarify as to what the waveform is? Is this the waveform while the device is being programmed?

What is the cause for the drop in Vprocessor (Unstable power or unknown)?

It is required to maintain a stable power of for the kit to function and the CPU to start.

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.

Is the Kitprog used to program during this time? Was any activity going on in the kitprog while the measurements were taken for the XRES to occur?

The Appnote is still valid for PSoC 6. you can also refer this KBA: PSoC 6 Boot Sequence

Please note that PSoC 6 is a dual core CPU, so there will be a further delay for the CM4 applications to start since CM4 must be enabled by CM0's main application

Thanks,
Hari

0 Likes

The processor is programmed with an ADC and an output PIN P13_7, but the wave does NOT show a programming cycle, it shows the start up (cold boot) of the (pre-programmed) processor on the BLE developer board.

The power is provided through the USB connector, so it shows the moment it is plugged in (it does show a small in rush current, visible as the little dot as the beginning of the red signal ramp).

Vprocessor shows the Voltage the CPU receives, which depends on the power supply of the developer board. No kitprog activity is performed. Note that PIN13_7 is driven from CM4 main.

0 Likes
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi Pava_1191361​,

This does not give us information on the reason for XRES being triggered. Is this done manually to test the XRES performance compared to power on reset? What is the cause of XRES being pulled low for 200 ms after the initial start?

Also, I see you are monitoring the voltage for J8. However, J8 is supposed to be used for current measurement. Please monitor the current using J8, making sure that the resistance in the path is minimum. You can use the VCCD test point of the kit to monitor the core voltage.

There are also brown out detection circuit within the controller that resets the chip if the power supply is not stable. So, please make sure that during these tests, the power supplied to the kit is stable.

Thanks,
Hari

0 Likes

I'm afraid I can't answer the XRES question. The measurement is performed by simply plugging the (through the docking station powered) USB cable into the developer board. That USB supply is quite stable. 

From the analog signal it does not seem that XRES is pulled low: It follows the same pattern as the Vprocessor  signal: Initially it is pulled high, but after some time is seems to be released, after which it slowly discharges. That reset goes low (in the Logic Analyzer output) is just because eventually it falls below the logical threshold value. It does impact Vprocessor: the moment XRES is low, the processor stops working (= decreased load) and Vprocessor degrades less rapidly.

The Jumper J8 is in place. It's just to indicate where the Voltage probe is placed.

The objective is to measure the cold boot timing, which means the amount of time the processor starts to draw current. I will try to repeat the measurement  using VCCD (although a test point is less suitable to attach a mini grabber), but really the focus must be on the output pin P13_7. As it turns out, cold boot (or reset induced by pressing the reset button on the board) results in a consistent (approx 21ms) delay time (measured from the time reset is high) until there's user program control (in main) over the output pin.

Is there a way to shorten this time, or is this delay set by the manufacturer? From the documentation this seems to be caused by T2 (512 ILO clocks (max 100ms), as all other times are in the low ms range.

Cold boot (and reset times) are critical as I have an application where the CPU must timely control a regulator. Losing control (reset/ cold boot/other) for more than 5ms means that other hardware needs to be used in case of such events, which is highly undesirable.

What can I do to shorten that time? Would and external Xtal be a solution?

Is there another way to gain control rapidly (perhaps at low speed through one core) while the rest of the system gets "up to speed"?

0 Likes
Hari
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Pava_1191361

There is a weak function, Cy_OnResetUser, that you can override and provide your custom logic required for the high speed tasks. Note that when this API is executed, many system components are not initialized, including clocks.

I was able to execute a code in this space in the CM0+ core within 19 ms of system start.

pastedImage_0.png

The Red waveform indicates XRES and the blue line indicates a GPIO that was toggled in the Cy_OnResetUser API.

Note that for a normal application, there are boot codes that run in this 19ms and it is not possible to bypass that

Best regards,
Hari

0 Likes

This means at least 19ms of uncontrolled behavior of the MCU control pins in case a cold boot (or reset) occurs. Although that is perhaps suitable for most applications, in my case that is not fast enough. I believe that keeping the device in deep sleep and waking up from that mitigate some of the situations, but that includes adding a supercap or battery to the design.

I would have preferred to be power less and boot-up/reset quickly (Jumpstart) rather than being powered all the time, with the chance of running out of battery power... 

Thanks

0 Likes