Byte wide access to OCOTP->LOCK address seems to hang the CPU...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Byte wide access to OCOTP->LOCK address seems to hang the CPU...

1,189 Views
EdSutter
Senior Contributor II

Hi,

I'm working on an MIMXRT1060-EVK.  I'm doing some work with the OCOTP and I accidentally read from address 0x401f0400 (LOCK register) with a byte-wide access.  Clearly this is illegal.  My firmware catches all exceptions, but what I noticed was that my running program just hung (i.e. no longer responsive).  So, I attached my Segger JLINK and ran the [illegal] code again hoping that I could halt the core to see where the code was after that access (thinking maybe my exception handling was the problem).  I got a response from JLINK:  

**************************
WARNING: CPU could not be halted
**************************

Is this expected?  What is the state of the CPU if JLINK can't halt it?  Shouldn't that illegal access have caused the processor to at-least take a hard-fault exception?

Any thoughts?

Labels (1)
0 Kudos
9 Replies

1,051 Views
EdSutter
Senior Contributor II

Replying to my own post... Slight modification to the above..  I realized that I was at the wrong address (0x401f0400 should have been 0x401f4400); so the hangup is actually not caused by an unaligned access to that address, but just accessing that address period.  So, the question still stands... Assuming this must be an illegal address range within the memory map, shouldn't this cause an exception?

0 Kudos

1,051 Views
jeremyzhou
NXP Employee
NXP Employee

Hi ,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
According to your introduction, it seems like that read the value of OTP Bank0 Word0 will make the MCU be hung, I was wondering if you can share the testing code, as I'd like to replicate the phenomenon on my site.
Looking forward to your reply.

Have a great day,
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,051 Views
EdSutter
Senior Contributor II

The actual code is part of a large application, but it is easily reproducible with an access to that address.

Note that it is not at a valid location as far as I know; however, I would expect an exception, not a lockup.

For example...

printf("Val: ");
uint8_t val = *(uint8_t *)0x401f0400;
printf("%02x\n",val);

The output is simply:

Val:

and the processor is in that hung state at that point.

HTH,

Ed

0 Kudos

1,051 Views
jeremyzhou
NXP Employee
NXP Employee

Hi ,

Thanks for your reply.
In the ocotp_example demo from the SDK library, I add below codes to replicate the phenomenon you mentioned, however, in addition to MCU doesn't enter the hung state, I get the value of the OTP Bank0 Word0 (Lock controls) (LOCK).
Maybe you can run the ocotp_example demo for confirming.

    /* Get the OCOTP controller version. */
    version = OCOTP_GetVersion(OCOTP);
    LOCK_value = OCOTP->LOCK;

    PRINTF("OCOTP controller version: 0x%08X\r\n\r\n", version);
    PRINTF("OCOTP LCOK Register: 0x%08X\r\n\r\n", LOCK_value);

pastedImage_1.png

Have a great day,
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,051 Views
EdSutter
Senior Contributor II

Jeremy,

That's not the same as my example code.  Please read my responses and do exactly what my example does...

Ed

0 Kudos

1,051 Views
jeremyzhou
NXP Employee
NXP Employee

Hi ,

Thanks for your reply.
It still works well.

    /* Get the OCOTP controller version. */
    version = OCOTP_GetVersion(OCOTP);
    LOCK_value = *((uint8_t *)(0x401f4400));

    PRINTF("OCOTP controller version: 0x%08X\r\n\r\n", version);
    PRINTF("OCOTP LCOK Register: 0x%08X\r\n\r\n", LOCK_value);

pastedImage_1.png

Have a great day,
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,051 Views
EdSutter
Senior Contributor II

Jeremy,

You're not looking at the code I show above!

My line of code:

val = *(uint8_t *)0x401f0400;

Your line of code:

LOCK_value = *(uint8_t *)0x401f4400;

Notice your address vs my address.  My address is probably an illegal access (its not in the OCOTP register map)

but my board just hangs when I execute that. 

Please run your experiment using the 0x401f0400 address.

Ed

0 Kudos

1,051 Views
jeremyzhou
NXP Employee
NXP Employee

Hi ,

Thanks for your reply.
The 0x401f0400 is an invalid address in the chip, and the IC behavior may be unpredictable after reading or writing an area inside the invalid address range.
BTW, I've replicated the hung situation after executing the below code.
LOCK_value = *(uint8_t *)0x401f0400;

Have a great day,
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

1,051 Views
EdSutter
Senior Contributor II

Ok, thanks for clarifying Jeremy...

This just further emphasizes the need for the watchdog, which by the way, does recover this fault if enabled.

0 Kudos