• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 735 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SimpleBLEPeripheral hangs: loop back to main()

user4228845
Prodigy 120 points
Other Parts Discussed in Thread: CC2541, CC2540

I am a new to the TI BLE stack and IAR, and am probably missing something very obvious. I am just trying to make the SimpleBLEPeripheral work, but it hangs. When I run it in the debugger, then I can see it reaches the GATTServApp_ProcessCharCfg() function call inside the function SimpleProfile_SetParameter() in simpleGATTprofile.c. But from somewhere inside that function call it jumps directly back to the start of main().

Anybody knows what is going on here?

This is such a strange behaviour, that I decided to reinstall the whole stack, and not do any of the changes needed for my own app. The behaviour is still the same. What I did specifically:

- Using IAR version 9.10.1; IAR common components 7.0.6.3257

- Using BLE_CC254x_140

- Opened the SimpleBLEPeripheral workspace in IAR, and let IAR "convert to current version"

- Choose "CC2541" configuration in IAR (I have a custom CC2541 board)

- Did the _NR_OF_VIRTUAL_REGISTERS replacement as described in: http://e2e.ti.com/support/wireless_connectivity/f/538/p/303921/1061642#1061642

- In the preprocessor macros, undefined POWER_SAVING, and redefined HAL_LCD=FALSE

- Note that I did not change any line of code anywhere in the software (except for the required _NR_OF_VIRTUAL_REGISTERS change).

The strangest thing about this is, that if I redefine HAL_LED=TRUE (instead of the default HAL_LED=FALSE), then the hang/loop goes away, and the device seems to be functioning correctly, except that it doesn't advertise (see my other question on that). This is very strange, because the HAL_LED seems to have nothing at all to do with the GATTServApp_ProcessCharCfg call. 

Any help on this would be very much appreciated - I am missing something big, or the TI stack is extremely buggy. 

 

  • 0
    TI__Expert 6505 points
    Hi,

    Are you opening the correct project? You need to open CC2541 Project and not CC2540 mini-DK project.

    Regards,
    Arun
  • 0 in reply to Arun Menon
    Prodigy 120 points

    I opened the workspace that is under CC2541; the file: Projects\ble\SimpleBLEPeripheral\CC2541DB\SimpleBLEPeripheral.eww, and then the CC2541 configuration within that. 

    There is something weird though, don't know whether that is correct. If I look in the IAR file overview, under HAL/Target, it shows only a CC2540EB directory, while in reality there are also the directories: CC2540USB, CC2541ARC, and CC2541ST. Is this correct, and if not, how do I change that?

  • 0 in reply to user4228845
    Prodigy 120 points
    I spent the whole day debugging this. The problems is caused because the IAR linker maps both the virtual register V15 and the XSP to the same memory location. I discovered the problem because the disassembler shows the following when compiling with HAL_LED=TRUE:

    8C 16 MOV V14, R4
    8D 17 MOV V15, R5

    When compiling with HAL_LED=FALSE, the same lines show up as:

    8C 16 MOV V14, R4
    8D 17 MOV XSP(L), R5

    Note the identical opcodes, but the different interpretation by the disassembler. Needless to say, if you want to write to virtual register V15, but write to the XSP instead, things are going to fail in interesting ways....

    I have no idea yet whether it is a fault in the linker, or in the TI configuration files. To be continued.

    It would be really nice if TI would create libraries that actually work without change with the only development environment available for them....
  • 0 in reply to user4228845
    Prodigy 120 points
    This turned out to a combination of a bug in the IAR linker, and the fact that the TI libraries are too old for the current version of IAR. The linker does not recognise that V15 is used in one of the libraries. Therefore, it thinks it is not in use in the application, and the memory location can be used for XSP.
    If you set HAL_LED=TRUE, then an extra library is linked which happens to use V15 as well, and which is detected by the linker, and presto: the problem disappears.

    I have made a work-around by not removing _NR_OF_VIRTUAL_REGISTERS from the *.xcl files altogether, but instead using:
    -Z(DATA)VREG+2=08-7F
    This tells the linker to allocate 2 extra virtual registers that it does not know about.

    But really, TI needs to update their libraries for the latest version of the tool (likely only a couple of hours of work), and/or IAR needs to fix this bug (probably a backward-compatibility problem).