You are here

Start up delay issue | Cypress Semiconductor

Start up delay issue

Summary: 6 Replies, Latest post by maustin_1409416 on 29 Sep 2016 04:54 PM PDT
Verified Answers: 2
Last post
Log in to post new comments.
maustin_1409416's picture
User
17 posts

OK, I'm hoping someone can help me resolve this, because its driving me nuts!!

Short story is I've had some problems with some hardware I designed using a PSoC4 BLE chip, and the problem stems from the start up delay from when the chip first gets a clean 3.3V supply and when things start to kick off in software.  There seems to be a 500msec delay between these two events, which is causing issues with my hardware operation.

To try to get to the bottom of why this is, I tried paring the code right back.  Still seeing the delay

Then I wrote a very simple pin-toggling program to eliminate everything else - still seeing the delay.

I then programmed one of the Cypress BLE modules with my code to eliminate my hardware as being the issue - still seeing the delay!

Arrgggghhhhhhhh!!

I've attached my code here, in the hope someone can look at it and go "oh, you're doing this wrong - that's why you've got the 500msec delay at start up".  I've also included a screen dump from my scope showing the 3.3V rail starting up (yellow trace) and my pin toggle kicking into action (blue trace) showing the 500msec delay I'm referring to.

The weird thing is I have some other code that drives some additional hardware, and this isn't showing the issue with the software I developed for that.  However, if I load up the simple pin toggle code, it starts showing the 500msec delay, so there is something weird going on in my software set up that I can't seem to get to the bottom of.

I've tried updating PSoC Creator to the latest version, and updating the firmware on my development kit, but this hasn't improved the situation at all :-(

Anyone got any ideas?

Anjana Muralidharan's picture
Cypress Employee
116 posts

Hi,

The start up delay of 500 ms is because you are using WCO for LFCLK. See .cydwr -> clocks -> LFCLK.

The start up time of WCO is 500ms. If you want to reduce it, you can try changing the LFCLK to ILO.

But if in your application you need to include low power code, you have to use WCO. In that case you can't reduce this start up time.

Thanks,

Anjana

user_1377889's picture
User
10428 posts

Isn't there a chance to start the WCO manually (or rather: per program)?

 

Bob

jrow's picture
Cypress Employee
123 posts

This delay is in the auto-generated code in cyfitter_cfg.c, usually around line 192:

	/* Start the WCO */
	CySysClkWcoStart();
	CyDelayCycles(12000000u); /* WCO may take up to 500ms to start */
	(void)CySysClkWcoSetPowerMode(CY_SYS_CLK_WCO_LPM);    /* Switch to the low power mode */

 

To eliminate the boot delay, you can remove the CyDelayCycles() call and move the CySysClkWcoSetPowerMode() call to somewhere else in your application where it is able to execute in a non-blocking way after at least 500ms have elapsed. For example, you could use a TCPWM timer or the WDT to generate a GlobalSignal interrupt after half a second. You do still need to switch the WCO to low-power mode in order to take advantage of the best current consumption.

Also, note that any modifications to the project schematic or performing a clean/build cycle will re-generate the original code in cyfitter_cfg.c, so you'll have to re-apply the modifications. I recommend making a separate copy of the modified version and keeping it handy so you can overwrite it easily when needed.

maustin_1409416's picture
User
17 posts

Thanks everyone - nice to finally understand what was going on!

The red herring for me was the fact that the code I had for my other piece of hardware, which was pretty similar to the one that was giving me trouble, didn't have this 500msec delay.  I just checked out the cyfitter_cfg.c file that is generated when I build that code and it doesn't seem to insert the CyDelayCycles(12000000u); code in - it just has:

/* Start the WCO */
    CySysClkWcoStart();
    (void)CySysClkWcoSetPowerMode(CY_SYS_CLK_WCO_LPM);    /* Switch to the low power mode */

So, not sure why my original code doesn't insert this delay, whilst every program I create from now that uses the WCO does!

I made the suggested changes to cyfitter_cfg.c in my Simple_Pin_Toggle project and it now boots up in about 10msec :-)  It would be nice, but not totally necessary, to reduce this to < 5msec.  Anyone know what else I need to do to speed things up at first turn on?

Cheers,

Mike

user_1377889's picture
User
10428 posts

 It would be nice, but not totally necessary, to reduce this to < 5msec  What is the need for speed? When the GPIO pins are externally set to a save level (resistors) it doesn't matter if the operator takes the early train or the next one.

 

Bob

maustin_1409416's picture
User
17 posts

Actually, in my case its pretty critical.  My hardware has a bootstrap resistor that allows my bulk capacitor on the 12V rail to charge up to a level that kicks my 3.3V regulator into gear, but with a pretty low charge rate (it takes seconds).  Once the 3.3V rail is good, and my chip starts up, I very quickly (i.e. < 10msec) need to get my PWM running and driving an output so I can switch the bootstrap resistor out of circuit and keep the 12V rail charged up.

So, when the chip sat around admiring the view for 500msec, my hardware just cycled on and off, as once the chip started, my 12V rail sagged down to the point that the 3.3V regulator switched off due to insufficient voltage input in about 20-30msec.

I had this all working on my previous hardware and software, which doesn't insert the 500msec delay (no idea why - must be a new "feature" of the compiler".  So, I just duplicated hardware that worked, only to find that everytime I created some new code there was a 500msec thumb twiddling session added in at the start.  Obviously, with 250 boards stock piled from pre-production, I'm not in a position to just change the hardware.

Anyway, I can work with the 10msec start up delay, but it does limit my minimum AC input voltage, hence why I was keen to reduce the start up delay.

Log in to post new comments.