Determining source of "reset"

RE: Determining source of "reset"

Richard Phillips — Tue, 26 May 2015 13:52:44 GMT

Ok, thanks!

RE: Determining source of "reset"

Hung Bui — Tue, 26 May 2015 12:29:01 GMT

@Richard: I can find that you fixed the issue in the linked case. I suggest we can close this case here.

RE: Determining source of "reset"

Richard Phillips — Fri, 22 May 2015 09:36:47 GMT

Hung, I created a new (more specific) topic here: devzone.nordicsemi.com/.../

In there, I've had some more help and have nearly resolved my issue... I think your suspicion was right though!

RE: Determining source of "reset"

Hung Bui — Fri, 22 May 2015 09:30:15 GMT

@Richard: Have you managed to figure out what caused the issue ?

I suspect that it was because there is no link in the vector table to the UART IRQ handler, then the compiler simply ignore the function because there is no reference/call to it. I'm not sure how it's done on IAR but in KEIL the IRQ handler is linked at arm_startup_nrf51.s file.

RE: Determining source of "reset"

Richard Phillips — Thu, 21 May 2015 10:58:17 GMT

It seems that UART0_IRQHandler() is missing from the map-file. However, looking at the lst-file for app_uart_fifo (both projects), everything seems ok. So is it a linker issue?

RE: Determining source of "reset"

Richard Phillips — Thu, 21 May 2015 08:51:44 GMT

One early observation - I am unable to set breakpoints (in my project) within UART0_IRQHandler(), even though app_uart_fifo.c is part of my project.

RE: Determining source of "reset"

Richard Phillips — Thu, 21 May 2015 08:33:59 GMT

Hung, I've gone back to the UART example (my code was based on it actually), I've made a few trivial mods to get it working on my custom hardware (pin changes, remove the LED stuff), and it works! So, now I need to figure out what's different...

RE: Determining source of "reset"

Hung Bui — Wed, 20 May 2015 15:52:41 GMT

@Richard: I'm not very familiar with IAR, I would suggest you to isolate the issue, maybe creating a project to test just the UART module. Note that we provided an example on UART in the SDKv8.x and there is an IAR project for UART that you can test.

If it doesn't help, I would suggest you to post a case in our support portal (Mypage section in our website), it's private portal where you can send confidential information/code.

RE: Determining source of "reset"

Richard Phillips — Wed, 20 May 2015 15:20:27 GMT

Having dug further... I'm still not sure what might cause a LOCKUP. Plus, I am unable to set a breakpoint on UART0_IRQHandler() - having looked through the stack and compared to map file, it looks like the code might be getting as far as somewhere in "app_uart_fifo", but not sure where yet...

RE: Determining source of "reset"

Richard Phillips — Wed, 20 May 2015 15:17:12 GMT

IAR Embedded Workbench. I am happy to share the code, but it's probably not quite simple enough to post up here (more than one module, each with it's own boilerplate code). I could email it as a zip (entire project!), or can look at posting if it's the only option, but it'll run to a good few screens!

RE: Determining source of "reset"

Hung Bui — Wed, 20 May 2015 14:43:38 GMT

@Richard: Which compiler did you use ? Could you post your code ?

RE: Determining source of "reset"

Richard Phillips — Wed, 20 May 2015 12:29:34 GMT

RESETREAS indicates LOCKUP (and only that - I clear RESETREAS at the start of main()). Does that sound consistent with a missing handler, or should I be looking elsewhere now?

RE: Determining source of "reset"

Nick Pelis — Tue, 19 May 2015 17:11:24 GMT

You can look at NRF_POWER->RESETREAS register to determine the source of the reset.

A soft reset should not kill the state of memory. You'll know this because at the time the processor jumps to the reset vector, your stack pointer will still be valid (sp register is nonzero). If this is the case, then another trick you can use is to put the stack pointer in the memory window and see what was on the stack at the time of the reset. Of particular interest will be values corresponding to function return addresses (anything in the memory range 0x00000000 - SIZE_OF_FLASH_IN_HEX). You can then match those return addresses up using the .map file and work out the sequence of calls at the time the reset occurred.

My guess is that somewhere you have an undefined event handler which is invoked when UART characters are received, so the processor is executing a BLX instruction to address zero.