My image won't come up in App mode, but others will

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I have a Smart Tag that I've been using for development. I'm building an image that acts as the central device for Wiced Sense Kits, connecting to several kits and relaying notification and advertisement data over the PUART.

My image doesn't work in App mode. Instead, the device starts emitting a lot of what appears to be trace data over the HCI UART. I get about a 3 second burst of data every approximately 5 seconds. I'm reasonably sure my app isn't running and causing it because I'm not using any of the trace functions.

I know app mode will work if I set SW4 appropriately because I've loaded and tested other images (the PWM tones image is useful because it's very easy to hear that it is working).

-> Why isn't app mode working for me?

-> What is coming over the HCI UART?

I've attached my source.

0 Likes
1 Solution
Anonymous
Not applicable

Ok, looks like it was something to do with my GATT database struct, I reverted to one from a separate example and my image came up.

Now it's crashing every 4 seconds (still only in app mode), I presume due to the watchdog. I'll open a separate thread to get some documentation on that.

View solution in original post

0 Likes
17 Replies
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

This sounds like watchdog reset or a crash (the WD timer is 4s) and what you see on the UART is most likely the crash dump. Try removing portions of your app and see when it starts working.

0 Likes
Anonymous
Not applicable

Have been trying that, but I've had no luck finding anything that makes any difference.

I start getting data from the HCI UART immediately, well under a second after releasing RESET.

It doesn't help that I can't get any logs out of it in app mode because it doesn't get far enough to bring up the PUART and it falls over faster than I can switch the HCI UART back on SW4 after the device comes out of reset. I have it set up to blink an LED in the client create callback, and it's not even getting that far.

Works 100% fine when it isn't in App mode, though.

0 Likes

Are you using the SiP module? If you are, can you make sure that the platform name in the build string corresponds to the module you are using? So if you are using a 20736S module, you must build with <application_name>-BCM920736TAG_Q32.

0 Likes
Anonymous
Not applicable

I'm going to use the SIP once I have the image stable, but right now I'm running it right on the BCM920737TAG. I have a header in there in place of platform.h, but right now it's just a straight copy of platform.h

0 Likes

Your puart_sprintf() allocates a 512 byte buffer on the stack. The app thread stack is 1024 bytes by default. I don't see this function being called during init, so this is probably not it, but I would recommend that you use a buffer of a 100 or so bytes at most here. Try disabling all traces. If you are using the serial flash for storage, add PLATFORM_NV=SFLASH to your make target (the other apps work, so I assume this is not it either, but just saying).

0 Likes
Anonymous
Not applicable

Yeah, just noticed that and took it down to 128 bytes. You really should have some general docs somewhere - I only knew about the stack limitation because of another forum thread I happened across.

Not using the serial flash for storage. My app is mostly just a hacked-up copy of the proximity_client example.

Again, not even making it to the beginning of client_create, but *only* in app mode.

0 Likes
Anonymous
Not applicable

Come to think of it, none of your watchdog methods are in the docs that came with the SDK. Is there a bunch of documentation somewhere else, or does it just not exist?

0 Likes

We just have the deoxygen based API docs that are provided within the SDK, along with some of the official docs that we make available here on the community.

We try to supplement our official docs with blogs/discussions here on the community.  There is also a larger API document that is being worked on currently, which I feel many will find helpful.

0 Likes
Anonymous
Not applicable

Yeah, that's pretty bleak. An SDK is only as useful as the parts of it I know about and understand, and the Doxygen docs are only useful for remembering the types of arguments to use with a method whose purpose I already understand.

Oh well.

Anyway, any other thoughts on what I could try to get this running in app mode? Can you give me some documentation on the watchdog and its various methods, if such things exist?

0 Likes
Anonymous
Not applicable

Ok, here's some more information.

The traces coming over UART when I try to start the image in app mode are not being decoded by the IDE. I'm running 2.1.1 and I've verified that it does decode trace messages made by other images. These are just raw hex. I've attached a chunk of trace logs that I got right after releasing reset.

(looks like I'll have to attach them to the original post, as the forum won't let me attach to a reply. Please look up there)

0 Likes
Anonymous
Not applicable

Still working on this.

I've found that if I pass a NULL config into bleapp_set_cfg, the device gets through initialization, brings up the PUART, and is generally functional in app mode. In this case, it does time out every four seconds, I presume because without a config there's nothing handling the watchdog.

I've tried using a config verbatim from the hello world client, as well as changing most of the parameters in my own original config, but I can't seem to resolve the issue. What could be happening?

0 Likes
Anonymous
Not applicable

Can I please get some assistance on this? Electric Imp would like to recommend this solution to customers and we can't start until we have a solid example running. This is blocking my team's development.

I need to know what my app is doing (crashing?), why, and why passing a NULL BLE_PROFILE_CFG struct into bleapp_set_cfg lets it run until presumably the watchdog halts the app.

0 Likes
Anonymous
Not applicable

Hello Tom,

  1. Trace your steps back to where the Watchdog was biting you - that will give you some insight to where you went wrong - the Sample Apps have all been verified.
  2. What did you differently from the sample App from which you started?
  3. Did you clear the P_UART interrupt properly in your puart_rx_callback?

I will dig a bit more on this.

Thanks

JT

Anonymous
Not applicable

Thanks for looking into this, JT.

My app is crashing immediately, not because of the watchdog. The only way I can get my app to run long enough to encounter the watchdog is to pass a NULL BLE_PROFILE_CFG to bleapp_set_cfg. If I pass any config into bleapp_set_cfg, my app crashes as soon as I release reset in app mode, but runs fine in download mode.

I've also tried leaving the PUART code out completely. No change.

Thanks,

-Tom

0 Likes
Anonymous
Not applicable

Ok, looks like it was something to do with my GATT database struct, I reverted to one from a separate example and my image came up.

Now it's crashing every 4 seconds (still only in app mode), I presume due to the watchdog. I'll open a separate thread to get some documentation on that.

0 Likes

This thread talks about disabling the watchdog: Increasing/Disabling the watchdog timer

0 Likes
Anonymous
Not applicable

Thanks, just saw that. I tried that but it turns out it's not the watchdog after all. Will have to try and figure out where it's locking up...

0 Likes