PSoC62 disable DAP

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

cross mob
JeHu_3414236
Level 5
Level 5
10 likes received First like received

I want to disable the DAP to prevent debug access from the SWD port and I am using this COM API to change lifecyle to secure.  I am leaving all secureRestrict and deadRestrict settings as don't care from the example given in the API document.  Is this the correct method?  I cannot connect to the chip anymore with SWD after I run this.  Do I need to set any bytes to 1 for the secureRestrict also?

byte[] secureRestrict = new byte[16];

byte[] deadRestrict = new byte[16];

bool voltageVerification = false;

byte lifecycle = 4; //secure

            for (int i = 0; i < secureRestrict.Length; i++)

                secureRestrict = 0xFF;

            for (int i = 0; i < deadRestrict.Length; i++)

                deadRestrict = 0xFF;

            hr = pp.PSoC6_WriteProtection(lifecycle, secureRestrict, deadRestrict, voltageVerification, out strError);

Also, the COM API doesn't state how the 16 bytes map to the 2 bytes of SECURE_ACCESS_RESTRICT0 and SECURE_ACCESS_RESTRICT1.  Is this how the mapping works?

[0] = bit 0, SECURE_ACCESS_RESTRICT0

...

[7] = bit 7, SECURE_ACCESS_RESTRICT0

[8] = bit 0, SECURE_ACCESS_RESTRICT1

...

[15] = bit 7, SECURE_ACCESS_RESTRICT1

0 Likes
1 Solution

Hi JeHu_3414236,

Yes, even if you leave all the configurations from the example at its default state and enter secure mode, you will not be able to connect to your device. The procedure that you have followed is correct.

I thought you were programming the Secure Image project and then changing the lifecycle. I am sorry for the confusion. If you are just using the PPCOM APIs to write into the Secure Access Register with 0xFF value and then changing the lifecycle then the initial value, 0, will remain. Therefore, secureRestrict array needs to be filled with the appropriate security settings if only PPCOM APIs are used.

Please refer to  Section 12.1.3 EFUSE_DATA_SECURE_ACCESS_RESTRICT0 in the Technical Reference Manual to know about the default value of the SECURE ACCESS REGISTER

Hope this helps,

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B

View solution in original post

0 Likes
7 Replies
Rakshith
Moderator
Moderator
Moderator
250 likes received 1000 replies posted 750 replies posted

Hi JeHu_3414236​,

Yes, even if you leave all the configurations from the example at its default state and enter secure mode, you will not be able to connect to your device. The procedure that you have followed is correct.

To answer your second question, yes, each byte is mapped to 1 bit of the SECURE_ACCESS_RESTRICT0 and SECURE_ACCESS_RESTRICT1.

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

Thank you.  What is the purpose of the secureRestrict and deadRestrict settings if they are not used and only the lifecycle is used?  When it is in the secure state, what is the equivalent secureRestrict setting?  Does it behave like this or something else:

CM0_DISABLE=1

CM4_DISABLE=1

SYS_DISABLE=1

In the example where the settings are all 0xFF=don't care, it will keep the initial value of 0 which means nothing is disabled.

0 Likes

Hi JeHu_3414236,

Yes, even if you leave all the configurations from the example at its default state and enter secure mode, you will not be able to connect to your device. The procedure that you have followed is correct.

I thought you were programming the Secure Image project and then changing the lifecycle. I am sorry for the confusion. If you are just using the PPCOM APIs to write into the Secure Access Register with 0xFF value and then changing the lifecycle then the initial value, 0, will remain. Therefore, secureRestrict array needs to be filled with the appropriate security settings if only PPCOM APIs are used.

Please refer to  Section 12.1.3 EFUSE_DATA_SECURE_ACCESS_RESTRICT0 in the Technical Reference Manual to know about the default value of the SECURE ACCESS REGISTER

Hope this helps,

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B
0 Likes

The document says all default values are 0 which means full access to everything.  When I change to secure mode and leave all values as default, why am I not able to access anything over SWD?  It should behave the same as normal mode if all values are default.

Can I just set all bits to 1 for maximum protection?  Will this interfere with normal code execution like secure bootloading or writing to non-sflash flash areas?  Also, what is the feature "DirectExecute system call functionality"?  I don't see it described anywhere in the TRM or datasheet.  Is it safe to disable it?

0 Likes

Hi JeHu_3414236​,

When I change to secure mode and leave all values as default, why am I not able to access anything over SWD?  It should behave the same as normal mode if all values are default.

In NORMAL mode, the SWD pins are configured in flash boot. But in SECURE mode the SWD pins are not configured in flash boot and needs to be configured by the user.

Use the following code in your application to enable DAP -

/*******************************************************************************

* Function Name: Cy_FB_EnableDap

****************************************************************************//**

* Enable DAP by updating CPUSS->AP_CTL register.

*******************************************************************************/

void Cy_FB_EnableDap(void)

{

    uint32_t apCtl = REG32(CY_FB_CPUSS_AP_CTL_ADDR);

    apCtl |= (  CY_FB_AP_CTL_CM0_ENABLE_MASK | CY_FB_AP_CTL_CM4_ENABLE_MASK ) | CY_FB_AP_CTL_SYS_ENABLE_MASK;

    REG32(CY_FB_CPUSS_AP_CTL_ADDR) = apCtl;

}

/*******************************************************************************

* Function Name: ConfigureSWJ_NoAP

****************************************************************************//**

* This function Configures SWD and JTAG pins.

* Note, TRST pin is not configured and shall not be used.

*******************************************************************************/

static void ConfigureSWJ_NoAP(void)

{

    /* Pin number multiplied by a number of bits per drive mode in GPIO_PRT.CFG register */

    const uint32_t PRIMARY_SWDIO_PIN_POS  = 7UL * 4UL;

    const uint32_t PRIMARY_SWDCLK_PIN_POS = 6UL * 4UL;

    const uint32_t PRIMARY_TDI_PIN_POS    = 5UL * 4UL;

    const uint32_t PRIMARY_TDO_PIN_POS    = 4UL * 4UL;

    const uint32_t TCLK_DM = 0xBUL; /* input enabled=1, drive mode=3 */

    const uint32_t TMS_DM  = 0xAUL; /* input enabled=1, drive mode=2 */

    const uint32_t TDI_DM  = 0xAUL; /* input enabled=1, drive mode=2 */

    const uint32_t TDO_DM  = 0x6UL; /* input enabled=0, drive mode=6 */

    Cy_GPIO_SetHSIOM(GPIO_PRT6, 7UL, P6_7_CPUSS_SWJ_SWCLK_TCLK);

    Cy_GPIO_SetHSIOM(GPIO_PRT6, 6UL, P6_6_CPUSS_SWJ_SWDIO_TMS);

    Cy_GPIO_SetHSIOM(GPIO_PRT6, 5UL, P6_5_CPUSS_SWJ_SWDOE_TDI);

    Cy_GPIO_SetHSIOM(GPIO_PRT6, 4UL, P6_4_CPUSS_SWJ_SWO_TDO);

    GPIO_PRT6->CFG = (TCLK_DM << PRIMARY_SWDCLK_PIN_POS) | (TMS_DM << PRIMARY_SWDIO_PIN_POS)

| (TDI_DM  << PRIMARY_TDI_PIN_POS)    | (TDO_DM << PRIMARY_TDO_PIN_POS  );

}

Can I just set all bits to 1 for maximum protection?  Will this interfere with normal code execution like secure bootloading or writing to non-sflash flash areas?

Yes, setting all bits to 1 will enable all protection settings. But it is adviced to first configure the MPU structures and then change the efuse bits. The code execution and the writing to flash restrictions are defined by these structures.

Also, what is the feature "DirectExecute system call functionality"?  I don't see it described anywhere in the TRM or datasheet.  Is it safe to disable it?

DirectExecute system calls enable the user applications to execute system calls like flash write etc. If DirectExecute system call is enabled then the device might be vulnerable. So, it is adviced to disable the DirectExecute system call when entering SECURE mode.

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B

Thank you for the info.  Can you please tell me how to configure the MPU structures?  I don't see any COM API to program it.  I disabled DirectExecute but I can still write to the main and EEPROM flash region using Cy_Flash_WriteRow().  Is this the correct behavior?

0 Likes

Hi JeHu_3414236,

Cy_Flash_WriteRow() is different from the DirectExecute function call. DirectExecute function directly executes code located at a configurable address. This is mainly used for internal testing. I apologize for the confusion. Please refer to Section 12.5.10 DirectExecute in PSoC 6 MCU: CY8C62x6, CY8C62x7 Architecture TRM.

We are working on an Application Note that will address all these queries. I will update this thread once the AN is released.

Thanks and Regards,

Rakshith M B

Thanks and Regards,
Rakshith M B