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.
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.
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.
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
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).
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.
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?
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.
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.
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?
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)
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?
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.
1 of 1 people found this helpful
- 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.
- What did you differently from the sample App from which you started?
- Did you clear the P_UART interrupt properly in your puart_rx_callback?
I will dig a bit more on this.
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.