CC2640: CC2640: firmware download service issue

5t34m

Part Number: CC2640
Other Parts Discussed in Thread: BLE-STACK, , SYSBIOS

Hi,

we want to use firmware donwload bluetooth service within an existing project.

Therefore we try to registrate service via:

registerStat = GATTServApp_RegisterService(suotaAttrTbl,
                                               GATT_NUM_ATTRS(suotaAttrTbl),
                                               GATT_MAX_ENCRYPT_KEY_SIZE,
                                               &suotaCBs);

--> Controller is running but debugger gets stuck at: "xdc_runtimer_error_policySpine__E"

What else do we need to do to get this service registerated?

Thanks

5t34m

over 7 years ago

0 Sean2 over 7 years ago

TI__Mastermind 33460 points

Hi 5t34m,

I am not familiar with the suota service, but we will need the following information to best help you:

- Stack version (i.e. BLE-Stack 2.2.2 ,etc)
- Chip version: please confirm this is for CC2640F128 and not CC2640R2F
- Stack flavor: ble5stack or blestack
- IDE and compiler version (i.e. IAR 8.20.2 or CCS 8.1 + TI ARM Compiler 5.2.6)

When you pause the debugger at the policySpin fxn, do you have a useful callstack?

0 5t34m over 7 years ago in reply to Sean2

TI__Intellectual 1175 points

CC2640R2F
blestack
CCS version: 8.0.0.00016 with Ti arm compiler version: TI v18.1.1.LTS

0 Sean2 over 7 years ago in reply to 5t34m

TI__Mastermind 33460 points

Hello,

Please provide the stack/SDK version number as requested above.

Additionally, please answer as to whether or not a call-stack is available when the error occurs.
Further clarification is also needed on the suota service, as this is not the TI provided OAD service.
Is this a custom service, how is it different? Is the sample app based on simple_peripheral_oad_offchip?

0 user3508444 over 7 years ago in reply to Sean2

Prodigy 100 points

Hello
thanks for your quick answer
The SDK Version/Stack version is 1.50.0.58

Call stack:
Texas Instruments XDS110 USB Debug Probe/Cortex_M3_0 (Suspended)
xdc_runtime_Error_policySpin__E(struct xdc_runtime_Error_Block *, unsigned short, unsigned char *, int, unsigned int, int, int)() at Error.c:178 0x1001C412
xdc_runtime_Error_raiseX__E(struct xdc_runtime_Error_Block *, unsigned short, unsigned char *, int, unsigned int, int, int)() at Error.c:114 0x1001C680
ti_sysbios_family_arm_m3_Hwi_Instance_init__E(struct ti_sysbios_family_arm_m3_Hwi_Object *, int, void (*)(unsigned int), struct ti_sysbios_family_arm_m3_Hwi_Params *, struct xdc_runtime_Error_Block *)() at Hwi.c:144 0x10019FF4
ti_sysbios_family_arm_m3_Hwi_construct(struct ti_sysbios_family_arm_m3_Hwi_Struct *, int, void (*)(unsigned int), struct ti_sysbios_family_arm_m3_Hwi_Params *, struct xdc_runtime_Error_Block *)() at ti.sysbios.family.arm.m3.Hwi_config.c:287 0x1001AAEC
osalRegisterCtrlReadyInt() at ..\SCInterface\scif_osal_tirtos.c:78 0x000000EA
ble_dispatch_liteProcess(unsigned char, unsigned short)() at icall_lite_translation.c:175 0x0000B97C
osal_start_system() at osal.c:1.799 0x00006700
startup_entry(struct _icall_remote_task_arg_t *, void *)() at osal_icall_ble.c:263 0x0000408E
ICall_taskEntry$5(unsigned int, unsigned int)() at icall.c:498 0x0000F524
ti_sysbios_knl_Task_exit__E() at Task.c:455 0x1001B118 (an error occurred: debug info does not indicate the return address)

This suota download service is a bit different to your OAD service but provides the same functionality. We started with your simple peripheral oad offchip example. In this example we implemented and tested the suota service and it was working correctly.

Now we are merging this service (now part of a library project which is working within a modified oad offchip example) into a main application which was based on the simple peripheral app example. The difference as far as i could see is that the bluetooth stack is now linked into the application whereas in the OAD-offchip example the stack is in a seperate flash area. During this merging process i got stucked at this problem.

Best regards
Martin

0 Sean2 over 7 years ago in reply to user3508444

TI__Mastermind 33460 points

Hi Martin,

Thanks for the detailed info. I think we are onto something.
I do have to give you a disclaimer first though: stack library OAD is not currently supported on CC2640R2 SDK 1.50.00.58.
It is theoretically possible if you always send the full merged binary over the air, but I do not believe the OAD image tool has been updated to support this image type or to support the absence of a boundary file. Not sure if you have gotten to this point in the merging/development or overcame it already, but just a heads up.
At this time we highly recommend just using a split image if you wish to do OAD. This is something that is being looked at and scoped for future releases.

That said, I will attempt to support the issue at hand. Here is the interesting part of your callstack, I have annotated it below:
osalRegisterCtrlReadyInt() at ..\SCInterface\scif_osal_tirtos.c:78 0x000000EA --> Here is where things appear to go wrong, the previous call to the BLE-Stack has resulted in a Sensor Controller fxn being called....not good/does seem like expected behavior.
ble_dispatch_liteProcess(unsigned char, unsigned short)() at icall_lite_translation.c:175 0x0000B97C --> stack task is running an API that was dispatched to it by the application. Here is executes the API directly

When the failure is about to occur, can you set a break point at at icall_liteTranslation.c, line 175. At this time what is the value of pMsg->directAPI? I would suspect 0x000000EA based on the callstack above.

A couple questions to further help:

1. Is the failing pMsg->directAPI consistently 0x000000EA or does it change?
2. What does the application thread's callstack look like at the time of the error? You should be able to view this at your breakpoint that I described above? Is it in fact pending on GATTServApp_RegisterService()

0 user3508444 over 7 years ago in reply to Sean2

Prodigy 100 points

Hi Sean

I am aware of the problem with the OAD image tool which should be already fixed (we modified the python script).

I set the breakpoint according to your suggestion but this point is never reached (i can go through the program step by step until BIOS_start() but if i set a breakpoint at the beginning of the task funktion this point is never reached), so i could not find out the value of pMsg->directAPI

Now I removed the complete initialisation of sensor controller (and uart interface) from main and now the program get stuck in GATTServApp_RegisterService after ICall_waitMatch() as a result of a timeout -> ICall_abort() is called, but now in the debugger i am able to step troug the code until this problem occured

Best regards,

Martin

0 Sean2 over 7 years ago in reply to user3508444

TI__Mastermind 33460 points

Hi Martin,

Have you also ported the oad.c file to support images of type stack library? There are some changes required there and in the project files.

Just checking.

Using an unmodified simple_peripheral project (stack library) I am also unable to set a breakpoint in the icall_liteTranslation function.

However, this is is just due to over optimization in the function (project defaults to O4) and usually the optimization can make debugging/breakpoints challenging.

I removed optimization in the icall_lite_translation.c file by right clicking on the file --> properties --> build --> ARM compiler --> optimization --> off

After removing optimization, I was able to set a breakpoint without issue. Note that I have annotated my CCS window to show exactly how I deduced both which stack API is under question and who called it.

Note that the various task callstacks in the bottom right is accessible through ROV --> Task --> Callstacks. Please use ROV2 (tools --> runtime object view) to view this. With an application based on BLE simple peripheral there are only two tasks that will access the stack: user application (simple_peripheral task) and GAPRole (peripheral.c). If you have added more ICall aware tasks, then you may need to check other callstacks too.

Please confirm that you are able to reproduce the above scenario with optimization disabled in the icall_lite_translation.c file.

Once you have confirmed this, we will need to find an inventive way to only break on this function when it is about to fail. icall_liteTranslation() is responsible for matialing every API call so setting a breakpoint for each stack API call until the failure occurs is not feasible (there will be many).

Instead, I recommend this:

1. Revert any changes to the sensor controller code. Leave it in there. Keep your project as is when this was originally reported.

2. Remove optimization in icall_lite_translation.c

3. Run the test again and see if you still are encountering the XDC runtime error.

4. If yes, does it appear that the pMsg->directAPI value is the same every time? Previously this was pointing to your sensor contoller fxn, is this still the case?

5. If the value of pMsg->directAPI is consistent, then you can write a trap case for it. Just modify icall_lite_translation.c to trap when the system is about to fail.

After 1-5 above you should be able to identify exactly the stack API that is causing the error and who is calling it. Furthermore you will know what the ICall layer thinks the pointer should be. Based on this we should be able to work backward to find where the issue is. What I suspect that there is some misconfiguration in the stack/ICall that is causing the directAPI pointer to be incorrectly mapped to your sensor controller fxn.

0 user3508444 over 7 years ago in reply to Sean2

Prodigy 100 points

Hi Sean

i found the solution

The update Service was compiled in a library project. There i had to set STACK_LIBRARY define in the compiler predefined symbols. After that change i was able to include the new update service and it is working as expected.

Thank you for your assistance

Martin

0 Sean2 over 7 years ago in reply to user3508444

TI__Mastermind 33460 points

Hi Martin,

Thank you for following up and I am glad the issue is resolved at this time.
I hope the above response was helpful for your resolving your issue.

I can confirm that not having STACK_LIBRARY defined in your library would cause API translation on the stack side to go very wrong.

Bluetooth®︎

Bluetooth forum

CC2640: CC2640: firmware download service issue