• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 929 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.

DMA glitches when RF stack is running

Oleg Komlev
Expert 1740 points

Other Parts Discussed in Thread: CC2540, CC2541

Hi,

I've tried to produce a code adding SPI slave functionality to SimpleBLEx projects (peripheral for now). The idea is to use twin DMA channels (ch3, ch4) to offload 8051 core as much as possible (with my code, radio stack have hard time working with 1MHz SPI and 32-byte transfers). For simplicity, an extra GPIO pin was used to signal SPI master (C5515 DSP) to perform SPI read transaction. We are using USART0 alternative location on a board.

 

Now the solution itself is

a) initialize DMA channels 3 and 4, ch3 having U0DBUF as target, ch4 having it as source,

b) use DMA ISR which, upon stoppage of either channel will set a flag for this channel and set an event to be processed in SimpleBLEPeripheral_ProcessEvents,

c) the event processing branch that reset the flags and rearms the channels. Before arming ch4, a data buffer is copied to a variable at ch4 source pointer.

All pretty conventional. The problem is occasional glitch that happens randomly, but typically occurs once in 30-100 tranfers. Too bad I have no screenshots from logic analyzer, but the glitch involves either stoppage of DMA transfer in a middle, or substituting data bytes with either zeros or 255s. This definitely has something to do with other timing critical resources, as simply stopping the CC2540 via IAR and then resuming it will cripple radio stack (it stops advertising, which is clearly visible using BLE dongle under Btool) - but at the same time SPI transfers begin to work flawlessly. Event processing definitely works at this time (without it, no channels would be rearmed, hence no DMA transfers would happen).

 

The question is - what kind of timing-critical operation may disrupt DMA transfer in process? I've been hinted that USART0 alternative location shares SS pin with Timer1, but according to IO register, it is placed withing P0_x pins. I'm new to concept of using various HAL layers - does it all mean that I should place a function to process flags from interrupt to some event-processing loop withing HAL tasks? Will high-priority task (processed before HCI) be appropriate, or it will cripple RF part of application? Thanks in advance,

  • 0
    Expert 1685 points

    Hey Oleg, could this be related to the ongoing conversation over here: 

    http://e2e.ti.com/support/low_power_rf/f/538/p/227515/802731.aspx


    I seem to be having a similar problem over UART

  • 0 in reply to Jonathan Cohn
    Expert 1740 points

     Hi, Jonathan

     Looks like it is highly probable. I am using USART as SPI slave endpoint, and CC2540 DMA engine instead of byte-per-byte processing via ISR. But I do have same picture - a few percent of transfers are corrupted, but if the radio is stopped, everything is suddenly fine. Actually, I've started from using single ISRs to push individual bytes into buffer, much like you did. It did not work, too, but I attributed it to strict timing budget - I was using 6 MHz SPI, and it left CC2540 very little time to process interrupt AND keep RF engine and OSAL loop running.

    I do hope that Aslak and other TI guys will look into the issue. My guess is that it is some vulnerability of SimpleBLEx applications if very straightforward ISR is used. TI has stable HostTestRelease, after all, which uses UART as HCI interface. Granted, its stock version acts as GAP central device with no advertising, but it should keep all BLE stack levels below HCI running. Though I admit that prowling through HostTestRelease gave me almost no clues. 

     

  • 0 in reply to Oleg Komlev
    Expert 1685 points

    well good, at least we're in the same boat.  It seems like Nick might know of a fix for version 1.3, but I assume he's off until after vacation.  I guess we'll have to wait and see...

  • 0 in reply to Jonathan Cohn
    Expert 1740 points

    Definitely. An upgrade to interface library would be nice, especially adding SPI support (I hate messing up real-time system with my own low-level code).

     

     For now, might be good idea to look deeper into their examples (HTR and SerialApp) - I suspect that there is some workaround. Or at least we'll be sure that random access to serial port should not be considered reliable if radio is on (which would be shame, but knowing is better than nothing). Will post if any progress happen.

  • 0 in reply to Oleg Komlev
    Guru 31280 points

    Hi Guys,

    Just my 5 cents to conversation...

    Oleg Komlev said:
    especially adding SPI support

     

    In my opinion, such driver would be extremely hard to code, since every single IC with SPI

    interface has different access, so basically writing a general SPI driver is not practical.

    By the way, TI have released "peripheral examples" pack for CC2541 device, one of the

    examples is for SPI.

  • 0 in reply to Igor Sherer
    Expert 1740 points

     Hi,

    Those examples are very helpful - I have used them as a primer (they contain same code as DN113) :) Unfortunately, they give no idea about creating proper HAL-safe implementation.

     

    I agree that creating SPI driver that would fit every protocol may be impractical (every other device uses different protocol, EEPROMs, ). But there is a need for SPI (or USART as a whole, actually) to be safely incorporates into HAL/OSAL event processing, without potentially stopping radio. It is probable that I simply miss some workaround for this problem.