You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Szymon Janc <sz...@codecoup.pl> on 2017/02/28 14:51:51 UTC
issue with FCB reboot logs
Hi,
I noticed that some applications (eg bleprhp) enable FCB logging in
syscfg.yml by default.
When flashing such sample on nRF52DK I get assertion [1] before even
main() is reached.
And if I reset a board I get loop of assert and unhandled interrupt
exception [2].
Disabling FCB makes sample works fine. Do I need to do any magic to
get it working
with FCB enabled?
Also, should those be enabled by default in samples in first place?
[1]
1:Assert @ 0x1a393
[2]
1:Assert @ 0x1a38b
1:Unhandled interrupt (2), exception sp 0x20000ba0
1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
1:BFAR:0xe000ed38 MMFAR:0xe000ed34
1:Assert @ 0x1a38b
1:Unhandled interrupt (2), exception sp 0x20000ba0
1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
1:BFAR:0xe000ed38 MMFAR:0xe000ed34
--
pozdrawiam
Szymon K. Janc
Re: issue with FCB reboot logs
Posted by Jacob Rosenthal <ja...@gmail.com>.
This comes up a lot Ive noticed, at least with nrf51. I was thinking that
the bsp could expose an erase for newtmgr for the cases when it does
On Tue, Feb 28, 2017 at 12:24 PM, marko kiiskila <ma...@runtime.io> wrote:
>
> > On Feb 28, 2017, at 7:59 AM, Christopher Collins <ch...@runtime.io>
> wrote:
> >
> > Hi Szymon,
> >
> > On Tue, Feb 28, 2017 at 03:51:51PM +0100, Szymon Janc wrote:
> >> Hi,
> >>
> >> I noticed that some applications (eg bleprhp) enable FCB logging in
> >> syscfg.yml by default.
> >> When flashing such sample on nRF52DK I get assertion [1] before even
> >> main() is reached.
> >> And if I reset a board I get loop of assert and unhandled interrupt
> >> exception [2].
> >>
> >> Disabling FCB makes sample works fine. Do I need to do any magic to
> >> get it working
> >> with FCB enabled?
> >
> > My guess is that there is something else written to the reboot log area.
> > I believe the reboot log package asserts that it initializes
> > successfully. Do you know what code is at the indicated address
> > (0x1a393)?
> >
> > This would be the case if it has been a long time since you erased your
> > device's flash. The flash map changed in an non-backwards-compatible
> > way between 0.9.0 and 1.0.0-b1.
>
> This has gotten on my way few times as well. The flash block assigned
> for reboot log was used for something else for a while (e.g. run without
> bootloader once).
> The init routine in sys/reboot asserts if FCB finds some other data in
> that area.
> I erase that flash sector manually, or the whole flash when I encounter
> this
> assert.
>
> With config fcb, we erase the flash area if we find unexpected data
> in the area. Would folks be ok if I did that for sys/reboot as well?
>
>
> >> Also, should those be enabled by default in samples in first place?
> >
> > Yes, that is probably a good idea IMO.
> >
> > Chris
> >
> >>
> >> [1]
> >> 1:Assert @ 0x1a393
> >>
> >> [2]
> >> 1:Assert @ 0x1a38b
> >> 1:Unhandled interrupt (2), exception sp 0x20000ba0
> >> 1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
> >> 1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
> >> 1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
> >> 1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
> >> 1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
> >> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
> >> 1:Assert @ 0x1a38b
> >> 1:Unhandled interrupt (2), exception sp 0x20000ba0
> >> 1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
> >> 1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
> >> 1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
> >> 1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
> >> 1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
> >> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
> >>
> >>
> >> --
> >> pozdrawiam
> >> Szymon K. Janc
>
>
Re: issue with FCB reboot logs
Posted by marko kiiskila <ma...@runtime.io>.
> On Feb 28, 2017, at 7:59 AM, Christopher Collins <ch...@runtime.io> wrote:
>
> Hi Szymon,
>
> On Tue, Feb 28, 2017 at 03:51:51PM +0100, Szymon Janc wrote:
>> Hi,
>>
>> I noticed that some applications (eg bleprhp) enable FCB logging in
>> syscfg.yml by default.
>> When flashing such sample on nRF52DK I get assertion [1] before even
>> main() is reached.
>> And if I reset a board I get loop of assert and unhandled interrupt
>> exception [2].
>>
>> Disabling FCB makes sample works fine. Do I need to do any magic to
>> get it working
>> with FCB enabled?
>
> My guess is that there is something else written to the reboot log area.
> I believe the reboot log package asserts that it initializes
> successfully. Do you know what code is at the indicated address
> (0x1a393)?
>
> This would be the case if it has been a long time since you erased your
> device's flash. The flash map changed in an non-backwards-compatible
> way between 0.9.0 and 1.0.0-b1.
This has gotten on my way few times as well. The flash block assigned
for reboot log was used for something else for a while (e.g. run without
bootloader once).
The init routine in sys/reboot asserts if FCB finds some other data in that area.
I erase that flash sector manually, or the whole flash when I encounter this
assert.
With config fcb, we erase the flash area if we find unexpected data
in the area. Would folks be ok if I did that for sys/reboot as well?
>> Also, should those be enabled by default in samples in first place?
>
> Yes, that is probably a good idea IMO.
>
> Chris
>
>>
>> [1]
>> 1:Assert @ 0x1a393
>>
>> [2]
>> 1:Assert @ 0x1a38b
>> 1:Unhandled interrupt (2), exception sp 0x20000ba0
>> 1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
>> 1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
>> 1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
>> 1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
>> 1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
>> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
>> 1:Assert @ 0x1a38b
>> 1:Unhandled interrupt (2), exception sp 0x20000ba0
>> 1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
>> 1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
>> 1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
>> 1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
>> 1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
>> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
>>
>>
>> --
>> pozdrawiam
>> Szymon K. Janc
Re: issue with FCB reboot logs
Posted by Szymon Janc <sz...@codecoup.pl>.
Hi Chris,
On 28 February 2017 at 16:59, Christopher Collins <ch...@runtime.io> wrote:
> Hi Szymon,
>
> On Tue, Feb 28, 2017 at 03:51:51PM +0100, Szymon Janc wrote:
>> Hi,
>>
>> I noticed that some applications (eg bleprhp) enable FCB logging in
>> syscfg.yml by default.
>> When flashing such sample on nRF52DK I get assertion [1] before even
>> main() is reached.
>> And if I reset a board I get loop of assert and unhandled interrupt
>> exception [2].
>>
>> Disabling FCB makes sample works fine. Do I need to do any magic to
>> get it working
>> with FCB enabled?
>
> My guess is that there is something else written to the reboot log area.
> I believe the reboot log package asserts that it initializes
> successfully. Do you know what code is at the indicated address
> (0x1a393)?
>
> This would be the case if it has been a long time since you erased your
> device's flash. The flash map changed in an non-backwards-compatible
> way between 0.9.0 and 1.0.0-b1.
Yes, that was this. Although it wasn't due to 0.9.0->1.0.0 but rather flashing
Zephyr. Doing 'nrfjprog --eraseall -f nrf52 before flashing Mynewt did
the trick.
That said, I find asserting and leaving system in unbootable state a bit odd.
--
pozdrawiam
Szymon K. Janc
Re: issue with FCB reboot logs
Posted by Christopher Collins <ch...@runtime.io>.
Hi Szymon,
On Tue, Feb 28, 2017 at 03:51:51PM +0100, Szymon Janc wrote:
> Hi,
>
> I noticed that some applications (eg bleprhp) enable FCB logging in
> syscfg.yml by default.
> When flashing such sample on nRF52DK I get assertion [1] before even
> main() is reached.
> And if I reset a board I get loop of assert and unhandled interrupt
> exception [2].
>
> Disabling FCB makes sample works fine. Do I need to do any magic to
> get it working
> with FCB enabled?
My guess is that there is something else written to the reboot log area.
I believe the reboot log package asserts that it initializes
successfully. Do you know what code is at the indicated address
(0x1a393)?
This would be the case if it has been a long time since you erased your
device's flash. The flash map changed in an non-backwards-compatible
way between 0.9.0 and 1.0.0-b1.
> Also, should those be enabled by default in samples in first place?
Yes, that is probably a good idea IMO.
Chris
>
> [1]
> 1:Assert @ 0x1a393
>
> [2]
> 1:Assert @ 0x1a38b
> 1:Unhandled interrupt (2), exception sp 0x20000ba0
> 1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
> 1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
> 1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
> 1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
> 1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
> 1:Assert @ 0x1a38b
> 1:Unhandled interrupt (2), exception sp 0x20000ba0
> 1: r0:0x00000000 r1:0x00000000 r2:0x80000000 r3:0xe000ed00
> 1: r4:0x0001a38b r5:0x00000000 r6:0x00000000 r7:0x00000000
> 1: r8:0x00000000 r9:0x00000000 r10:0x00000000 r11:0x00000000
> 1:r12:0x00000000 lr:0x00008875 pc:0x00008884 psr:0x61000200
> 1:ICSR:0x00421802 HFSR:0x00000000 CFSR:0x00000000
> 1:BFAR:0xe000ed38 MMFAR:0xe000ed34
>
>
> --
> pozdrawiam
> Szymon K. Janc