SAMB11 debugging/crashing at 0x54A ?

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

I'm desperately trying to do useful debugging of the samb11 - Atmel's refusal to provide a decent datasheet or code for their firmware is getting in the way.  One of the things I've noticed is that when I can get the debugger to work at all, I often find that I'm looping at 0x54a:

0000054A   b    #-4         

...which makes me think this is some kind of "we're screwed, so loop here" error handler.  Anyone know what I might be doing that I wind up there so frequently?  This generally happens after I call ble_event_task(20).  

 

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

Do you use ULP ?

 

For instance using  : ble_set_ulp_mode(BLE_ULP_MODE_SET);

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

Yes, most of the examples use ULP.  I've tried a bit without it, and while I seem to wind up at 0x54a less often, I have actually wound up there without it...

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

Which modules are you using ?

 

Are you using the MSx ports ?

 

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

OK, I now know more about the SAMB11 and debugging cortex-m0 (which is the cpu core) with GDB instead of the atmel debugger.   While I don't know exactly what was going on before, I will say that at least with ASF3.34.1, 0x54a is within the hardfault handler.  In fact, the vector table of the CPU is here:

 

>>> x/20w 0

0x0: 0x10003fd8 0x000004b1 0x0000052d 0x0000053d

0x10: 0x00000000 0x00000000 0x00000000 0x00000000

0x20: 0x00000000 0x00000000 0x00000000 0x0000054d

0x30: 0x00000000 0x00000000 0x0000055d 0x0000056d

0x40: 0x0000057d 0x0000058f 0x000005a1 0x000005b3

 

The hardfault vector is 0x53d  - since this is Thumb mode (as all cortex-m0 are), the vector actually starts at 0x53c:

 

>>> disassem 0x53c,0x54c

Dump of assembler code from 0x53c to 0x54c:

   0x0000053c: ldr r0, [pc, #712] ; (0x808)

   0x0000053e: ldr r0, [r0, #12]

   0x00000540: ldr r1, [pc, #712] ; (0x80c)

   0x00000542: cmp r0, #0

   0x00000544: str r0, [r1, #0]

   0x00000546: beq.n 0x54a

   0x00000548: bx r0

   0x0000054a: b.n 0x54a

End of assembler dump.

 

So, yeah, this was a hardfault, and it loops there to let the debugger gather more info.  I'm not sure if I would be able to figure out what was up, but I know more now!

PS- these days, I've started running into an issue where I wind up at 0x52c, which is the NMI handler.  Anyone know why the SAMB11 might throw an NMI?  The dox are crap.