SimpleLink Academy SNP Example NPITask_Fxn stack problem

Hi,

What's your CCS version? What's the message you are getting?

Hi Jeff,
Could you also provide us with what version of the TI ARM compiler you're using? (Properties > General, Advanced Settings under the Main Tab)
-Rebel

Hi Guys,

Thanks for responding.

The CCS is the latest 6.2.0.00050. The compiler is TI v16.6.0.STS.

XDC Tools version : 3.32.0.06_core.

TI-RTOS for c13xx and c26xx : 2.18.0.03

I have attached some screenshots of the ROV Tasks and BIOS views (taken after I paused in debugger after a few seconds after startup) which may help :

Jeff

Hey Jeff,

In a case like this, I recommend using the version of the compiler that's shown in the dependencies of the SDK: TI ARM Compiler v5.2.6

5.2.6 is the version of the TI ARM Compiler that we test with for that particular version of the SDK. The Software Developer's Guide 2.6.3.2 has information on installing this version.

On a side note: If there's features you need from the newer versions of the compilers, I'd recommend using with Long Term Support (LTS) compilers rather than Short Term Support(STS) Compilers to avoid issues like the ones you ran into.

Thank you for bringing this up! (And the appropriate fix - I know others will find this useful)

Regards,

-Rebel

Hi Rebel,

Thanks for your suggestion. I have downloaded the compiler version 5.2.6 as suggested but it has not fixed the problem (although the issue with the GAPRole Task stack size didn't occur). See the attached screenshots for details:

I also tried the newer SimpleLink Academy updated September 2016 (.09.00.0000) but this made no difference. Interestingly, the simple_np files which are under the SA directory aren't used in the example as the code comes from the BLE Stack example directory.

So if the SA version, BLE Stack version, compiler version and TI-RTOS CC13xx/26xx versions are all as originally used, doesn't this mean that it can only be something about the new version of CCS (6.2.0.00050) and the ROV / debugger code?

Do you have any comments on the errors that appear in the BIOS listing. Why should it think there are invalid read addresses in this example build ? How would changing the compiler version affect this especially as I don't get any build/compilation errors ?

I will try to step through the code to determine where it fails, but I can't find any obvious issues in the map listing at these memory locations.

Thanks.

Jeff

Hey Jeff,

I ran into the same errors as you in regards to ROV. I verified that the NPI stack was not overflown (via memory viewer). There's plenty of space on my end. It's just the ROV utility that seems to be running into problems. To address this problem, I recommend posting this question on the TI RTOS forum: e2e.ti.com/.../355

On the other hand, the SNP and  SAP projects included in the SDK need to be patched in order to function correctly. The SLA version is already patched, and work properly (and even have logging functionality to see where issues occur, saving you some code stepping.

You mentioned using the SLA version of SNP and SAP - and did they work for you on 5.2.6?

In regards to changing the compiler version, it's important to note it's influence on runtime stack/memory usage. Different versions of compilers will interpret the same code but produce different output files. Both will build, and have the same functionality, but how they achieve the functionality may differ (runtime memory useage, code size, etc). In this case, it sounds like you found that the stack size increased on the STS compiler, so I suggested using the one we test with. The heap and stack sizes for the examples were chosen with based on that compiler. (I hope that answers your question)

Regards,

-Rebel

Hey Jeff -

Just a last few notes that hopefully might help:

• SNP and SAP in SLA were designed to be used with the CC2650 not the CC1350

That might have been the reason why you ran into the issue - I had assumed you were using the CC2650. For for the CC1350, you should be ok using the SDK versions. You may need to patch the board file - change:

/* RF hwi and swi priority */
const RFCC26XX_HWAttrs RFCC26XX_hwAttrs = {
    .hwiCpe0Priority = ~0,
    .hwiHwPriority   = ~0,
    .swiCpe0Priority =  0,
    .swiHwPriority   =  0,
};

to

/* RF hwi and swi priority */
const RFCC26XX_HWAttrs RFCC26XX_hwAttrs = {
    .hwiCpe0Priority = ~0,
    .hwiHwPriority   = ~0,
    .swiCpe0Priority =  5,
    .swiHwPriority   =  5,
};

in board_cc1350lp.c. As well as make sure the PIN assignments are correct for your AP. I recommend seeing how the SNP and SAP are done in SLA's CC2650LP projects.

• make sure you're using the latest version of SLA: http://software-dl.ti.com/lprf/simplelink_academy/overview.html

I believe the v1.09 has all the fixes needed to make SNP and SAP work correctly - if it doesn't we'd love to know why to prevent others from running into the same issues. Again, this is if you end up switching over to CC2650.

• Turn off Drawf File Compression for ROV for the App project (right click -> properties -> build -> Arm Linker -> Advanced options -> Linktime optimizations)

The ROV uses the drawf files to pull information, hopefully this will help it out. (I still got the errors on my end, but on other examples it allowed me to see all the RTOS tasks)

Regards,

-Rebel

Hi Rebel,

My reference to the issue with the RF files was not when I used the SNP with the CC1350 but rather when I tried to build the simple BLE peripheral with the latest TI-RTOS library updates (2.20.00.06 and 2.21.00.06) instead of the 2.18.00.03 version. These libraries have modified the RF directory under the Drivers directory and the RF.c file no longer exists and has been replaced with RFCC26XX_multiMode.c and RFCC26XX_singleMode.c files.

In any case, I have tried your suggestion of the dwarf setting but it makes no difference.

I have reverted my CCS to version 6.1.3 and set the XDCTools version to 3.31.3.43 which seemed to remove an error in the simple BLE Peripheral example, but made no difference to the SNP example. I even reverted back to the earliest compatible XDCTools version for the 6.1.3 CCS viz. 3.31.00.24, but it didn't fix the issue of the memory read fail at address 0x20002a38.

I did manage to debug further and found that the system fails with the ROV message when the NPITask_Fxn is created. If I create this task statically then the error message doesn't occur although the program fails during the SNP_initGAP function. It seems to get stuck in the first GAP_SetParamValue function for some reason. This appears to be in the sendWaitMatchCS function because the ICall_getEntityId parameter fails to return a valid entity ID.

I also tried to use a Task_construct function instead of the Task_create function used in the NPITask_open function, but it makes no difference to the memory read address error.

Now that I have managed to overcome the exception in ROV, I will try to revert back to the latest CCS (which I use to build my other Tiva C code) and see if the static NPI task fixes my BLE application-specific NP code. I have built a TivaC-based AP using the NPI to link to the NP on the CC2650 LP and I hope to get it working. I am trying to replace my existing TM4C1294-based board which uses an RN4020 with a CC2640 BLE NP instead.

I had a few problems porting the simple AP code to run on the TivaC mcu because of the differences in the UART driver design but I finally managed to get it working with the standard NP code running on the SmartRF06 emulation board.

Thanks for your help.

Regards,

Jeff

Rebel,

I forgot to mention that I had already updated the SLA to version 1.09.00.0000 but it made no difference to the issue.

I also found on the Eclipse ROV bugzilla site a bug possibly related to this issue : bugs.eclipse.org/.../show_bug.cgi. It appears that ROV doesn't handle heap managers which add new memory address ranges and flags them as invalid and corrupt.

Cheers.

Jeff

Rebel,

I have just reverted my CCS back to 6.2 and am now using the latest compiler revision. I have set the GAPROLE_TASK_STACK_SIZE value (600) to adjust for the increase in size of the gapRole task stack to 516 with the new compiler.

When I use the old version of the RTSC XDCTools (3.31.3.43) I don't get any ROV BIOS errors other than "Error fetching Hwi stack info!" messages which I have been getting all along.

When I use the latest XDCTools (3.32.1.22_core) I now get extra semaphore errors :

I guess I will use the latest version which doesn't cause me grief.

Cheers.

Jeff