- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all.
I'm currently working on designing a bootloader to be loaded during manufacturing and once it's in the user's hands, the actual firmware is downloaded from our servers. Now, I'd like to permanently disable the SWD interface after the manufacturing firmware has been loaded to prevent it being dumped. I'm new to the PSoc series and I'd like to know what options I have? Can this all be done in code, or do I need a dedicated SWD programmer from PSoc to achieve this?
Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Can you please let me know which PSoC6 device you are referring to? PSoC6 devices come with EFuses that you can burn to enter SECURE mode where the DAP is disabled completely.
Please refer to the following threads for more information:
Is it possible to prevent user to trace through SWD/JTAG?
Reversible DAP lock using EFUSE_DATA_SECURE_ACCESS_RESTRICT0
Please refer to the Architecture TRM for more information on E-fuses and lifecycle modes.
Regards,
Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pn,
In the Design Wide Resources (DWR) there is a tab called "System"
Select the "Debug Select/GPIO" to allow the SWCLK and SWIO pins to be used as GPIO and therefore cannot be used for debugging.
You should note the following:
In order to program the bootloader, the SWCLK and SWIO pins are used. At powerup or RESET, these programming pins are available. If the reset is not intercepted by the programmer, the CPU will go through the boot process and will shortly allow the SWCLK and SWIO pins to be disabled and repurposed as GPIO.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!! Wouldn't this post a security issue in still allowing somebody to still dump the firmware if they control the reset line? I was hoping there are fuses connected to the swd lines which can be burned, resulting only them pins being used as GPIO?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pn,
You may want to speak to Cypress about your security needs.
At reset/powerup the SWDCLK and SWIO lines are available for programming AND debugging!
There are two options I am aware of to protect FLASH and possibly EEPROM and RAM.
Option #1: There is a "FLASH SECURITY" tab in the DWR. Here you can protect FLASH for "FULL PROTECTION". However, I don't know what the limitations are if you want to use a bootloader and allow for in-field firmware updates.
Option #2: The "System" tab of the DWR allows for Chip Protections of "Open", "Protected (no debugging)" and "Kill (program once and reprogramming not allowed)". For you, probably only "Protected" is useful. The "Kill" option blows a security fuse after programming. This prevents any debugging and any reprogramming as well. If you need to change the code you need to throw away the CPU.
... once it's in the user's hands, the actual firmware is downloaded from our servers.
With the above statement I don't know how you're going to protect the load the user is loading into the product in the field. Any file supplied to the bootloader can be reverse-engineered.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Can you please let me know which PSoC6 device you are referring to? PSoC6 devices come with EFuses that you can burn to enter SECURE mode where the DAP is disabled completely.
Please refer to the following threads for more information:
Is it possible to prevent user to trace through SWD/JTAG?
Reversible DAP lock using EFUSE_DATA_SECURE_ACCESS_RESTRICT0
Please refer to the Architecture TRM for more information on E-fuses and lifecycle modes.
Regards,
Dheeraj