Strange program crashes

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Program crashes to Dummy_Handler (IPSR = 6,3) from code that worked fine with a demo board.

Have my own board that I'm bringing up: ATSAMS70J21B. Code was developed on SAM E70 Xplained board (ATSAME70Q21) and worked fine.

Crash occurs in a library function (library developed in-house). Other than the IPSR code, there appears to be no reason for the crash, it happens right at the function header.

Funny thing is that changing optimization levels affects where the crash occurs.

Only 15% program and 7% data memory used.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

did the program crash or raise an exception?  If it got to the dummy handler, it was an exception and there was a reason for this. Is it something like an unaligned fetch or a load or store to an illegal address or unaligned address? Other reasons might be an unhandled interrupt vector - it could just be that the interrupt gets fired when your function is called.

 

 

Last Edited: Sun. Aug 18, 2019 - 09:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It jumps to dummy handler right at the function header so it's hard to tell why other than the code (3 and/or 6) which doesn't help much.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a way to view the stack, program counter, and memory pointers? It may be that the program is trying to access external memory that's not there. This code was developed on the Xplained board which has external memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Found the "Processor Status" display. Everything looks ok until the crash and then the "Link Register" goes from 0x0040B549 (SRAM) to 0xFFFFFFF9, which is definitely wrong.

What is the "Link Register"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You want to read up on the cortex m4 architecture! With the ARM, rather than doing a function call by pushing the return address on the stack and jumping , the compiler might do a BX where the link reg holds the return address. As to what might cause your problem - i dare say like a train crash, the problem happens well before the exception. Backtrack to find where your magic value of fffffff9 appears. My guess is stack overflow or bad array index. Just because it worked in the other cpu doesn’t mean it doesn’t have the defect as well. As was demonstrated with the Therac25, the defects were well entrenched, but only came to light when there were some changes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman,

I have stepped through the code and the LR value of FFF...9 only appears after the crash; everything else looks normal up until then.

Could be a memory location that points outside the SRAM range but I haven't seen that.

The crash occurs in a library function that is compiled separately and is affected by the optimization level.

BTW, the processor is an ARM Cortex-M7, not an M4.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Examine the stack frame that gets pushed on the exception. It could be you have an interrupt with the default vector of the dummy handler. You can also modify the dummy handler to return.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The stack looks wrong to me. Stack should start at the end of RAM and work down so, for this processor, start at 0x2060000 (or close). However, the stack is at 0x204088A8 at the start of main. It is at 0x20408838 when it crashes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stack at the end of ram? Not necessarily. It is not unusual to have the heap placed above the stack. We’re not using little micros with tiny ram anymore!
If you have largish arrays, then you might have stack issues. Looking at the map file might give clues.

Have a look at your project settings to see if there is stack configuration else have a look at the linker file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I don't think it's a stack or heap problem; I increased both their sizes and it didn't make a difference though I saw the changes.

The Xplained board used an external RAM but my board does not. Could it be trying to use that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Possibly. All we know is that you have an exception/interrupt that gets mapped to the dummy handler. My specific knowlege of the arm interrupt system gets a little thin at this point, but you need to determine the source of this. There might be info in the stack frame or in the interrupt controller that will tell you this. Once you know the source, then that will either explain or point you towards the cause. I’d suggest you read up on this in the arm docs. Alternately, you could add specific handlers and see which handler gets fired - a bit brutal and longwinded though. Its these problems where you learn a lot - although you’d prefer not to!

Last Edited: Mon. Aug 26, 2019 - 11:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After digging deeper and with a bit of luck, I found out the FPU needed to be enabled.

 

Called "fpu_enable()" and that fixed the crashes and the program is now running correctly.

 

There was nothing that indicated the crashes were caused by the FPU not being enabled nor was there any mention of it in the documentation (at least that which I found and read).

 

Now on to why I'm not getting data out the second UART.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fpu - i didn’t expect that! You’ve gained some skills now for the next time. That problem would've been near impossible to find without a debugger.
Another technique you might find handy is to use the debugger to look at the peripheral configuration - with all the libraries etc, you don’t really know what they’re doing so when things don’t work as expected, getting down and dirty with the peripherals can help. You can also fiddle the configuration to try things.