• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 765 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.

OMAPL138 McBSP/DMA stability after DEEPSLEEP

Nigel Paton
Intellectual 320 points

Hi,

I am working on a project where we need to put the OMAP into deep sleep to save power. The processor appears to go in and out of deep sleep okay but communication over the McBSP with DMA seems to be unreliable. When it fails only the start of a message is received even though the sender has sent all the data. The McBSP (instance 1) is running at 48MHz and the OMAP at 456MHz (1.3V). I know that there is no data being sent into the OMAP on the McBSP at the time it goes into deep sleep as the last message before the port is blocked at source is the command to go into deep sleep. The port is blocked until we receive a message from the OMAP (over the same McBSP) saying it is awake. After the awake message is received by the controlling system it sends some more messages into the OMAP on the McBSP and it is these that are not fully received. I can connect with a debugger and see no McBSP or DMA errors.

When coming out of deep sleep are there any extra steps needed by the McBSP/DMA devices to allow them to work reliably?

Thanks

Nigel

  • 0
    TI__Guru** 116100 points
    Did you power down the McBSP (module clock) before going to DEEP SLEEP mode ?
    I hope you are shutdown all the peripherals before going to deep sleep mode.
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 320 points

    Hi Titus,

    No I hadn't tried that as that is what I thought DEEP SLEEP does, from spruh77a, section 10.10:

    'This device supports a Deep Sleep mode where all device clocks are stopped and the on-chip oscillator is shut down to save power. Registers and memory contents are preserved, thus, upon recovery, the program may continue from where it left off with minimal overhead involved.'

    Also no mention about this is section 10.10.1.1 (explicitly mentions that USB and SATA should be disabled but not McBSPs).

    But I've now tried it and it does not seem to make any difference.

    The clock for the Rx is coming from the external controller and looks stable during the whole process. One interesting thing is that dropping the data clock rate from 48MHz to 24MHz seems to get rid of the problem but this is too low a frequency for what we need.

    Thanks

    Nigel

  • 0 in reply to Nigel Paton
    TI__Mastermind 35645 points

    Hi,

    For any data instability on C6748 with the as-is on the example "mcbspSampleMaster" (~\ti\biospsp_03_00_01_00\drivers\examples\evm6748\mcbsp\Master\src\mcbspSampleMaster_main.c), kindly refer the below E2E post:

    https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/429267#pi317270=2

    Thanks & regards,

    Sivaraj K

  • 0 in reply to Sivaraj Kuppuraj
    Intellectual 320 points

    Hi Sivaraj,

    Thanks for the reply. This does not appear to be the problem in our case.

    We have now found that the RXFULL flag is being set in the McBSP SPCR register, but there is no error in the DMA controller. The reason we did not notice this before is that opening the debugger window that showed the McBSP registers caused a read of the DRR register which clears the RXFULL error. Once the RXFULL error is cleared everything seems to work again although we have lost some data. So it looks like the DMA has not seen an Rx event from the McBSP/FIFO or the McBSP/FIFO has not issued an Rx event or the DMA is silently failing (or something else).

    As I said in an earlier post lowering the McBSP clock to 24MHz seems to reduce the occurrence of the problem but it still happens.

    Thanks

    Nigel

  • 0 in reply to Nigel Paton
    Intellectual 320 points
    Hi,

    The problem appears to be connected to having an McBSP CLKGDIV value of 0. If it is non-zero (even with the same resulting clock frequency) the problem no longer occurs.

    Posted a separate question on what the relationship is, but no real answer yet:

    e2e.ti.com/.../1759930

    Thanks

    Nigel