FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

Internal RAM to determine cause of core reset

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
SOLVED
Jump to solution

Internal RAM to determine cause of core reset

Jump to solution
‎10-18-2016 05:00 PM
1,005 Views
vivienwong
Contributor I

Hi,

  

  I'm reading the LPC18xx user manual and it says that to determine the cause of core reset, we can use the flag in internal RAM. What location/address is this flag? So far, using the event router, I haven't been successful in determining the cause of core reset and I thought I'd like to try the flag in internal RAM. I've actually opened a question here a few days ago but haven't received a reply: https://community.nxp.com/thread/436767 

  I would appreciate a reply on this as soon as possible as it is delaying my development progress. Thank you.

0 Kudos
Reply
1 Solution

Jump to solution
‎10-25-2016 01:01 PM
640 Views
isaacavila
NXP Employee
NXP Employee

Hello Vivien,

 

You can use any address from internal RAM to "allocate a token", basically, what section

14.5.1 Determine the cause of a core reset

describes is the way to change this value depending the reset source. It uses the first "token" (0xAA55FF01) to signal when RESET by external pin is used and the second "token" (0xAA55FF02) to signal when RGU causes the reset event. However, it is not limited to use only these values.

 

  • Suppose that you choose 0x1000_0000 address for your flag. You can read this address the beginning, if this application has any value different than first token: 0xAA55FF01 (RESET) or second token: 0xAA55FF02 (RGU), then, MCU was reset by POR. (Remember that RAM's content is volatile and on POR event, address 0x1000_0000 will have random data).
  • After reading this value, you set the value 0xAA55FF01 to address 0x1000_0000. If a RESET event comes, then at the beginning of the application, 0xAA55FF01 will be read, showing that RESET event was caused (on POR, address 0x1000_0000 will have a random data different than 0xAA55FF01). On the other hand, before requesting a RGU reset event, you must write 0xAA55FF02 (second token) on address 0x1000_0000 and, on the beginning of the application, 0xAA55FF02 will be read, showing that this reset event was caused due RGU.
Does it make sense to you?

 

Regards,

Isaac

View solution in original post

0 Kudos
Reply
2 Replies

Jump to solution
‎10-25-2016 01:01 PM
641 Views
isaacavila
NXP Employee
NXP Employee

Hello Vivien,

 

You can use any address from internal RAM to "allocate a token", basically, what section

14.5.1 Determine the cause of a core reset

describes is the way to change this value depending the reset source. It uses the first "token" (0xAA55FF01) to signal when RESET by external pin is used and the second "token" (0xAA55FF02) to signal when RGU causes the reset event. However, it is not limited to use only these values.

 

  • Suppose that you choose 0x1000_0000 address for your flag. You can read this address the beginning, if this application has any value different than first token: 0xAA55FF01 (RESET) or second token: 0xAA55FF02 (RGU), then, MCU was reset by POR. (Remember that RAM's content is volatile and on POR event, address 0x1000_0000 will have random data).
  • After reading this value, you set the value 0xAA55FF01 to address 0x1000_0000. If a RESET event comes, then at the beginning of the application, 0xAA55FF01 will be read, showing that RESET event was caused (on POR, address 0x1000_0000 will have a random data different than 0xAA55FF01). On the other hand, before requesting a RGU reset event, you must write 0xAA55FF02 (second token) on address 0x1000_0000 and, on the beginning of the application, 0xAA55FF02 will be read, showing that this reset event was caused due RGU.
Does it make sense to you?

 

Regards,

Isaac

0 Kudos
Reply

Jump to solution
‎10-25-2016 02:50 PM
640 Views
vivienwong
Contributor I

Hi,

  Thanks for your reply. I figured that out too.

0 Kudos
Reply