topic Re: Debug in ROP_LEVEL1 in MCX Microcontrollers

Debug in ROP_LEVEL1

salvalatorre — Fri, 23 May 2025 05:48:25 GMT

After reading the insightful article MCXA153 Read Out Protection, it is clear to me that, once ROP1 or ROP2 is entered, it is possible to return the device to an unprotected state (ROP0) by performing a mass erase. However, we are particularly interested in the possibility of disabling the protection temporarily without erasing the flash memory, in order to debug units returned through RMA.

We have successfully implemented a secure workflow using a secret key configured during production with other microcontrollers, such as those in the Kinetis and iMXRT families. This key allows us to later disable protection temporarily for debugging purposes, without losing the contents of the flash memory.

Is there any similar mechanism or recommended approach for MCXA devices that would allow us to achieve this?

A footnote in the previous mentionted article to the image in section IV states: ROP1 Debug is disabled, but can be enabled by user application code.

That is exactly what I would like to do, but I don't know which way the application code can enable access through the debug port.

Could someone kindly provide me with documentation explaining this?

Re: Debug in ROP_LEVEL1

Alice_Yang — Mon, 26 May 2025 10:52:07 GMT

Hello @salvalatorre

Please use the Set_FA_Mode command. Combine with SPSDK. If you have installed the Secure Provisioning Tool, you can directly access the SPSDK within it.

Alice

Re: Debug in ROP_LEVEL1

salvalatorre — Mon, 26 May 2025 12:48:43 GMT

Hello @Alice_Yang,

1. I thought that FA Mode does not keep the memory's content (the article "MCXA153-Read-Out-Protection" says: without storing any IP assets) but we are looking for a opening protection mechanism that does keep so that we can analyze bugs by debugging the code inside.

2. Is FA Mode reversible? The MCXA manual says “Fault Analysis mode to return to NXP factory”, but we don't want to send it to NXP. In the initial post I was referring to an RMA being returned to our factory for analysis by us, not NXP.

3. In ROP1 mode, is it only possible to interact with the device ROM via ISP? The SWD port is more accessible in our products, so it would be a better option for us.

BR
Salvador.

Re: Debug in ROP_LEVEL1

Alice_Yang — Thu, 29 May 2025 02:47:17 GMT

Hello @salvalatorre

1. I thought that FA Mode does not keep the memory's content (the article "MCXA153-Read-Out-Protection" says: without storing any IP assets) but we are looking for a opening protection mechanism that does keep so that we can analyze bugs by debugging the code inside.

->>Yes, FA mode does not keep memory, also masse erase.

2. Is FA Mode reversible? The MCXA manual says “Fault Analysis mode to return to NXP factory”, but we don't want to send it to NXP. In the initial post I was referring to an RMA being returned to our factory for analysis by us, not NXP.

->> Customers can also use FA mode, but as mentioned above, it will also erase the flash.

3. In ROP1 mode, is it only possible to interact with the device ROM via ISP? The SWD port is more accessible in our products, so it would be a better option for us.

->> No, the SWD port is disabled on ROP1-3. This read-out protection is a mechanism that allows users to enable the of protection in the system.

Alice

Re: Debug in ROP_LEVEL1

salvalatorre — Thu, 29 May 2025 06:25:51 GMT

Hello Alice,

I understand that the protection is intended to prevent external access. However, it would be very useful if the program itself, after authenticated access through some means (e.g., serial port), could disable the protection without triggering a mass erase. This is possible with Kinetis and LPC microcontrollers, and would be a significant drawback to adopting the MCX.

A footnote to the image in section IV of the previously mentioned article states: "ROP1 Debug is disabled, but can be enabled by user application code."

That is exactly what I would like to do, but I don’t know how the application code can enable access through the debug port. Would you be so kind to tell me or point me to documentation where this is explained?

Regards,
Salvador.

Re: Debug in ROP_LEVEL1

salvalatorre — Fri, 30 May 2025 08:35:40 GMT

Sorry, I replied by mistake to my first post and my reply may have been missed:

Hello Alice,

I understand that the protection is intended to prevent external access. However, it would be very useful if the program itself, after authenticated access through some means (e.g., serial port), could disable the protection without triggering a mass erase. This is possible with Kinetis and LPC microcontrollers, and would be a significant drawback to adopting the MCX.

A footnote to the image in section IV of the previously mentioned article states: "ROP1 Debug is disabled, but can be enabled by user application code". That is exactly what I would like to do, but I don’t know how the application code can enable access through the debug port. Would you be so kind to tell me or point me to documentation where this is explained? Enabling the debug port by registers, reprogramming ROP_LEVEL in CMPA... any mechanism that from the program allows enabling debug access (after gaining authorization) would be great.

Regards,
Salvador.

Re: Debug in ROP_LEVEL1

Alice_Yang — Tue, 03 Jun 2025 10:52:30 GMT

Hello @salvalatorre

Please refer to the code under AN14525SW：

https://www.nxp.com/docs/en/application-note-software/AN14525SW.zip

https://docs.nxp.com/bundle/AN14525/page/topics/introduction.html

It includes the code to enable SWD .

Alice