How to re-enable Debug Interface on XMC4700?

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

cross mob
BillT
Level 1
Level 1
First reply posted First question asked Welcome!

The XMC4700-4800 Reference Manual, section 28.4.1, says:

Depending on the boot scenario and the Flash protection setup, the Startup Software enables the debug interface. If it is left disabled, the user can define a protocol, e.g. a password- protected unlock sequence via an SPI port, to enable the debug interface.

There is discussion here (by @Owen_Su and others) about how after calling XMC_FLASH_InstallProtection(),  the debug interface (i.e. JTAG) will be disabled for any Flash-based boot modes.  The above statement indicates that it is possible to re-enable JTAG in the running firmware, so that I could attach to that running firmware and debug.  I'd expect that on device reset, the JTAG would be disabled again.

I cannot find anywhere in the manual that describes how to enable the debug interface.  There is some other text:

A bit DAPSA, (DAP has system access) in the SCU is implemented, allowing the access from CoreSightTM debug system to the processor core.

That hints of a mechanism, but I can't find any other references to DAPSA in the documentation or library code.  That reference does go on to say that DAPSA is set unconditionally when the boot ROM exits, so it isn't clear that it is the right mechanism for the firmware to enable JTAG access.

Thanks,

Bill

0 Likes
1 Solution
Owen_Su
Moderator
Moderator
Moderator
250 solutions authored 500 replies posted 50 likes received

Hi, @BillT ,

    You can refer to the codes below:

int main(void)
{

  XMC_GPIO_EnableDigitalInput(XMC_GPIO_PORT15,12);
  XMC_GPIO_EnableDigitalInput(XMC_GPIO_PORT15,13);

  /* Placeholder for user application code. The while loop below can be replaced with user application code. */
  while(1U)
  {
	  if(XMC_GPIO_GetInput(XMC_GPIO_PORT15,12) == 0u)  // Add security
	  {
		  XMC_FLASH_InstallProtection(0, 0x8000, 0x7E0, 0x7E0);
		  XMC_FLASH_ConfirmProtection(0);
		  Security = 1;
		  while(1);
	  }

	  if(XMC_GPIO_GetInput(XMC_GPIO_PORT15,13) == 0u) // release security
	  {
		  XMC_FLASH_VerifyReadProtection(0x7E0, 0x7E0);
		  //XMC_FLASH_EraseUCB(XMC_FLASH_UCB0);
		  XMC_FLASH_ResumeProtection();

		  Security = 0;
		  while(1);
	  }


  }
}

    Flash can be temporarily decrypted through Disable Read/Sensor Write Protection.  If you do the system reset, Flash will resume encryption again.

    Permanently decrypting Flash by erasing the Flash UCB can only be done up to 4 times, otherwise it may damage the Flash.

Owen_Su_0-1683342771668.png

BR,

Owen

View solution in original post

0 Likes
6 Replies
lock attach
Attachments are accessible only for community members.
Owen_Su
Moderator
Moderator
Moderator
250 solutions authored 500 replies posted 50 likes received

Hi, @BillT ,

    You can refer to the attachment, this example is used for Flash encryption and decryption. After pressing BUTTON2, flash encryption, and reset, the MCU can no longer be debugged. After pressing BUTTON3, flash decryption, and reset, MCU can continue debugging.

    Flash encryption/decryption can also be implemented using MemTool:

    encryption:

Owen_Su_0-1683180802788.png

Owen_Su_1-1683180883669.pngOwen_Su_2-1683180899016.png

    decryption:

Owen_Su_5-1683181150972.png

BR,

Owen

0 Likes
BillT
Level 1
Level 1
First reply posted First question asked Welcome!

Hi @Owen_Su ,

Thanks for your response.

Your example removes the Flash protection, which will remove the JTAG protection after the next reset.  My hope has been to simply "enable the debug interface" as the Reference Manual says, without adjusting the Flash protection.  As you know, enabling or disabling the Flash protection requires a write to the UCB, so there is a very limited number of times that this can be done.  Additionally, if a production unit is in a bad state, it would be nice to be able to attach JTAG to the running unit (after an unlock) without requiring a reset.

My assumption is that the Boot ROM / SSW is able to control whether the Debug Port is enabled programmatically (possibly via DAPSA in the SCU), based on the type of boot being performed.  In that case, the user firmware should be able to operate the same controls to enable/disable the Debug Port as described in that line in the Reference Manual.

Thanks,

Bill

0 Likes
Owen_Su
Moderator
Moderator
Moderator
250 solutions authored 500 replies posted 50 likes received

Hi, @BillT ,

    From what you described, I think that changing the BMI value can meet your requirements. You can refer to the chapter 27 in the reference manual.

    Startup Software in BootROM (SSW) which provisions the various boot modes selectable by the user and is the main thread of execution. Desired boot mode can be enabled by driving the boot mode pins (JTAG TCK and TMS) with appropriate logic levels and issuing a power on reset. The actual value of these pins is latched into register STCON.HWCON. Some boot modes can only be selected by configuring STCON.SWCON bit field (of SCU module) and applying a system reset (such as a watchdog reset or CPU software reset).

BR,

Owen

 

 

0 Likes
BillT
Level 1
Level 1
First reply posted First question asked Welcome!

Hi Owen,

Thanks for the suggestion.  I'm already using the BMI boot mode (which is configured to lead to a FABM startup).  And changing it on the fly would also use up a cycle of the UCB flash, right?  So I don't see a way to use it to enable JTAG/Debug without a UCB reset and reboot.

There is also a statement (in 27.2.1):

Before program control is hand over to user application (described next), SSW turns on the Startup protection feature. This restricts access to certain registers (described as startup protected registers) and memories such as the Flash Configuration Sector (FCS).

I suppose that the DAPSA bit referenced in 28.4.2 may be such a "startup protected register", and be the way in which the Debug Port is disabled.  In which case user code can't enable the Debug Port if Flash is protected.  If so, it is frustrating that 28.4.1 implies that it is possible to enable Debug Port access.

 

0 Likes
Owen_Su
Moderator
Moderator
Moderator
250 solutions authored 500 replies posted 50 likes received

Hi, @BillT ,

    You can refer to the codes below:

int main(void)
{

  XMC_GPIO_EnableDigitalInput(XMC_GPIO_PORT15,12);
  XMC_GPIO_EnableDigitalInput(XMC_GPIO_PORT15,13);

  /* Placeholder for user application code. The while loop below can be replaced with user application code. */
  while(1U)
  {
	  if(XMC_GPIO_GetInput(XMC_GPIO_PORT15,12) == 0u)  // Add security
	  {
		  XMC_FLASH_InstallProtection(0, 0x8000, 0x7E0, 0x7E0);
		  XMC_FLASH_ConfirmProtection(0);
		  Security = 1;
		  while(1);
	  }

	  if(XMC_GPIO_GetInput(XMC_GPIO_PORT15,13) == 0u) // release security
	  {
		  XMC_FLASH_VerifyReadProtection(0x7E0, 0x7E0);
		  //XMC_FLASH_EraseUCB(XMC_FLASH_UCB0);
		  XMC_FLASH_ResumeProtection();

		  Security = 0;
		  while(1);
	  }


  }
}

    Flash can be temporarily decrypted through Disable Read/Sensor Write Protection.  If you do the system reset, Flash will resume encryption again.

    Permanently decrypting Flash by erasing the Flash UCB can only be done up to 4 times, otherwise it may damage the Flash.

Owen_Su_0-1683342771668.png

BR,

Owen

0 Likes
Owen_Su
Moderator
Moderator
Moderator
250 solutions authored 500 replies posted 50 likes received

Hi, 

    This thread will be closed due to long time no reply, you can create a new one if you have any other question. Thanks for your understanding.

BR,

Owen

0 Likes