• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 630 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.

DM8168 processor lockup when accessing EDMA param area.

Graham Newton
Intellectual 460 points
Other Parts Discussed in Thread: CCSTUDIO

We are trying to identify what is causing a processor lockup.  The system boots a Linux kernel and will run normally.  However when an access is made to the on chip EDMA parameter area at address 0x4900 4000  the processor locks up.  The access can be either from a program or driver running on the device or the emulator accessing this area.  Once the lockup has occurred the emulator attached cannot access the device to determine the cause.

We have narrowed down somewhat the point at which access to the memory area will first cause a lock-up. Before this point the area was accessible and functional. But we have not yet identified why it happens or what is causing it.

As far as we can tell no other areas are effected.  For example the EDMA TPCC  registers at 0x4900 0000 are still accessible as are the EDMA TPTCx Registers and associated Param memory areas at base address +0x4000. 

So the question is, from the perspective of the DM8168  what could possibly cause this behaviour of the device locking up by accessing to this on chip memory area?  

Regards

Graham Newton

  • 0
    TI__Guru**** 170625 points

    Graham,

    Are you using EZSDK or DVR RDK or else?

    Are you accessing this 0x49004000 address from u-boot, or from linux kernel or from user space or from CCStudio/JTAG?

    I am using EZSDK 5.05.00.02 with DM816x TI EVM. When I boot up the board, I can successfully access (read/write) the PaRAM0.OPT register (at address 0x49004000) from user space with the devmem2 tool.

    root@dm816x-evm:~# devmem2 0x49004000
    /dev/mem opened.
    Memory mapped at address 0x402ed000.
    Read at address  0x49004000 (0x402ed000): 0x80000000

    On first read access I have bit [31] PRIV = 1 (supervisor level). Then I try to change bit [0] SAM from 0 (INCR mode) to 1 (CONST mode) and I can do this, but as access from user space, bit 31 change also:

    root@dm816x-evm:~# devmem2 0x49004000 w 0x80000001
    /dev/mem opened.
    Memory mapped at address 0x40069000.
    Read at address  0x49004000 (0x40069000): 0x80000000
    Write at address 0x49004000 (0x40069000): 0x80000001, readback 0x80000001
    root@dm816x-evm:~# devmem2 0x49004000
    /dev/mem opened.
    Memory mapped at address 0x4018f000.
    Read at address  0x49004000 (0x4018f000): 0x00000001

    Then I am able to switch back to INCR mode:

    root@dm816x-evm:~# devmem2 0x49004000 w 0x80000000
    /dev/mem opened.
    Memory mapped at address 0x40196000.
    Read at address  0x49004000 (0x40196000): 0x00000001
    Write at address 0x49004000 (0x40196000): 0x80000000, readback 0x80000000
    root@dm816x-evm:~# devmem2 0x49004000            
    /dev/mem opened.
    Memory mapped at address 0x402ce000.
    Read at address  0x49004000 (0x402ce000): 0x00000000

    Make sure also you are using 32-bit access and you have enable to TPCC clock prior access it (CM_ALWON_TPCC_CLKCTRL = 0x2).

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 460 points
    Pavel
    We are using our own board design and a Lauterbach JTAG debugger.
    The lock up was first noticed when setting up the EDMA via the kernel EDMA driver. The same effect was seen accessing the memory from userspace using devmem. And also when trying to access the memory using the JTAG.
    Using the JTAG there is a period during booting the kernel that the EMDA is functioning, i.e. CM_ALWON_TPCC_CLKCTRL is set to 2, and the memory area in question is "alive" and then something happen to cause accesses to that memory area to lock the processor up. All other EDMA registers are still accessible as normal by both via JTAG and devmem provided the area in question is not accessed.
    The JTAG debugger confirms that CM_ALWON_TPCC_CLKCTRL is set to 2.
    I have found that if the clocks are not enabled then a bus error occurs, not a complete processor lockup.
    This was working code so we know it something we have changed and are trying to identify what causes this. Whilst we know roughly when the problem occurs we haven't been able to pin it down to a specific action.
    We are in the process of trying to isolate the offending kernel code but any information as to what would cause the processor to die in such a way would be very helpful.
    Regards
    Graham
  • 0 in reply to Graham Newton
    TI__Guru**** 170625 points
    Graham,

    Are you trying to access the PaRAM0 in the middle of a EDMA transfer?

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 460 points
    Pavel
    It is possible and I am going to check that. However it would be impossible to setup other EDMA channels without access to the param area if this were the case. Previous I have read this area whilst EDMA transactions were in progress to debug issues with incorrect programming of the params area and I was able to read anything I liked either via user space apps or the debugger without anything like this happening.
    However it is a good point and I will check this.
    Regards
    Graham
  • 0 in reply to Graham Newton
    TI__Guru**** 170625 points
    Graham,

    Explore also the PaRAM0.OPT[3] STATIC bit. See TRM, section 5.2.3.6 Parameter Set Updates.

    See also if the below wiki pages will be in help:
    processors.wiki.ti.com/.../TI81XX_PSP_EDMA_Driver_User_Guide
    processors.wiki.ti.com/.../EDMA3

    Check also if this PaRAM0 is reserved for ARM and you are trying to access it from DSP or vice versa.

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 460 points

    After much inverstigation this seems to be caused by a stalled 2 word EDMA transfer between the SD_DATA register in the SD/SDIO peripheral and memory.

    The EDMA event registers (ER) indicate the event has occurred but the interrupt pending registers (IPR) are not set to the contents of the TCC field.  There is also no error indicated.

    The destination memory area is accessible so I'm a still unsure as to why the the DMA does not terminate.

    This is all being done via the ARM.  The DSP is not enabled.