CCG3 I2C bootloader boot delay

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

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

cross mob
MaGa_3860551
Level 1
Level 1
Welcome!

I am using the CCG3 CYPD3125 with a firmware based on the notebook example on SDK v3.2.1. There is a long boot delay, about 1 second, for the bootloader to jump to the application firmware. This is causing me some problems in the way my firmware works.

I have opened the I2C bootloader project and I found that it has a wait timeout before loading the application firmware. The timeout is set by the function boot_set_wait_timeout, in boot.c. This function seems to always return a 1 second delay, from the following line, if the boot_app_id is not a special value:

gl_boot_wait_delay = GET_MAX (CCG_BL_WAIT_MAXIMUM, GET_MIN (CCG_BL_WAIT_MINUMUM, md_p->boot_app_id));

The wait delay is always CCG_BL_WAIT_MAXIMUM, therefore 1000ms. This was probably not the intention. GET_MAX and GET_MIN seems to be inverted.

I was able to bypass this line by setting the boot_app_id to CCG_FWMETA_APPID_WAIT_DEF (0xFFFF), which use the default delay of 50ms. This is done by setting the Application ID of the bootloadable component in the application firmware.

I could also set the boot_app_id value to CCG_FWMETA_APPID_WAIT_0 to eliminate the boot delay completely, but with a delay of 0, it seems to skip bootloader flash access boundaries protection.

Is this method valid to reduce the boot delay of the application firmware?

0 Likes
1 Solution
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hi ,

The boot wait delay have two defines:

----------------------------------------------------------------

/**

*  @brief FW metadata application ID value requesting default boot-wait window.

*/

#define CCG_FWMETA_APPID_WAIT_DEF                       (0xFFFFu)

/**

*  @brief FW metadata application ID value requesting a zero boot-wait window.

*/

#define CCG_FWMETA_APPID_WAIT_0                         (0x4359)

----------------------------------------------------------------

>> If you think 1s is too long, below ways to configure the firmware instead of comment out the gl_boot_wait_delay. Change the Application ID to 0x4359, you will got a zero boot-wait window.

pastedImage_0.png

Best Regards,

Lisa

View solution in original post

0 Likes
5 Replies
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hi ,

The boot wait delay have two defines:

----------------------------------------------------------------

/**

*  @brief FW metadata application ID value requesting default boot-wait window.

*/

#define CCG_FWMETA_APPID_WAIT_DEF                       (0xFFFFu)

/**

*  @brief FW metadata application ID value requesting a zero boot-wait window.

*/

#define CCG_FWMETA_APPID_WAIT_0                         (0x4359)

----------------------------------------------------------------

>> If you think 1s is too long, below ways to configure the firmware instead of comment out the gl_boot_wait_delay. Change the Application ID to 0x4359, you will got a zero boot-wait window.

pastedImage_0.png

Best Regards,

Lisa

0 Likes

Hi,

Thanks for you answer. So using one of the two boot delay defines is a valid workaround to reduce the boot delay.

Is there a plan for Cypress to fix this min/max bug in a future bootloader version, or should I consider that all these chips will have this behavior?

0 Likes

Hi ,

This is not bug of bootloader firmware, it is configuration of boot wait. Minimum tBootWait value is 10 ms and the maximum value is 200 ms.

Best Regards,

Lisa

0 Likes

Hi,

I understand the principle of configuring the boot wait, but the way it is implemented, it doesn't work. It always returns 1000ms, except for the two special defined values. And this is what I observe with a CYPD3125.

But maybe we're not looking exactly at the same code, because the minimum value I see is 20ms and the maximum value is 1000ms (not 10ms and 200ms). This is also the behavior that I see with a CYPD3125 chip, with 1000ms of delay. Could it be already fixed in a newer version?

Anyway, the workaround of using one of the two defines still works well.

0 Likes

Hi ,

I am using latest SDK. you could download take a look. SDK: http://www.cypress.com/documentation/software-and-drivers/ez-pd-ccgx-power-software-development-kit?...

Best Regards,

Lisa

0 Likes