帮助
英语（美国） | English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

Internal RAM to determine cause of core reset

取消
开启建议
自动建议可通过在您键入时建议可能的匹配，而快速缩小您的搜索结果范围。
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决
跳至解决方案

Internal RAM to determine cause of core reset

跳至解决方案
‎10-18-2016 05:00 PM
1,968 次查看
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 项奖励
回复
1 解答

跳至解决方案
‎10-25-2016 01:01 PM
1,603 次查看
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 项奖励
回复
2 回复数

跳至解决方案
‎10-25-2016 01:01 PM
1,604 次查看
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 项奖励
回复

跳至解决方案
‎10-25-2016 02:50 PM
1,603 次查看
vivienwong
Contributor I

Hi,

  Thanks for your reply. I figured that out too.

0 项奖励
回复