- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have developed a custom board based on the 20732S module and would like to migrate to the 20736S.
I built a few of our boards using the 20736S chip, and am currently trying to get our app to work on them.
I am successfully able to download and run "Hello Sensor" to my board using the 2.1.0 SDK.
However, when I try running my app that I developed in the 1.1.0 SDK, it seems to get what looks like a stack overflow in the create() function.
14:26:14 -
14:26:14 - permission check retCode = 00
14:26:14 - b4
14:26:14 - b400
14:26:14 - HELLO=0
<slight delay>
<booting again...>
14:26:14 -
14:26:14 - 0201060409546167
14:26:14 - 020a02
14:26:14 -
14:26:14 - permission check retCode = 00
14:26:14 - b4
14:26:14 - b400
14:26:14 - HELLO=0
14:26:15 -
14:26:15 - 0201060409546167
14:26:15 - 020a02
14:26:15 -
14:26:15 - permission check retCode = 00
14:26:15 - b4
14:26:15 - b400
14:26:15 - HELLO=0
14:26:15 -
14:26:15 - 0201060409546167
14:26:15 - 020a02
The last line in my create() function calls another function to complete board initialization. If I put a trace directly before that function call, it prints out; but putting a trace at the very start of the other function never prints, and then it reboots.
It's as if calling that function overwrites the stack and crashes the device.
Any ideas what is going on here? Is the application stack on the new SDK smaller than on the old one?
Is there any way to debug this?
void application_create(void)
{
extern UINT32 blecm_configFlag ;
blecm_configFlag |= BLECM_DBGUART_LOG | BLECM_DBGUART_LOG_L2CAP | BLECM_DBGUART_LOG_SMP;
bleprofile_Init(bleprofile_p_cfg);
bleprofile_GPIOInit(bleprofile_gpio_p_cfg);
// Configure battery monitor
blebat_batmon_cfg.fullVoltage = 1800;
blebat_batmon_cfg.emptyVoltage = 0;
blebat_batmon_cfg.shutdownVoltage = 0;
blebat_batmon_cfg.maxLevel = 180;
blebat_Init();
// register connection up and connection down handler.
bleprofile_regAppEvtHandler(BLECM_APP_EVT_LINK_UP, connection_up);
bleprofile_regAppEvtHandler(BLECM_APP_EVT_LINK_DOWN, connection_down);
bleprofile_regAppEvtHandler(BLECM_APP_EVT_ADV_TIMEOUT, advertisement_stopped);
//register to receive write callbacks
legattdb_regWriteHandleCb((LEGATTDB_WRITE_CB)write_handler);
ble_trace0("HELLO=0\n"); // <-- this runs.
// system bootup
boot_start();
}
void boot_start()
{
BLEPROFILE_DB_PDU db_pdu;
UINT8 i;
ble_trace0("HELLO=1\n"); // <-- this never runs.
UINT8 *addr = emconinfo_getAddr();
UINT8 unexpected_boot = 0;
ble_trace0("HELLO1\n");
// Test mode input pin
UINT16 mask[3] = {1<<2,0,0};
gpio_registerForInterrupt(mask, boot_test_mode_button_cb, NULL);
gpio_configurePin(0,2,GPIO_OUTPUT_DISABLE | GPIO_INPUT_ENABLE | GPIO_PULL_UP | GPIO_EN_INT_FALLING_EDGE, 0);
// Clear out any spurious interrupt status.
gpio_clearPinInterruptStatus(0,2);
...
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
boot_start() is already used.
Please try different name for your function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I spoke with the developers and they confirmed that for the most part, 20732S applications should be source code compatible with 20736S/20737S once compiled under the SDK 2.x environment.
There were a couple things that they wanted to point out initially. The first is that you need to change makefile.inc as it is now called makefile.mk and uses a slightly different format.
The source code change is that _write_handler function in 2.x should return an int while it was void returned in SDK 1.x.
They seem to think that there are plenty of samples for both included within the new SDK.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just for the record, in porting from 1.0 to 2.0, there is also a change to the GPIO interrupt handler function prototype, which adds an additional UINT8 argument (although I am not sure what the argument is for).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
> ....which adds an additional UINT8 argument (although I am not sure what the argument is for).
The UINT8 argument is the logical P# that triggered the interrupt.
> ... blecm_DidStackOverflow()
Yes, this is available as an optional patch (include thread_and_mem_mgmt.a to APP_PATCHES_AND_LIBS in the application's makefile). See thread_and_mem_mgmt.h and ota_secure_firmware_upgrade/ws_sec_upgrade_ota.c for an example.
> AES_CMAC()
This is now available only in 20737.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just discovered more info on stack overflow checking and wanted to share this:
In SDK 2.0, you need to call this function:
blecm_StackCheckInit();
In order for the blecm_didStackOverflow() to work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Following up on porting questions, are there replacements in the 2.1 SDK for these functions:
blecm_DidStackOverflow()
AES_CMAC() (which seems to be in the header file but is flagged as unreferenced for the 20736)
BTW, great job on the new SDK it is enormously improved over 1.0!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
boot_start() is already used.
Please try different name for your function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, guys, this was the problem. Now everything works as expected.
I am not sure why this did not generate a linker error though. Interestingly, I think the link was failing partway through because it also generated a super small binary output when it had the multiple declaration.