TI-RTOS 2.20.00.06 Exception in SPI driver for CC1310

Chris Hodson

Other Parts Discussed in Thread: SYSBIOS, CC1310

Hi,

I recently upgraded from TI-RTOS 2.16.01.14 to 2.20.00.06. After upgrading to the latest version of SmartRF Studio and recreatign the smartrf_settings.c/.h files (there are some RF command structures that have changed), I rebuilt my project code.

My SPI code that ran ok under 2.16.01.14 is now creating exceptions related to the SPI driver. I am using the SPI in slave mode with callback and have enabled RETURN_PARTIAL, so that the SPI transfer can be terminated on my device when the master de-asserts the chip select line.

I have previously had issues with the TI SPI driver, and had previously received assistance from TI to modify the driver to prevent an exception (hard fault, bus fault, imprecise). A copy of the SPICC26xxDMA.c file had to be taken into the local project and modified. The following check (highlighted in orange) had to be added within the SPICC26XXDMA_csnCallback() function to prevent the exception:

/* Cancel transfer if POSEDGE interrupt */
/* TODO: Consider doing this in a SWI */
if ((csnConfig & PIN_IRQ_POSEDGE) == PIN_IRQ_POSEDGE) {
/* Indicate why the transaction completed */
if (object->currentTransaction != NULL)
{
object->currentTransaction->status = SPI_TRANSFER_CSN_DEASSERT;
}

/* Cancel the current transaction */
SPICC26XXDMA_transferCancel(spiHandle);
}

This resolved my issue and I continued my development.

However, after upgrading to TI-RTOS 2.20.00.06 (which for the record DOES NOT include the modification outlined above ...) I have started to get SPI exceptions again. I have tried the following options for the SPI functionality:

1) Continue to use the 'modified' SPICC26XXDMA.c file from the TI-RTOS version 2.16.01.14

2) Use the new version of the SPICC26XXDMA.c file as supplied in TI-RTOS version 2.20.00.06

3) Use the new version of the SPICC26XXDMA.c file as supplied in TI-RTOS version 2.20.00.06 modified with the patch shown above

All of these options continue to provide exceptions.

I have compared the CC1310DK_7XD.c files from TI-RTOS versions 2.16.01.14 and 2.20.00.06 to ensure that any changes have been implemented into the equivalent file in my project.

Here is the exception information from the CCS (v. 6.1.1.00022) console window:

[Cortex_M3_0] {module#38}: line 1095: error {id:0x130000, args:[0xae6c, 0x0]}
{module#38}: line 1172: error {id:0x150000, args:[0x8458, 0xe000ed38]}
Exception occurred in background thread at PC = 0x00007c1e.
Core 0: Exception occurred in ThreadType_Swi.
Swi name: {unknown-instance-name}, handle: 0x20000f58.
Swi stack base: 0x20003c00.
Swi stack size: 0x400.
R0 = 0x20000f20 R8 = 0x00000000
R1 = 0x00000000 R9 = 0x00000002
R2 = 0x00007bc5 R10 = 0xffffffff
R3 = 0x00000000 R11 = 0xffffffff
R4 = 0x200001c8 R12 = 0x2000230c
R5 = 0x00000000 SP(R13) = 0x20003f90
R6 = 0x00000000 LR(R14) = 0x1001b011
R7 = 0x20000f58 PC(R15) = 0x00007c1e
PSR = 0x61000000
ICSR = 0x00414803
MMFSR = 0x00
BFSR = 0x04
UFSR = 0x0000
HFSR = 0x40000000
DFSR = 0x00000001
MMAR = 0xe000ed34
BFAR = 0xe000ed38
AFSR = 0x00000000
Terminating execution...

and here is the section from the map file that corresponds to the PC given for the exception:

00007a24 000001a0 drivers_cc13xxware.aem3 : PowerCC26XX_calibrateRCOSC.oem3 (.text:PowerCC26XX_doCalibrate)
00007bc4 000001a0 SPICC26XXDMA.obj (.text:SPICC26XXDMA_swiFxn)
00007d64 00000190 drivers_cc13xxware.aem3 : UARTCC26XX.oem3 (.text:UARTCC26XX_open)
00007ef4 00000184 mnet_llc.obj (.text:LLC_initialise)

which indicates that the exception occurs in SPICC26XXDMA_swiFxn

Here is the exception information from the ROV:

Decoded exception,
Decoded,Hard Fault: FORCED: BUSFAULT: IMPRECISERR
Exception context,
$addr,0x20003ec0
$type,ti.sysbios.family.arm.m3.Hwi.ExcContext
threadType,ti.sysbios.BIOS.ThreadType_Swi
threadHandle,0x20000f58
threadStack,0x20003c00
threadStackSize,1024
r0,0x20000f20
r1,0x0
r2,0x7bc5
r3,0x0
r4,0x200001c8
r5,0x0
r6,0x0
r7,0x20000f58
r8,0x0
r9,0x2
r10,0xffffffff
r11,0xffffffff
r12,0x2000230c
sp,0x20003f90
lr,0x1001b011
pc,0x7c1e
psr,0x61000000
ICSR,0x400803
MMFSR,0x0
BFSR,0x4
UFSR,0x0
HFSR,0x40000000
DFSR,0x1
MMAR,0xe000ed34
BFAR,0xe000ed38
AFSR,0x0
Exception call stack,
0 SPICC26XXDMA_swiFxn(unsigned int, unsigned int) at SPICC26XXDMA.c:532,PC = 0x00007C1E FP = 0x20003F90
1 <symbol is not available>,PC = 0x1001B010 FP = 0x20003FB8

And here is the section of my SPICC26XXDMA.c file that corresponds to line 532:

As we have tight timescales for a Beta test release of the project, I am going to return to TI-RTOS 2.16.01.14, but at some point I will need to resolve this issue so that I can move forward to TI-RTOS 2.20.00.06.

If anybody has any suggestions as to how I should proceed with resolving this exception, then they would be gratefully received.

Regards,

Chris

over 9 years ago

0 YiKai Chen over 9 years ago

Guru 735685 points

I would suggest you to post CC1310 related issue to Sub-1 GHz - Proprietary and 15.4 Star networks E2E forum.

0 Richard W. over 9 years ago

TI__Genius 14860 points

Well, it's unrelated to RF and the CC13xx/CC26xx are almost identical, so it doesn't really matter which forum to post to.

Chris, thanks for the detailed error report. This is indeed very frustrating. Does this exception occur for every transfer or just sometimes? If it occurs everytime, can you add a breakpoint at that position and check, whether "object" or "currentTransaction" is null? Your stack looks ok to me.

Can you also enable logging output for the drivers in your .cfg file?

driversConfig.libType = driversConfig.LibType_Instrumented;

0 Chris Hodson over 9 years ago in reply to Richard W.

Prodigy 190 points

I have some more information regarding this post.

In my application I am using the CC1310 device as an interface between an SPI link and a proprietary RF network. Information received over the SPI link (typically at 4Hz) is transmitted onto the wireless network and information received from the wireless network (typically at 1Hz) is passed onto the SPI link. The SPI in the CC1310 is running in slave mode using callbacks and with RETURN_PARTIAL enabled.

Whilst developing the SPI code, a 'dummy' sentence was generated in software to simulate a reception over RF and this was output onto the SPI link. Sentences received over the SPI link were buffered ready for RF transmission, but no transmission was made. This code was developed with TI-RTOS v2.16.01.14 and was working as desired.

The move to TI-RTOS v2.20.01.14 co-incided with the replacement of the dummy SPI sentence by real RF communications on our proprietary network. So now, 'real' sentences received from the RF network are transmitted onto the SPI port and the received SPI sentences are passed onto the wireless network. It is this combined RF and SPI code that causes the exception (which appears to come from the SPI code) after several seconds of correct operation.

When I reverted to TI-RTOS v2.16.00.06, I found that this also generates the exception when the RF code and SPI code are run together.

I have today confirmed that the SPI code using dummy sentences runs correctly with both v2.16.01.14 and v2.20.00.06 of the TI-RTOS.

I have also seen that our radio code runs quite happily on both versions of TI-RTOS when the SPI functionality is not activated, so it seems that the issue I am seeing is not related to having upgraded the TI-RTOS, but rather to having both the RF and SPI code running at the same time.

When both the RF and SPI code is active, the exceptions are not generated immediately. There can be up to 30s of correct operation (RF & SPI) before the exception occurs, so it is not easy to use breakpoints to trap the exception behaviour.

The RF code and SPI code are both running in the same background task. Whilst the RF code is active, a CTS line is asserted to prevent SPI sentences being received from the SPI master.

After the short period of RF comms, the CC1310 is doing very little for the rest of the second, and is dedicated to receiving data over the SPI port. The product is capable of doing bi-directional RF comms and then receiving SPI sentences during the time that the RF code is inactive.

After the receipt of each RF sentence (typically three sentences are received in a 20ms period), the payload of the RF sentence is transmitted over the SPI link. It is this functionality (enabling the transmission over SPI of the data received over RF) leads to the exception. The SPI transmission is much shorter than the radio reception operations (SPI runs at 3.75Mbps and radio runs at 76.8kbaud) so there should be enough time to complete each SPI transmission whilst the next RF sentence is being received.

In summary, the following statements are true for both v2.16.1.14 and v2.20.00.06 of the TI-RTOS:

1) The bi-directional SPI functionality runs as required when the radio code is not active
2) The bi-directional radio code runs as required when the SPI code is not active
3) The bi-directional radio code and SPI receptions (whilst the radio code is inactive) run as required
4) The bi-directional radio code and SPI transmissions of each received RF sentence leads to exceptions

With this additional information, you may feel that it is relevant to move this post to a different forum ... but either way, I would appreciate any input that you can give on what is causing the exceptions when my RF reception and SPI transmissions are interleaved.

I will try instrumenting the code as suggested by Richard above and post additional information that may be useful.

Thanks,

Chris

0 Richard W. over 9 years ago in reply to Chris Hodson

TI__Genius 14860 points

Chris,

thank you very much for the detailed description. It's good that you isolated the bug to concurrent access of RF core and SPI. From your investigation, I would conclude that either the hardware or software interrupt handler of the SPI driver get's delayed here more than it should.

How much are you doing in the callback functions of the RF or the SPI driver? Callbacks of the RF and the SPI driver run as part of an SWI. They are preemptive, but only for different priority levels. By default, all our board files set lowest priorities for both driver HWIs (=~0) and SWIs (=0). The following code snippet is taken from CC1310DK_7XD.c:

const SPICC26XXDMA_HWAttrsV1 spiCC26XXDMAHWAttrs[CC1310DK_7XD_SPICOUNT] = {
    {
        .baseAddr           = SSI0_BASE,
        .intNum             = INT_SSI0_COMB,
        .intPriority        = ~0,
        .swiPriority        = 0,
        .defaultTxBufValue  = 0,
        .powerMngrId        = PowerCC26XX_PERIPH_SSI0,
        .rxChannelBitMask   = 1<<UDMA_CHAN_SSI0_RX,
        .txChannelBitMask   = 1<<UDMA_CHAN_SSI0_TX,
        .mosiPin            = Board_SPI0_MOSI,
        .misoPin            = Board_SPI0_MISO,
        .clkPin             = Board_SPI0_CLK,
        .csnPin             = Board_SPI0_CSN
    },

Please note that the priority order is reverse for SWI and HWI. Please try now to

Raise the SWI priority of the SPI driver:
```
.swiPriority        = 1, // was 0
```
Raise the HWI priority of the SPI driver and then also for the DMA driver:
```
.intPriority        = INT_PRI_LEVEL6, // was INT_PRI_LEVEL7 (~1)
```

Please try these steps separately.

0 Chris Hodson over 9 years ago in reply to Richard W.

Prodigy 190 points

Hi Richard,

Thanks for the suggestions.

Please see the following scope image:

Channel 2 is the Rx activity from the radio (GPO0 driven by the RF core), channel 3 is the time spent in the SPI callback and channel 4 is the time spent in the RF callback. It really doesn't look like there is an issue between the two callback functions.

Here is the equivalent image that is captured when the exception occurs:

There is no obvious issue with the callback functions either getting longer or clashing, so I don't feel that there are any clues here. I'll try adjusting the interrupt priorities as you suggest and let you know if that makes any difference.

Regards,

Chris

0 Chris Hodson over 9 years ago in reply to Chris Hodson

Prodigy 190 points

Hi Richard,

Your first suggested test with changing priorities was to adjust the swi priority of the SPI driver to 1. I tried this and re-ran the code ... and it has now been running for 10 minutes without the exception occurring. I need to do some more thorough testing next week before jumping to anyu conclusions ... but it has certainly made a significant improvement to the behaviour of the code.

Does this imply that the exception was caused by contention between Swis from two different sources that had the same priority level?

Thanks for your assistance.

Regards,

Chris

0 Richard W. over 9 years ago in reply to Chris Hodson

TI__Genius 14860 points

This is an excellent idea! I think you are getting closer. Looks like the RF callbacks in the 3rd RX activity (packet?) are not executed as well. Since you have already included the driver source files into your project: Please move one or two of your test channels to entry and exit of SPICC26XXDMA_swiFxn() and also to swiFxnHw() in the RF driver. Then maybe also to the hwi's to get the full picture.

I wonder if instead of prioritizing the SPI, the RF core handlers must be prioritized.
How does your RX command(s) look like? Are these 3 subsequent RX commands? I assume so because the LNA is disabled after each packet. Therefore, is the RF core maybe running a power cycle? This causes a lot of interrupts and time dependencies.
Do you explicitly set RF_Params::nInactivityTimeout?

Bluetooth®︎

Bluetooth forum

TI-RTOS 2.20.00.06 Exception in SPI driver for CC1310