Re: BLE Tiny Unhandled exception

[Cody Smith]

Right now I'm mainly playing around with BLE a bit, so no real BLE apps
planned.  If I have any feedback, I'll certainly pass it along.

Thanks again,

Cody

On Fri, May 6, 2016 at 12:43 PM, will sanfilippo  wrote:

> No problem; glad you got it working. If you have any other questions
> please dont hesitate to ask.
>
> Are you planning on writing any BLE apps? Any feeback you have on the
> process would be great to hear...
>
>
> > On May 6, 2016, at 9:01 AM, Cody Smith  wrote:
> >
> > Hey Will,
> >
> > Thank you for your help.  My bletiny target looks the same as yours,
> except
> > I don't have the -DNIMBLE_OPT_SM=1 cflag.  It appears to be working
> now.  I
> > wasn't creating an image and I hadn't loaded the bootloader.  I'm not
> sure
> > how I missed the information about loading and running the bootloader
> since
> > I see it on the website clearly now.  Perhaps I was in a hurry to play
> with
> > my new toy :)
> >
> > In any case,  I was simply running:
> >
> > newt clean nrf52dk_bletiny
> > newt build nrf52dk_bletiny
> > newt load nrf52dk_bletiny
> >
> > Now I'm loading the bootloader and creating the bletiny image as you
> > suggested.
> >
> > Thanks for your time,
> >
> > Cody
> >
> > On Thu, May 5, 2016 at 4:10 PM, will sanfilippo 
> wrote:
> >
> >> Hello:
> >>
> >> Can you show me your targets? newt target show will do this. Also, can
> you
> >> describe the steps you used to build and load the image on the board?
> There
> >> are different ways to do this but this is what I did:
> >>
> >> newt clean nrf52dk_bletiny
> >> newt build nrf52dk_bletiny
> >> newt create-image nrf52dk_bletiny 0.0.0
> >> newt load nrf52dk_bletiny
> >>
> >> After that gets loaded you can reset the board and bletiny should boot
> >> (assuming you already have the bootloader downloaded).
> >>
> >> I have the latest off develop and I am not seeing the same issue. Here
> is
> >> the target I am building with (I show the bootloader target as well).
> >>
> >> targets/nrf52dk_bletiny
> >>app=apps/bletiny
> >>bsp=hw/bsp/nrf52dk
> >>build_profile=optimized
> >>cflags=-DNIMBLE_OPT_SM=1 -DSTATS_NAME_ENABLE
> >> targets/nrf52dk_boot
> >>app=apps/boot
> >>bsp=hw/bsp/nrf52dk
> >>build_profile=optimized
> >>
> >>
> >>
> >>> On May 5, 2016, at 2:35 PM, Cody Smith  wrote:
> >>>
> >>> Hey Everybody,
> >>>
> >>> I've been working with the nRF52 development board PCA10040 and have
> had
> >>> some issues running the bletiny example app that comes in the repo.  I
> >>> switched to the dev branch of the repo to get the nrf52dk as opposed to
> >> the
> >>> nrf52pdk, but that didn't solve this particular issue (although it did
> >> fix
> >>> a few things).
> >>>
> >>> I got the example code to build and load onto the board, but when it
> >> runs,
> >>> I see the following output printed to the terminal window on my desktop
> >>> (coming over the serial port in Tera Term) continuously.
> >>>
> >>> :Unhandled interrupt (3), exception sp 0x20007fa0
> >>> 0: r0:0x20007fa0  r1:0x200043a0  r2:0x0800  r3:0x0100
> >>> 0: r4:0x200043a0  r5:0x0800  r6:0x0100  r7:0x200043c0
> >>> 0: r8:0x  r9:0x00016047 r10:0x0501 r11:0x
> >>> 0:r12:0x200043c0  lr:0x  pc:0x00016047 psr:0x0501
> >>> 0:ICSR:0x0803 HFSR:0x4000 CFSR:0x8200
> >>> 0:BFAR:0x0800 MMFAR:0x0800
> >>>
> >>> The blinky app was running just fine.  I also see this same thing with
> >> the
> >>> bletest app as well.  Any ideas on what this could be?
> >>>
> >>> Thanks for the help,
> >>>
> >>> Cody
> >>
> >>
>
>

Re: newtmgr protocol, no sequence number

[will sanfilippo]

Sorry for the late response… this looks good to me.
> On May 3, 2016, at 2:49 PM, marko kiiskila  wrote:
> 
> Hi,
> 
> I was going to add a sequence number to message header
> to match responses to requests. It would be better if we
> could detect responses to retransmitted requests, for example.
> 
> I was going steal one byte from nh_id field and have one
> byte worth of sequence number. I feel one byte being
> sufficient width, as I don’t think there would be that many
> outstanding requests at any given time. Just one or two.
> 
> I think keeping the header size as 8 bytes is valuable, as well as
> keeping it a multiple of 4 bytes.
> 
> Here’s the old header:
> struct nmgr_hdr {
>uint8_t nh_op;
>uint8_t nh_flags;
>uint16_t nh_len;
>uint16_t nh_group;
>uint16_t nh_id;
> };
> 
> Here is what the new header would look like:
> struct nmgr_hdr {
>uint8_t  nh_op; /* NMGR_OP_XXX */
>uint8_t  nh_flags;
>uint16_t nh_len;/* length of the payload */
>uint16_t nh_group;  /* NMGR_GROUP_XXX */
>uint8_t  nh_seq;/* sequence number */
>uint8_t  nh_id; /* message ID within group */
> };
> 
> This will break backwards compatibility, when requester starts
> filling in the sequence number.
> 
> Any objections, or other comments?
> 
> I was also going to add a CRC at the end of the message, when
> newtmgr goes over serial line. You can run this protocol over
> UARTs with no flow control, so we should detect errors on this.
> —
> M

Re: callout and callout_func

[Christopher Collins]

I also prefer #2.

Chris

On Fri, May 06, 2016 at 11:31:03AM -0700, will sanfilippo wrote:
> My vote would be #2 as well.
> 
> 
> > On May 6, 2016, at 11:29 AM, marko kiiskila  wrote:
> > 
> > Hi,
> > 
> >> On May 5, 2016, at 10:47 AM, Sterling Hughes  wrote:
> >> 
> >> Salutations,
> >> 
> >> As I've been going through the callout implementation, one thing I've 
> >> noticed is that callouts and callout_funcs can't be interleaved.
> >> 
> >> The implementation of a callout, is that it has an event as the first 
> >> element of the structure.  When that event is posted to an event queue, it 
> >> is posted with the event type EVENT_T_TIMER, which is reserved for 
> >> callouts.  However, you must know a priori what type of callout it is, a 
> >> callout, or a callout_func.
> >> 
> >> I don't think this behavior is ideal, and there are a couple of options 
> >> for fixing it:
> >> 
> >> 1- Break out EVENT_T_TIMER into EVENT_T_TIMER (callout) and 
> >> EVENT_T_TIMER_FUNC (callout_func).
> >> 
> >> 2- Remove the concept of callout, and just have callout_func. callout_func 
> >> is by far the more useful of the two.
> >> 
> >> 3- Add a flags field to callout, which will tell you whether its a callout 
> >> or a callout_func.
> >> 
> >> I'm leaning towards either #2 or #3 here, because I think the first one 
> >> will end up being confusing when debugging things.  "Oh no, I put TIMER 
> >> instead of TIMER_FUNC. GRR."  My personal preference is #2, but I'm not 
> >> sure everyone wants to be forced to have a function per-timer in their 
> >> task context.
> >> 
> >> Thoughts?
> > 
> > I would prefer #2, as that would simplify the concept.
> > 
> > Also, while you have that file cracked open, cf_arg from within 
> > os_callout_func could be removed.
> > os_callout includes os_event, and that structure already has a void * which 
> > could be used as callout_func
> > argument.
> > —
> > M
> 

Re: BLE Tiny Unhandled exception

[will sanfilippo]

No problem; glad you got it working. If you have any other questions please 
dont hesitate to ask.

Are you planning on writing any BLE apps? Any feeback you have on the process 
would be great to hear...


> On May 6, 2016, at 9:01 AM, Cody Smith  wrote:
> 
> Hey Will,
> 
> Thank you for your help.  My bletiny target looks the same as yours, except
> I don't have the -DNIMBLE_OPT_SM=1 cflag.  It appears to be working now.  I
> wasn't creating an image and I hadn't loaded the bootloader.  I'm not sure
> how I missed the information about loading and running the bootloader since
> I see it on the website clearly now.  Perhaps I was in a hurry to play with
> my new toy :)
> 
> In any case,  I was simply running:
> 
> newt clean nrf52dk_bletiny
> newt build nrf52dk_bletiny
> newt load nrf52dk_bletiny
> 
> Now I'm loading the bootloader and creating the bletiny image as you
> suggested.
> 
> Thanks for your time,
> 
> Cody
> 
> On Thu, May 5, 2016 at 4:10 PM, will sanfilippo  wrote:
> 
>> Hello:
>> 
>> Can you show me your targets? newt target show will do this. Also, can you
>> describe the steps you used to build and load the image on the board? There
>> are different ways to do this but this is what I did:
>> 
>> newt clean nrf52dk_bletiny
>> newt build nrf52dk_bletiny
>> newt create-image nrf52dk_bletiny 0.0.0
>> newt load nrf52dk_bletiny
>> 
>> After that gets loaded you can reset the board and bletiny should boot
>> (assuming you already have the bootloader downloaded).
>> 
>> I have the latest off develop and I am not seeing the same issue. Here is
>> the target I am building with (I show the bootloader target as well).
>> 
>> targets/nrf52dk_bletiny
>>app=apps/bletiny
>>bsp=hw/bsp/nrf52dk
>>build_profile=optimized
>>cflags=-DNIMBLE_OPT_SM=1 -DSTATS_NAME_ENABLE
>> targets/nrf52dk_boot
>>app=apps/boot
>>bsp=hw/bsp/nrf52dk
>>build_profile=optimized
>> 
>> 
>> 
>>> On May 5, 2016, at 2:35 PM, Cody Smith  wrote:
>>> 
>>> Hey Everybody,
>>> 
>>> I've been working with the nRF52 development board PCA10040 and have had
>>> some issues running the bletiny example app that comes in the repo.  I
>>> switched to the dev branch of the repo to get the nrf52dk as opposed to
>> the
>>> nrf52pdk, but that didn't solve this particular issue (although it did
>> fix
>>> a few things).
>>> 
>>> I got the example code to build and load onto the board, but when it
>> runs,
>>> I see the following output printed to the terminal window on my desktop
>>> (coming over the serial port in Tera Term) continuously.
>>> 
>>> :Unhandled interrupt (3), exception sp 0x20007fa0
>>> 0: r0:0x20007fa0  r1:0x200043a0  r2:0x0800  r3:0x0100
>>> 0: r4:0x200043a0  r5:0x0800  r6:0x0100  r7:0x200043c0
>>> 0: r8:0x  r9:0x00016047 r10:0x0501 r11:0x
>>> 0:r12:0x200043c0  lr:0x  pc:0x00016047 psr:0x0501
>>> 0:ICSR:0x0803 HFSR:0x4000 CFSR:0x8200
>>> 0:BFAR:0x0800 MMFAR:0x0800
>>> 
>>> The blinky app was running just fine.  I also see this same thing with
>> the
>>> bletest app as well.  Any ideas on what this could be?
>>> 
>>> Thanks for the help,
>>> 
>>> Cody
>> 
>> 

Re: callout and callout_func

[will sanfilippo]

My vote would be #2 as well.


> On May 6, 2016, at 11:29 AM, marko kiiskila  wrote:
> 
> Hi,
> 
>> On May 5, 2016, at 10:47 AM, Sterling Hughes  wrote:
>> 
>> Salutations,
>> 
>> As I've been going through the callout implementation, one thing I've 
>> noticed is that callouts and callout_funcs can't be interleaved.
>> 
>> The implementation of a callout, is that it has an event as the first 
>> element of the structure.  When that event is posted to an event queue, it 
>> is posted with the event type EVENT_T_TIMER, which is reserved for callouts. 
>>  However, you must know a priori what type of callout it is, a callout, or a 
>> callout_func.
>> 
>> I don't think this behavior is ideal, and there are a couple of options for 
>> fixing it:
>> 
>> 1- Break out EVENT_T_TIMER into EVENT_T_TIMER (callout) and 
>> EVENT_T_TIMER_FUNC (callout_func).
>> 
>> 2- Remove the concept of callout, and just have callout_func. callout_func 
>> is by far the more useful of the two.
>> 
>> 3- Add a flags field to callout, which will tell you whether its a callout 
>> or a callout_func.
>> 
>> I'm leaning towards either #2 or #3 here, because I think the first one will 
>> end up being confusing when debugging things.  "Oh no, I put TIMER instead 
>> of TIMER_FUNC. GRR."  My personal preference is #2, but I'm not sure 
>> everyone wants to be forced to have a function per-timer in their task 
>> context.
>> 
>> Thoughts?
> 
> I would prefer #2, as that would simplify the concept.
> 
> Also, while you have that file cracked open, cf_arg from within 
> os_callout_func could be removed.
> os_callout includes os_event, and that structure already has a void * which 
> could be used as callout_func
> argument.
> —
> M

Re: callout and callout_func

[marko kiiskila]

Hi,

> On May 5, 2016, at 10:47 AM, Sterling Hughes  wrote:
> 
> Salutations,
> 
> As I've been going through the callout implementation, one thing I've noticed 
> is that callouts and callout_funcs can't be interleaved.
> 
> The implementation of a callout, is that it has an event as the first element 
> of the structure.  When that event is posted to an event queue, it is posted 
> with the event type EVENT_T_TIMER, which is reserved for callouts.  However, 
> you must know a priori what type of callout it is, a callout, or a 
> callout_func.
> 
> I don't think this behavior is ideal, and there are a couple of options for 
> fixing it:
> 
> 1- Break out EVENT_T_TIMER into EVENT_T_TIMER (callout) and 
> EVENT_T_TIMER_FUNC (callout_func).
> 
> 2- Remove the concept of callout, and just have callout_func. callout_func is 
> by far the more useful of the two.
> 
> 3- Add a flags field to callout, which will tell you whether its a callout or 
> a callout_func.
> 
> I'm leaning towards either #2 or #3 here, because I think the first one will 
> end up being confusing when debugging things.  "Oh no, I put TIMER instead of 
> TIMER_FUNC. GRR."  My personal preference is #2, but I'm not sure everyone 
> wants to be forced to have a function per-timer in their task context.
> 
> Thoughts?

I would prefer #2, as that would simplify the concept.

Also, while you have that file cracked open, cf_arg from within os_callout_func 
could be removed.
os_callout includes os_event, and that structure already has a void * which 
could be used as callout_func
argument.
—
M

Re: BLE Tiny Unhandled exception

[Cody Smith]

Hey Will,

Thank you for your help.  My bletiny target looks the same as yours, except
I don't have the -DNIMBLE_OPT_SM=1 cflag.  It appears to be working now.  I
wasn't creating an image and I hadn't loaded the bootloader.  I'm not sure
how I missed the information about loading and running the bootloader since
I see it on the website clearly now.  Perhaps I was in a hurry to play with
my new toy :)

In any case,  I was simply running:

newt clean nrf52dk_bletiny
newt build nrf52dk_bletiny
newt load nrf52dk_bletiny

Now I'm loading the bootloader and creating the bletiny image as you
suggested.

Thanks for your time,

Cody

On Thu, May 5, 2016 at 4:10 PM, will sanfilippo  wrote:

> Hello:
>
> Can you show me your targets? newt target show will do this. Also, can you
> describe the steps you used to build and load the image on the board? There
> are different ways to do this but this is what I did:
>
> newt clean nrf52dk_bletiny
> newt build nrf52dk_bletiny
> newt create-image nrf52dk_bletiny 0.0.0
> newt load nrf52dk_bletiny
>
> After that gets loaded you can reset the board and bletiny should boot
> (assuming you already have the bootloader downloaded).
>
> I have the latest off develop and I am not seeing the same issue. Here is
> the target I am building with (I show the bootloader target as well).
>
> targets/nrf52dk_bletiny
> app=apps/bletiny
> bsp=hw/bsp/nrf52dk
> build_profile=optimized
> cflags=-DNIMBLE_OPT_SM=1 -DSTATS_NAME_ENABLE
> targets/nrf52dk_boot
> app=apps/boot
> bsp=hw/bsp/nrf52dk
> build_profile=optimized
>
>
>
> > On May 5, 2016, at 2:35 PM, Cody Smith  wrote:
> >
> > Hey Everybody,
> >
> > I've been working with the nRF52 development board PCA10040 and have had
> > some issues running the bletiny example app that comes in the repo.  I
> > switched to the dev branch of the repo to get the nrf52dk as opposed to
> the
> > nrf52pdk, but that didn't solve this particular issue (although it did
> fix
> > a few things).
> >
> > I got the example code to build and load onto the board, but when it
> runs,
> > I see the following output printed to the terminal window on my desktop
> > (coming over the serial port in Tera Term) continuously.
> >
> > :Unhandled interrupt (3), exception sp 0x20007fa0
> > 0: r0:0x20007fa0  r1:0x200043a0  r2:0x0800  r3:0x0100
> > 0: r4:0x200043a0  r5:0x0800  r6:0x0100  r7:0x200043c0
> > 0: r8:0x  r9:0x00016047 r10:0x0501 r11:0x
> > 0:r12:0x200043c0  lr:0x  pc:0x00016047 psr:0x0501
> > 0:ICSR:0x0803 HFSR:0x4000 CFSR:0x8200
> > 0:BFAR:0x0800 MMFAR:0x0800
> >
> > The blinky app was running just fine.  I also see this same thing with
> the
> > bletest app as well.  Any ideas on what this could be?
> >
> > Thanks for the help,
> >
> > Cody
>
>