Porting an app from the 20732S to the 20736S

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

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

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);

...

0 Likes
1 Solution
Anonymous
Not applicable

boot_start() is already used.

Please try different name for your function.

View solution in original post

7 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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.

0 Likes

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).

0 Likes

> ....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.

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.

0 Likes

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!

0 Likes
Anonymous
Not applicable

boot_start() is already used.

Please try different name for your function.

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.