Usage Fault in App Scheduler

RE: Usage Fault in App Scheduler

goldwake — Mon, 07 Aug 2017 00:12:55 GMT

I've managed to fix this. Turns out there was a potential pointer error in one of my events. Thanks for your help, I've definitely learnt a lot about debugging hardfaults etc

RE: Usage Fault in App Scheduler

RK — Wed, 02 Aug 2017 21:42:58 GMT

there you go - that MMD post did have it in it in a comment. It's called Vector Catch (so I wasn't that far off). Even googling that there's not a lot of information. I must have read about it in the M4 debug and trace technical manual or something.

RE: Usage Fault in App Scheduler

RK — Wed, 02 Aug 2017 21:34:23 GMT

no - not MMD. What I'm talking about it breakpoints on exceptions, which get taken before the fault handler is called. I never saw them on the nRF51 series, when I started working with the '52 they showed up enabled (I use Crossworks which is basically Segger Embedded Studio). It was confusing at first because they caused debug stops at points I didn't expect and got turned off at some point. I just don't remember the term for them and don't have a board handy right now (been in Atmel land for a while recently which is mostly cortex M0 again).

Nor has my google-fu turned up the term. Either way - on the M4 you should be able to take a breakpoint before the exception handler runs which is handy dandy for figuring out where you were without having to work backwards.

RE: Usage Fault in App Scheduler

goldwake — Wed, 02 Aug 2017 21:27:02 GMT

@RK when you talked about catch points, where you referring to monitor mode debugging? I've sent away a PCB to be made so I can use the ETM on the Dev Kit. @Hung Bui, its easy to reproduce but takes a couple of minutes to occur. I'll try create a simplified demonstration

RE: Usage Fault in App Scheduler

Hung Bui — Tue, 01 Aug 2017 14:26:07 GMT

@goldwake: Is it easy to reproduce ? Could you provide simplified source code (could be a SDK's example) that we can run on the nRF5 DK and can reproduce the issue here ?

RE: Usage Fault in App Scheduler

goldwake — Tue, 01 Aug 2017 05:15:55 GMT

Unfortunately it doesn't look like its due to a small stack. Increasing the stack from 8192 to 18480, gives no improvement. Tomorrow I will have a look at trying to get ETM going with a ULink pro, maybe that can offer some insight. I'll also look at the catch points you mentioned

RE: Usage Fault in App Scheduler

RK — Tue, 01 Aug 2017 04:14:52 GMT

that may also explain the second trace, remember I said I didn't understand the PC (it was 0x024f0a00) which meant nothing, if you have an event handler on your queue you're jumping to and that is getting corrupted as you think .. that may be your issue.

Do you have enough stack? wonder if you're running the stack into your event queue or something.

RE: Usage Fault in App Scheduler

RK — Tue, 01 Aug 2017 04:11:53 GMT

yes I know r7 is the event handler - question I had was is it 0x00000000 and that bl r7 was jumping there, or is it making it to event_handler correctly and then indirecting to something else which is 0x0. Or perhaps I'm wrong about the PC on the stack trace being 0x0 (first stack trace) which indicates where it was when it faulted.

Can you check that a couple more times, see if that is the address? If so then you can put an execute breakpoint on 0x0 and it should break before it runs the instruction which takes the exception. Then you have a stack.

You're on the nRF52 as well, it should be possible to set breakpoints (I can't think what they are called now, catchpoints or something) on the exceptions which will drop into debug again BEFORE the exception is taken. I haven't used them in a while but had at some point to turn them off to get my exception handlers called.

RE: Usage Fault in App Scheduler

goldwake — Tue, 01 Aug 2017 04:01:58 GMT

0> sched 58 //my app_sched_pull_evt()is processing evt 58
0> ADDING 64 //My app is adding evt 64
0> put 26 22FF5 // evt 64 has size 26 and handler addr 0x22FF5
0> ADDING 58 //My app is adding evt 58
0> put 26 22FF5 // evt 58 has size 26 and handler addr 0x22FF5
0> sched done 7 //my app_sched_pull_evt() is finished processing evt 58. There are 6 (7 -1) elements in queue free
0> h //exited my app_sched_pull_evt()
0>sched 64 //my app_sched_pull_evt() is processing evt 64
0> sched done 8 //my app_sched_pull_evt() is finished processing evt 58. There are 7 (8 -1) elements in queue free
0> h //exited my app_sched_pull_evt()
0>event_data_size 0 // unexpected data size in app_sched_execute
0> event_handler 5EB0A01 // unexpected handler in app_sched_execute

RE: Usage Fault in App Scheduler

goldwake — Tue, 01 Aug 2017 04:01:47 GMT

Thanks RK.

r7 is the event_handler. I think I'm seeing the same problem manifest itself as usage and bus faults. I've narrowed this down and it seems that somehow the m_queue_event_headers buffer is being corrupted. I see that the vaules for event_size and/or event_handler are being read differently to what I set them as. here is an example trace:

RE: Usage Fault in App Scheduler

RK — Tue, 01 Aug 2017 02:12:19 GMT

So lots of good information there. Going back to the original usage fault. You have a little more information, you know that the p_event_data was 0x20009b42 and the size of the event was 31 bytes (0x0000001f), that from the stacked R0 and R1 assuming they didn't change before the fault occurred. If they make sense, it sounds like you didn't get far after bx r7

You also have the PC at the point of the fault which according to that trace is 0x00000000. That doesn't look good. (don't understand the PC in the second image). So my first guess here would be you've jumped to 0x00000000, whatever is there (the initial stack pointer) disassembles as something which causes a usage fault, probably an invalid instruction.

I can't see where r7 comes from, that I assume is the address of the event_handler which was loaded a little earlier from the event handling structure. If any of that code used but didn't destroy r2, r3 or any of the other stacked registers, you might be able to see what r7 was loaded with. If that was zero, the bx r7 would have caused what you're seeing.

If that's the case then something reset the event_handler to 0x00000000 (or you stomped over your memory). I don't know what resets that to zero but possibly a de-registration of the event handler might. Are you deregistering the event handler anywhere whilst you still have events to process?

RE: Usage Fault in App Scheduler

Hung Bui — Mon, 31 Jul 2017 14:17:41 GMT

If you don't enable the SCB what would happens ? Where in the code the hardfault handler's stack pointed to ? Please try to describe what you observed before you go in to debugging. What exactly happened when "it starts receiving usage faults." ?

RE: Usage Fault in App Scheduler

goldwake — Sun, 30 Jul 2017 21:04:27 GMT

Hi Hung Bui, I have already got the app_error_handler defined and have been using it however, when I see this problem, it does not go into the error handler. It would go into the hard fault handler until I enabled the usage and bus fault handlers like this

SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk;

RE: Usage Fault in App Scheduler

Hung Bui — Fri, 28 Jul 2017 12:32:44 GMT

I afraid you just over complicated the debugging process. Could you describe what exactly happen when "it starts receiving usage faults." Please try to follow this guide.