• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 945 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.

DSP access to McBSP on DM8168

Solon Despotopoulos
Prodigy 30 points

We are trying to set up the DSP of the DM8168 to access the McBSP. We are working with a JTAG emulator and using our own gel file.

We have enabled the McBSP clock through the gel file (address 0x4818154c) however when we are trying to write any registers (memory locations) with either our program or directly through the Memory Browser of the CCS, the value does not change. For example trying to write 0xFFFF to register RCERA_REG (0x4700 0138) the value 0 does not change. It looks like the whole McBSP interface is not operational. PinMux is configured correctly.

We have tried the same in the EVM816x development board (spectrum digital gel file/software) and the result is the same.

Do we need to activate something else to access the McBSP from the DSP.

Note. In both the Development board and our own board we have managed to work with McASP interfaces.

  • 0
    TI__Guru**** 170625 points

    Hi Solon,

    What is the value of the CM_ALWON_MCBSP_CLKCTRL register (at address 0x4818154C) after you write [1:0] MODULEMODE = 0x2? Do you have [17:16] IDLEST = 0x0? What is the value of the CM_ALWON_L3_SLOW_CLKSTCTRL[12] CLKACTIVITY_MCBSP_AUX_GCLK bit ?

    Can you also try to access the McBSP from Cortex-A8 (instead of the DSP), thus we will be sure whether the problem is in the McBSP or not.

    BR

    Pavel




  • 0 in reply to Pavel Botev
    Prodigy 30 points

    Hi Pavel,

    IDLEST is 0x00 after the activation of the McBSP clock and also the L3 slow clock is activated (bit 12 is 1).

    In the mean time we had some progress with this issue. It turns out that the correct register set to use is the one described at the processor data sheet document SPRS614 revision B (February 2012) and not what is described in document SPRS614 revision D. Also it seems that TRM SPRUGX8 - preliminary edition on 1st July 2011, provides a consistent register mapping to the data sheet revision B. The values that I had initially used were taken from SPRS614 revision D and TRM SPRUGX8 revision A

    After identifying the issue we had a look and our board is build with part number TMS320DM8168BCYG - B indicating a revision B of the DM8168. When reading the JTAG ID register (located at 0x4814 0600) the value written is verified to be 0x2B81 E02F (Silicon Errata document SPRZ329D indicates indeed a revision 2.0 of the chip) 

    Another issue which is also probably relevant is that when checking the XBUFFSTAT_REG register (address 0x4700 00B4) before starting to operate the McBSP shows that the free locations inside the transmit buffer is 0x80 instead of 0x500. This probably relates to the note on the preliminary TRM regarding modules SC_McBSPOCP10GS60 and SC_McBSPOCP20GS60.

    In a  nutshell the processor we have right now is revision B and McBSP should be accessed using the registers described in SPRS614 rev B. McBSP buffer size is 512 Bytes.

    So my question now is :

    Do we assume that all revision B processors behave as above?

    Should we assume that if we read 0x3B81 E02F from the JTAG ID register I can access the McBSP peripheral with the memory map described in SPRS614 rev D and that I will have available 5K receive and transmit buffers?

    Thanks in advance for your help,

    Solon
     

  • 0 in reply to Solon Despotopoulos
    TI__Guru**** 170625 points

    Hi Solon,

    All these three chips (DM814x, DM816x and J5Eco), and all DM816x silicon revisions (1.0, 1.1, 2.0, 2.1)  have MCBSPLP_SCAV10GS70 core. Thus they have McBSP with 512B (128x32-bit) buffers for transmit and receive.This buffer size (512B) is not configurable, it is fixed.

    I have 1.1 revision (DEVICE_ID = 1B81E02F), and I read the reset value of XBUFFSTAT_REG to be 0x80 (512B).

    You are right for the XBUFFSTAT_REG address, the correct address is 0x470000B4 (not 0x470001B4). The DM816x McBSP base address is 0x47000000. For the correct registers offset you can also check the linux kernel source code:

    {EZSDK}/board-support/linux-2.6.37-psp04.04.00.01/arch/arm/plat-omap/include/plat/mcbsp.h

    #define OMAP_MCBSP_REG_XBUFFSTAT    0xB4

    Some source code for McBSP here:

    {EZSDK}/board-support/linux-2.6.37-psp04.04.00.01/arch/arm/plat-omap/mcbsp.c

    Also note that DSP can not access McBSP directly (at physical address 0x47000000), but it should go through the system MMU, which translates the physical addresses to virtual addresses.

    BR

    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 350 points

    Hi,

    Can you please explain how can I configure the mmu to achive direct access to McBSP?

    Thanks,

    Gilad

  • 0 in reply to Pavel Botev

    my chip DM8168 silicon revision is 2.0, and i want to use mcbsp module,the mcbsp register adderess used is in SPRGX8(2011.7),not SPRUGX8A(2012.12)。

    the recieve buffer is 512B in DM8168 2.0,which can write in the document  SPRUGX8A(2012.12)。

    access the registers defined in SPRGX8(2011.7) on the chip 2.0,mcbsp module work normally.