• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 442 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1352P: Need help with an exception

hkr
Intellectual 950 points

Part Number: CC1352P
Other Parts Discussed in Thread: SYSBIOS

Hello,

I am using a CC1352P Rev. E in a custom design that runs the BLE Stack with a modified SPPClient.c example.

I am in the middle of upgrading from SDK 2.30 to 2.40, and struggling with an exception for days, so I need your help please how to investigate this further.

This is the error print of the XDC runtime:

ti.sysbios.family.arm.m3.Hwi: line 1148: E_hardFault: FORCED
ti.sysbios.family.arm.m3.Hwi: line 1260: E_usageFault: INVSTATE: Invalid EPSR and instruction combination
Exception occurred in background thread at PC = 0x00000000.
Core 0: Exception occurred in ThreadType_Swi.
Swi name: {unknown-instance-name}, handle: 0x2000fa18.
Swi stack base: 0x20013800.
Swi stack size: 0x800.
R0 = 0x00000000  R8  = 0x00000001
R1 = 0x00000000  R9  = 0x20010460
R2 = 0x0001141a  R10 = 0x00000000
R3 = 0x00000412  R11 = 0x00000000
R4 = 0x2000ef74  R12 = 0x00000000
R5 = 0x20003538  SP(R13) = 0x20013f70
R6 = 0x0001182c  LR(R14) = 0x00027be7
R7 = 0x000005c8  PC(R15) = 0x00000000
PSR = 0x60000000
ICSR = 0x00400803
MMFSR = 0x00
BFSR = 0x00
UFSR = 0x0002
HFSR = 0x40000000
DFSR = 0x00000001
MMAR = 0xe000ed34
BFAR = 0xe000ed38
AFSR = 0x00000000
Terminating execution...

I am using the SPPServer application (again modified) on another device and I have never seen this exception there.

The exception happens after starting the BLE discovering process.

I am using the example project "dmm_154sensor_remote_display_app_CC1352P_2_LAUNCHXL_tirtos_ccs" as a template, so I am using the same compiler flags, same BLE configs, etc. I am using the BLE release config, and hence the internal ROM.

Please help!

Thank you

hkr

  • 0
    Intellectual 950 points
    I found a workaround in the meanwhile and want to let you know. I did not get any further with this exception (which is pretty annoying - what good are exception analysis then?), and started to analyze from within the application code.

    The last action before the exception occurred which I did in the application was a
    GapScan_enable(0, DEFAULT_SCAN_DURATION, 0);
    I am using the following params:
    GapScan_setPhyParams(DEFAULT_SCAN_PHY, SCAN_TYPE_ACTIVE, SCAN_PARAM_DFLT_INTERVAL, SCAN_PARAM_DFLT_INTERVAL);
    Instead of the expected callback event GAP_EVT_SCAN_DISABLED, the exception came.
    I figured out that there are other events one can listen to, and I decided to react to GAP_EVT_SCAN_WND_ENDED instead.
    In this callback, I stop scanning using
    GapScan_disable();
    then wait for the GAP_EVT_SCAN_DISABLED event,
    then restart scanning with
    GapScan_enable(...);
    This is a workaround which works for me. I do not know what happens internally. I only know this has worked with SDK releases 2.20, 2.10, and 1.60, and stopped working with 2.40.
    Also, the exception occurs at a point in time (I verified that roughly by changing the DEFAULT_SCAN_DURATION) when I expected the GAP_EVT_SCAN_DISABLED event, so probably, the exception occurs in the context of this GAP Scanner event.
    I hope you can dig into this.
    hkr
  • 0 in reply to hkr
    TI__Mastermind 23730 points
    Have you checked out the Debugging -> Dechipering CPU Exceptions section in the BLE5-stack User's Guide?

    dev.ti.com/.../
  • 0 in reply to Severin Suveren
    Intellectual 950 points
    Severin,
    thanks for your answer.
    Yes, I read this chapter many times :-) Just it was not this easy because I never got an exact address (BFAR valid)...

    Anyway,
    turns out it was actually a problem with the chip's soldering. In this respect, probably the exception was the best the controller could provide :-) After fixing it, I now get the GAP_EVT_SCAN_DISABLED event as expected.

    -hkr