This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SVC and fault handling not passed to application

First step of trying to integrate S132 to a small OS is failing completely.

When I use SVC the system ends up in hanging in hard fault.

The SoD handler ends up trying to read branch address from location 0xa891be2c - which causes the hardfault. (The hardfault handler itself has the same problem)

The SoD it not enabled - for now I have just moved the OS to 0x1f000/0x20002128.

Am I supposed to do any initialization for this?

The invalid memory location comes from the SVC handler reading @0x20000000 - why? I would have expected that passing handler is done to fixed vector table address at 0x1f000?

  • I just saw your post here. You are doing a lot more than i thought. You linker script is little cryptic for me

  • I have the softdevice running now and doing BLE advertisements - all fine. I have added the following hack to startup code to initialize locations 0x20000000 and 0x20000004 to the same values the blinky app has on entering C main:

    	; Softdevice initialization hack
    	MOV		R0, #0x20000000
    	MOV		R1, #0x1000
    	STR		R1, [R0],#0x04
    	MOV     R1, #0x1f000
    	STR		R1, [R0]
    

    I just wonder if there is an explanation to why this is necessary.

    I have started the project from scratch.

    I am using IAR EWARM 7.80.1.

  • at 0x20000000 you have MBR vector forwarding address which is 0x1000 where the softdevice is located in flash. at 0x20000004 it is softdevice vector forwarding address which is the starting address of your of you OS (application) in flash. As the names suggest you need these for interrupt forwarding to any place within the flash as these are need to perform OTA DFU .

    Not sure how you managed to corrupt them, but it seems that there is some bug hiding somewhere in your implementation. Can you please dig into you code and see which part of your OS touched 0x20000000 and 0x20000004 just to be sure.

  • They are not touched by my OS. If I set the debugger to "run to main" starting my debugging sessions at C main entry, the values are already corrupt. That is why I added the "Softdevice initialization hack" between the call to "SystemInit" and "__iar_program_start".

    Who is supposed to initialize these two locations - the softdevice or the app?

    Note that I am not linking against any Nordic library components - so if I AM supposed to initialize these I wil just remove the work "hack" from comment :-)

  • Location 0x20000000 is initialized in MBR reset handler and 0x20000004 is initialized by softdevice reset handler. So they should have been initialized before your OS gets to execute its first instruction in reset handler. Instead of running upto main, can you put a breakpoint in your OS reset handler and see if they are corrupt already there? If so, then i would really really like to reproduce this here.

Related