always have to restart system after eraseall and firmware download

[Juliusc]

so this is something weird I encountered.

Every time I use an eraseall statement and download my firmware, the chip doesnt start up immediately unless I reset it 4 times. Any idea on this?

[Einar Thorsrud]

Hi,

Seen from the nRF there is nothing that explains why you would need 4 resets. It could be that something happens on external circuitry (that is affected by your firmware running and behaving differently on each iteration based on that), or that you read and write persistent data to flash and act differently on that, for instance. There could also be something else.

To fix the issue, you first need to understand what is going on. To figure that out, I suggest you erase, download firmware, and reset once, then attach your debugger to see what state the device/your firmware is in.

[Juliusc]

Hi I have done that, my firmware halts at this point:

 thought your suggestion on the flash writes might be right since it doesn't happen if I don't erase all data

[Einar Thorsrud]

Hi,

From the call stack I see that you ended up in the hardfault handler. That could be caused by several things, like for instance dereferencing an invalid pointer (or something else). I suggest you start by adding a hardfault handler and take it from there. See for instance How to add the hardfault handler on nRF SDK.

[Juliusc]

 I tried this once but the hardfault handler doesn't trigger although I followed those steps meticulously 

after enabling the hardfault breakpoint the call stack just doesn't show anything any more

[Einar Thorsrud]

That is odd. Alternatively then you can look at what happens before, where you are writing to flash via fstorage. Could it be that some pointer values are wrong for some reason? Are you basing something upon data that will be but have not yet been written to flash, or something else? If it is difficult to find it by inspection, and you cannot get the hardfault handler working, then a third alternative could be to comment out parts of your code and gradually include more to narrow down the problematic part.

[Juliusc]

okay I will try some of these things but I have already gone through these things and the problem is that the hardfault happens on an SVCall. Therefore I can only go to '

sd_ble_gap_adv_start

' and not any further. I am using the peer manager btw so this is something that could fail as well maybe? I am not writing to storage before starting the advertising so this is strange to me as well.  will go through some data that goes into the advertising_init structure but I don't think its a problem in there. 

[Einar Thorsrud]

How have you determined that it happens on an SVCall? And is that the sd_ble_gap_adv_start(), or something else?

Juliusc said:

I am using the peer manager btw so this is something that could fail as well maybe?

The peer manager like any other SW library could fail, but I do think it is premature to blame that at this point (and not very likely). You need to debug to understand what happens (for instance working a bit more with the approaches I have suggested). If this happens consistently after 4 resets it must be that something changes over time, either because of writing to flash, or some external circuitry or something else, so that should give a hint.

[Juliusc]

So I found out it doesnt actually happen at that SVCALL but rather somewhere before (I just put in a delay before starting my advertising)  and got the hardfault at that place. How do I find out whats written in the triggered event?:

thanks for your help already, I appreciate your quick responses!

[Einar Thorsrud]

Can you try again to get the hardfault handler working? Without it, perhaps ti would make sense to try to log or inspect the parameters you provide to fstorage. Could there be corrupt pointers, for instance? Coming from some data that is stored in flash (as you see changes after a certain number of resets, these changes must be stored in something persistent, like flash)?