Mar 02, 2016
01:44 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 02, 2016
01:44 AM
Hello,
I am currently busy with the flash protection of XMC4 family.
Due to the chapter 8.4.8.4 of UM XMC4500, System Wide Effects of Flash Protection:
If the read protection is activated, after power-up the SSW clears the DCF and DDF to be able to run up the system, in additional it leaves the debug-interface e. g. JTag interface locked.
Does it mean that I am not able to access the system with e. g. a Jtag Debugger anymore if the read protection is once activated ?
Thank you very much in advance for any clarification.
I am currently busy with the flash protection of XMC4 family.
Due to the chapter 8.4.8.4 of UM XMC4500, System Wide Effects of Flash Protection:
If the read protection is activated, after power-up the SSW clears the DCF and DDF to be able to run up the system, in additional it leaves the debug-interface e. g. JTag interface locked.
Does it mean that I am not able to access the system with e. g. a Jtag Debugger anymore if the read protection is once activated ?
Thank you very much in advance for any clarification.
- Tags:
- flash protection
- IFX
4 Replies
Mar 03, 2016
12:35 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 03, 2016
12:35 AM
Yes, you are right. That's the purposes of flash protection as debugger shall be disabled.
Mar 03, 2016
01:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 03, 2016
01:50 AM
Hi Travis,
many thanks for your reply.
Additional comments how to handle the flash protection:
1. If I want to use this feature so I should activate it only for series production, right !? During development it should be better NOT active since no debug session is possible !?
2. If the flash protection is activated the Startup SW clears the DCF and DDF after power-up,
so while the my App.-SW is running I do not need to clear the DCF & DDF again if I want to do read/write access to the flash e. g. for firmware update, is it correct ?
3. In case of flash protection is active and I still want to debug I could do following:
a) change the bootmode (!= internal pflash)
b) connect the Jtag debugger, download a software (executable on PSRAM) which deletes the UCB0 (with correct passwords), after power-on the debug interface is not locked anymore ?
4. About "Resume Protection", as I understand it: after disabling e. g. the read protection, the read protection is enabled again after reset,
or I could do a "Resume Protection". I am wondering how the code fetch can be done after a "Resume Protection" ? (Misunderstanding on my part ?)
I would be very appreciated for comments for your part again. Thank you in advance.
many thanks for your reply.
Additional comments how to handle the flash protection:
1. If I want to use this feature so I should activate it only for series production, right !? During development it should be better NOT active since no debug session is possible !?
2. If the flash protection is activated the Startup SW clears the DCF and DDF after power-up,
so while the my App.-SW is running I do not need to clear the DCF & DDF again if I want to do read/write access to the flash e. g. for firmware update, is it correct ?
3. In case of flash protection is active and I still want to debug I could do following:
a) change the bootmode (!= internal pflash)
b) connect the Jtag debugger, download a software (executable on PSRAM) which deletes the UCB0 (with correct passwords), after power-on the debug interface is not locked anymore ?
4. About "Resume Protection", as I understand it: after disabling e. g. the read protection, the read protection is enabled again after reset,
or I could do a "Resume Protection". I am wondering how the code fetch can be done after a "Resume Protection" ? (Misunderstanding on my part ?)
I would be very appreciated for comments for your part again. Thank you in advance.
Attachments are accessible only for community members.
Mar 03, 2016
06:23 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 03, 2016
06:23 PM
1. If I want to use this feature so I should activate it only for series production, right !? During development it should be better NOT active since no debug session is possible !?
Yes, you are right. Flash protection is to prevent hacker to read and edit the software inside the XMC4000 flash. Hence this should be done during production after you had programmed the flash.
2. If the flash protection is activated the Startup SW clears the DCF and DDF after power-up,
so while the my App.-SW is running I do not need to clear the DCF & DDF again if I want to do read/write access to the flash e. g. for firmware update, is it correct ?
This is taken care by the startup software and there is no need to be involve with DCF and DDF.
3. In case of flash protection is active and I still want to debug I could do following:
a) change the bootmode (!= internal pflash)
No it is not possible. To unprotect the flash you have to erase the UCB.
b) connect the Jtag debugger, download a software (executable on PSRAM) which deletes the UCB0 (with correct passwords), after power-on the debug interface is not locked anymore ?
For firmware update, there is a temporary unprotect feature which allows user to update the firmware as many times as you wish. The protection is active again automatically after a hardware reset.
4. About "Resume Protection", as I understand it: after disabling e. g. the read protection, the read protection is enabled again after reset,
or I could do a "Resume Protection". I am wondering how the code fetch can be done after a "Resume Protection" ? (Misunderstanding on my part ?)
See 3b
You can have a feel of the protection feature using Memtool (see attached ppt). Please note that there is limited number of times you can reprogram the UCB (about 10 times) after that the MCU will be lock out forever. Other than that, please also remember your password.
Yes, you are right. Flash protection is to prevent hacker to read and edit the software inside the XMC4000 flash. Hence this should be done during production after you had programmed the flash.
2. If the flash protection is activated the Startup SW clears the DCF and DDF after power-up,
so while the my App.-SW is running I do not need to clear the DCF & DDF again if I want to do read/write access to the flash e. g. for firmware update, is it correct ?
This is taken care by the startup software and there is no need to be involve with DCF and DDF.
3. In case of flash protection is active and I still want to debug I could do following:
a) change the bootmode (!= internal pflash)
No it is not possible. To unprotect the flash you have to erase the UCB.
b) connect the Jtag debugger, download a software (executable on PSRAM) which deletes the UCB0 (with correct passwords), after power-on the debug interface is not locked anymore ?
For firmware update, there is a temporary unprotect feature which allows user to update the firmware as many times as you wish. The protection is active again automatically after a hardware reset.
4. About "Resume Protection", as I understand it: after disabling e. g. the read protection, the read protection is enabled again after reset,
or I could do a "Resume Protection". I am wondering how the code fetch can be done after a "Resume Protection" ? (Misunderstanding on my part ?)
See 3b
You can have a feel of the protection feature using Memtool (see attached ppt). Please note that there is limited number of times you can reprogram the UCB (about 10 times) after that the MCU will be lock out forever. Other than that, please also remember your password.
Mar 04, 2016
12:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 04, 2016
12:53 AM
Thumbs-up for your comments, Travis. Thank you very much for the very helpful clarification and attached pptx-file.