• State Resolved
  • Locked Locked
  • Replies 29 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 3352 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.

RTOS/TDA2PXEVM: CSI-2 capture on TDA2Px

TG2718
Intellectual 1000 points
Part Number: TDA2PXEVM
Other Parts Discussed in Thread: AWR1243, SYSCONFIG

Tool/software: TI-RTOS

I am using Processor SDK Vision 3.0.3, and a TDA2PxEVM attached to a custom board with AWR1243 radar chips connected via CSI-2 and UB953/UB960 serializer/deserializers. I have configured the AWR1243s, UB953, and UB960 chips, and the UB960 is forwarding data to the processor. However, when attempting to run the radar Capture+Null use-case, no data is collected. I believe this example was originally developed for TDA3x, so perhaps I missed a step in porting it for TDA2Px.

The technical reference manual for the TDA2Px states that VIP3_GCLK is used as functional clock to the CAL module. However, it appears to be on standby. Is that likely to be the issue? If so, how should I enable it?
TDA2Px[0x4A009030] = 0x00040001  CM_CAM_VIP3_CLKCTRL

I believe that the CAL module described in chapter 10 under the Camera Interface Subsystem (CAMSS) is used to read the CSI-2 data in this case (not the ISS Camera Adapter Layer instance CAL_B described in chapter 9). Is this correct?

I would greatly appreciate any suggestions. Please let me know if there is any additional information I can provide that would be helpful.

Thanks.

  • 0
    TI__Mastermind 30245 points
    Todd,

    The first thing to check would be if you are able to access the CAL registers. That would confirm if the module is properly enabled. The next thing to check would be to see if you are seeing any CSI COMPLEXIO errors (CAL_CSI2_COMPLEXIO_IRQSTATUS).

    The CAMSS is the right module.

    Thanks and Regards,
    Piyali
  • 0 in reply to Piyali Goswami
    Intellectual 1000 points

    I am able to access CAL registers. Since that establishes the CAL module is enabled, why does CM_CAM_VIP3_CLKCTRL read 0x00040001 indicating standby?

    Initially, CAL_CSI2_COMPLEXIO_IRQSTATUS read 0x0, but I realized that CAL_CSI2_COMPLEXIO_IRQENABLE_l read 0x0 as well. I enabled all interrupts by setting:
    CAL_CSI2_COMPLEXIO_IRQENABLE_l = 0x5FFFFFFF and
    CAL_CSI2_VC_IRQENABLE_l = 0x3F3F3F3F

    Then I read (TDA2Px[address] = value  register_name):
    TDA2Px[0x489B0308] = 0x00000000  CAL_CSI2_COMPLEXIO_IRQSTATUS
    TDA2Px[0x489B0328] = 0x0F0F0F0F  CAL_CSI2_VC_IRQSTATUS_l

    Here is a dump of other potentially relevant registers:
    TDA2Px[0x489B0010] = 0x00000008  CAL_HL_SYSCONFIG
    TDA2Px[0x489B0100] = 0x0A40C07E  CAL_CTRL
    TDA2Px[0x489B0104] = 0x00000000  CAL_CTRL1
    TDA2Px[0x489B0300] = 0x00000009  CAL_CSI2_PPI_CTRL_l
    TDA2Px[0x489B0304] = 0x6A0DCBA9  CAL_CSI2_COMPLEXIO_CFG_l
    TDA2Px[0x489B0314] = 0x00004197  CAL_CSI2_TIMING_l
    TDA2Px[0x489B0330] = 0x0080012C  CAL_CSI2_CTX0_l
    TDA2Px[0x489B0334] = 0x0080026C  CAL_CSI2_CTX1_l
    TDA2Px[0x489B0338] = 0x008003AC  CAL_CSI2_CTX2_l
    TDA2Px[0x489B033C] = 0x008004EC  CAL_CSI2_CTX3_l
    TDA2Px[0x489B0350] = 0x00000C64  CAL_CSI2_STATUS0_l
    TDA2Px[0x489B0800] = 0x00001058  REG0
    TDA2Px[0x489B0804] = 0xF002E116  REG1
    TDA2Px[0x489B0808] = 0x000000FF  REG2
    TDA2Px[0x4A005110] = 0x00000000  CM_DLL_CTRL
    TDA2Px[0x4A005120] = 0x00000007  CM_CLKMODE_DPLL_CORE
    TDA2Px[0x4A005124] = 0x0000001F  CM_IDLEST_DPLL_CORE
    TDA2Px[0x4A005128] = 0x00000000  CM_AUTOIDLE_DPLL_CORE
    TDA2Px[0x4A00512C] = 0x00010A04  CM_CLKSEL_DPLL_CORE
    TDA2Px[0x4A005130] = 0x00000002  CM_DIV_M2_DPLL_CORE
    TDA2Px[0x4A005170] = 0x00000001  CM_DIV_M2_DPLL_MPU
    TDA2Px[0x4A0056C0] = 0x00000102  CM_EVE3_CLKSTCTRL
    TDA2Px[0x4A0056E0] = 0x00000001  CM_EVE3_EVE3_CLKCTRL
    TDA2Px[0x4A009000] = 0x00001702  CM_CAM_CLKSTCTRL
    TDA2Px[0x4A009004] = 0x00000020  CM_CAM_STATICDEP
    TDA2Px[0x4A009030] = 0x00040001  CM_CAM_VIP3_CLKCTRL
    TDA2Px[0x4A009040] = 0x00040001  CM_CAM_CSI1_CLKCTRL
    TDA2Px[0x4A009048] = 0x00040001  CM_CAM_CSI2_CLKCTRL
    TDA2Px[0x4AE07BC4] = 0x00000037  PM_EVE3_PWRSTST
    TDA2Px[0x4AE07030] = 0x00000000  PM_CAM_VIP3_WKDEP

    What should I check next?

    Thanks for your help!

  • 0 in reply to TG2718
    TI__Genius 12455 points
    Hi Todd,

    Did you check on the lane ordering?

    Regards,
    Sujith
  • 0 in reply to Sujith
    Intellectual 1000 points

    Yes, the lane ordering and polarity has been triple-checked and looks correct.

    CM_IDLEST_DPLL_CORE.ST_DPLL_MODE ==7, which is reserved. Is that OK?

    The capture examples use issCaptureLink, but if I understand correctly, ISS is not involved with CSI-2 capture, and I assume the link configuration reflects this.

    vision_sdk/<my_project>/configs/<my_config>/cfg.mk sets CAL_INCLUDE=yes. It also sets ISS_INCLUDE=yes, which I think could be disabled, but probably doesn't matter.

    Any further ideas of what to check? Thanks!

    Here is a register dump again, this time broken down by bitfields:

    TDA2Px[0x489B0010] = 0x00000008  CAL_HL_SYSCONFIG
	b3:2 = 2  IDLEMODE
	b0 = 0  SOFTRESET
TDA2Px[0x489B0100] = 0x0A40C07E  CAL_CTRL
	b31:24 = 10  MFLAGH
	b22 = 1  RD_DMA_STALL
	b21 = 0  PWRSCPCLK
	b20:13 = 6  MFLAGL
	b12:7 = 0  LL_FORCE_STATE
	b6:5 = 3  BURSTSIZE
	b4:1 = 15  TAGCNT
	b0 = 0  POSTED_WRITES
TDA2Px[0x489B0104] = 0x00000000  CAL_CTRL1
	b5:4 = 0  INTERLEAVE23
	b3:2 = 0  INTERLEAVE01
	b1:0 = 0  PPI_GROUPING
TDA2Px[0x489B0300] = 0x00000009  CAL_CSI2_PPI_CTRL_l
	b3 = 1  FRAME
	b2 = 0  ECC_EN
	b0 = 1  IF_EN
TDA2Px[0x489B0304] = 0x6A0DCBA9  CAL_CSI2_COMPLEXIO_CFG_l
	b30 = 1  RESET_CTRL
	b29 = 1  RESET_DONE
	b28:27 = 1  PWR_CMD
	b26:25 = 1  PWR_STATUS
	b24 = 0  PWR_AUTO
	b19 = 1  DATA4_POL
	b18:16 = 5  DATA4_POSITION
	b15 = 1  DATA3_POL
	b14:12 = 4  DATA3_POSITION
	b11 = 1  DATA2_POL
	b10:8 = 3  DATA2_POSITION
	b7 = 1  DATA1_POL
	b6:4 = 2  DATA1_POSITION
	b3 = 1  CLOCK_POL
	b2:0 = 1  CLOCK_POSITION
TDA2Px[0x489B0308] = 0x00000000  CAL_CSI2_COMPLEXIO_IRQSTATUS
TDA2Px[0x489B030C] = 0x00000000  CAL_CSI2_SHORT_PACKET_l
	b23:0 = 0  SHORT_PACKET
TDA2Px[0x489B0310] = 0x5FFFFFFF  CAL_CSI2_COMPLEXIO_IRQENABLE_l
TDA2Px[0x489B0318] = 0x3F3F3F3F  CAL_CSI2_VC_IRQENABLE_l
TDA2Px[0x489B0328] = 0x0F0F0F0F  CAL_CSI2_VC_IRQSTATUS_l
TDA2Px[0x489B0314] = 0x00004197  CAL_CSI2_TIMING_l
	b15 = 0  FORCE_RX_MODE_IO1
	b14 = 1  STOP_STATE_X16_IO1
	b13 = 0  STOP_STATE_X4_IO1
	b12:0 = 407  STOP_STATE_COUNTER_IO1
TDA2Px[0x489B0330] = 0x0080012C  CAL_CSI2_CTX0_l
	b29:16 = 128  LINES
	b14 = 0  PACK_MODE
	b13 = 0  ATT
	b12:8 = 1  CPORT
	b7:6 = 0  VC
	b5:0 = 44  DT
TDA2Px[0x489B0334] = 0x0080026C  CAL_CSI2_CTX1_l
	b29:16 = 128  LINES
	b14 = 0  PACK_MODE
	b13 = 0  ATT
	b12:8 = 2  CPORT
	b7:6 = 1  VC
	b5:0 = 44  DT
TDA2Px[0x489B0338] = 0x008003AC  CAL_CSI2_CTX2_l
	b29:16 = 128  LINES
	b14 = 0  PACK_MODE
	b13 = 0  ATT
	b12:8 = 3  CPORT
	b7:6 = 2  VC
	b5:0 = 44  DT
TDA2Px[0x489B033C] = 0x008004EC  CAL_CSI2_CTX3_l
	b29:16 = 128  LINES
	b14 = 0  PACK_MODE
	b13 = 0  ATT
	b12:8 = 4  CPORT
	b7:6 = 3  VC
	b5:0 = 44  DT
TDA2Px[0x489B0350] = 0x0000EE98  CAL_CSI2_STATUS0_l
	b15:0 = 61080  FRAME
TDA2Px[0x489B0800] = 0x00001058  REG0
	b24 = 0  HSCLOCKCONFIG
	b15:8 = 16  THS_TERM
	b7:0 = 88  THS_SETTLE
TDA2Px[0x489B0804] = 0xF002E116  REG1
	b29:28 = 3  RESET_DONE_STATUS
	b25 = 0  CLOCK_MISS_DETECTOR_STATUS
	b24:18 = 0  TCLK_TERM
	b17:10 = 184  DPHY_HS_SYNC_PATTERN
	b9:8 = 1  TCLK_DIV
	b7:0 = 22  TCLK_SETTLE
TDA2Px[0x489B0808] = 0x000000FF  REG2
	b31:30 = 0  TRIGGER_CMD_RXTRIGESC0
	b29:28 = 0  TRIGGER_CMD_RXTRIGESC1
	b27:26 = 0  TRIGGER_CMD_RXTRIGESC2
	b25:24 = 0  TRIGGER_CMD_RXTRIGESC3
	b23:0 = 255  CCP2_SYNC_PATTERN
TDA2Px[0x4A003C08] = 0x00000000  CTRL_CORE_SMA_SW_3
	b31 = 0  CAL_BASELINE_EN
	b30 = 0  CAL_TILED_MEMORY_SPACE
	b21 = 0  CSI2_0_XY_IE
	b20 = 0  CSI2_1_XY_IE
	b19 = 0  CSI2_0_XY_PIPD
	b18 = 0  CSI2_1_XY_PIPD
	b17 = 0  CSI2_0_XY_PIPU
	b16 = 0  CSI2_1_XY_PIPU
TDA2Px[0x4A0026DC] = 0xFF000909  CTRL_CORE_CONTROL_CSI
	b31 = 1  CSI0_LANEENABLE4
	b30 = 1  CSI0_LANEENABLE3
	b29 = 1  CSI0_LANEENABLE2
	b28 = 1  CSI0_LANEENABLE1
	b27 = 1  CSI0_LANEENABLE0
	b26 = 1  CSI1_LANEENABLE2
	b25 = 1  CSI1_LANEENABLE1
	b24 = 1  CSI1_LANEENABLE0
	b11 = 1  CSI0_MODE
	b10:9 = 0  CSI0_CAMMODE
	b8 = 1  CSI0_CTRLCLKEN
	b3 = 1  CSI1_MODE
	b2:1 = 0  CSI1_CAMMODE
	b0 = 1  CSI1_CTRLCLKEN
TDA2Px[0x4A005110] = 0x00000000  CM_DLL_CTRL
	b0 = 0  DLL_OVERRIDE
TDA2Px[0x4A005120] = 0x00000007  CM_CLKMODE_DPLL_CORE
	b11 = 0  DPLL_REGM4XEN
	b10 = 0  DPLL_LPMODE_EN
	b8 = 0  DPLL_DRIFTGUARD_EN
	b2:0 = 7  DPLL_EN
TDA2Px[0x4A005124] = 0x0000001F  CM_IDLEST_DPLL_CORE
	b4 = 1  ST_DPLL_INIT
	b3:1 = 7  ST_DPLL_MODE
	b0 = 1  ST_DPLL_CLK
TDA2Px[0x4A005128] = 0x00000000  CM_AUTOIDLE_DPLL_CORE
	b2:0 = 0  AUTO_DPLL_MODE
TDA2Px[0x4A00512C] = 0x00010A04  CM_CLKSEL_DPLL_CORE
	b23 = 0  DPLL_BYP_CLKSEL
	b22 = 0  DCC_EN
	b20 = 0  DPLL_CLKOUTHIF_CLKSEL
	b18:8 = 266  DPLL_MULT
	b6:0 = 4  DPLL_DIV
TDA2Px[0x4A005130] = 0x00000002  CM_DIV_M2_DPLL_CORE
	b9 = 0  CLKST
	b4:0 = 2  DIVHS
TDA2Px[0x4A005170] = 0x00000001  CM_DIV_M2_DPLL_MPU
	b9 = 0  CLKST
	b4:0 = 1  DIVHS
TDA2Px[0x4A0056C0] = 0x00000102  CM_EVE3_CLKSTCTRL
TDA2Px[0x4A0056E0] = 0x00000001  CM_EVE3_EVE3_CLKCTRL
TDA2Px[0x4A009000] = 0x00001702  CM_CAM_CLKSTCTRL
	b12 = 1  CLKACTIVITY_LVDSRX_96M_GFCLK
	b10 = 1  CLKACTIVITY_VIP3_GCLK
	b9 = 1  CLKACTIVITY_VIP2_GCLK
	b8 = 1  CLKACTIVITY_VIP1_GCLK
	b1:0 = 2  CLKTRCTRL
TDA2Px[0x4A009004] = 0x00000020  CM_CAM_STATICDEP
	b28 = 0  VPE_STATDEP
	b27 = 0  L4PER3_STATDEP
	b25 = 0  GMAC_STATDEP
	b22 = 0  EVE4_STATDEP
	b21 = 0  EVE3_STATDEP
	b20 = 0  EVE2_STATDEP
	b19 = 0  EVE1_STATDEP
	b12 = 0  L4CFG_STATDEP
	b5 = 1  L3MAIN1_STATDEP
	b4 = 0  EMIF_STATDEP
	b2 = 0  IVA_STATDEP
TDA2Px[0x4A009030] = 0x00040001  CM_CAM_VIP3_CLKCTRL
	b18 = 1  STBYST
	b17:16 = 0  IDLEST
	b1:0 = 1  MODULEMODE
TDA2Px[0x4A009040] = 0x00040001  CM_CAM_CSI1_CLKCTRL
	b18 = 1  STBYST
	b17:16 = 0  IDLEST
	b1:0 = 1  MODULEMODE
TDA2Px[0x4A009048] = 0x00040001  CM_CAM_CSI2_CLKCTRL
	b18 = 1  STBYST
	b17:16 = 0  IDLEST
	b1:0 = 1  MODULEMODE
TDA2Px[0x4AE07BC4] = 0x00000037  PM_EVE3_PWRSTST
	b25:24 = 0  LASTPOWERSTATEENTERED
	b20 = 0  INTRANSITION
	b5:4 = 3  EVE3_BANK_STATEST
	b2 = 1  LOGICSTATEST
	b1:0 = 3  POWERSTATEST
TDA2Px[0x4AE07030] = 0x00000000  PM_CAM_VIP3_WKDEP
	b9 = 0  WKUPDEP_VIP3_EVE4
	b8 = 0  WKUPDEP_VIP3_EVE3
	b7 = 0  WKUPDEP_VIP3_EVE2
	b6 = 0  WKUPDEP_VIP3_EVE1
	b5 = 0  WKUPDEP_VIP3_DSP2
	b4 = 0  WKUPDEP_VIP3_IPU1
	b2 = 0  WKUPDEP_VIP3_DSP1
	b1 = 0  WKUPDEP_VIP3_IPU2
	b0 = 0  WKUPDEP_VIP3_MPU
TDA2Px[0x4AE07034] = 0x00000101  RM_CAM_VIP3_CONTEXT
	b8 = 1  LOSTMEM_VIP_BANK
	b0 = 1  LOSTCONTEXT_DFF

  • 0 in reply to TG2718
    TI__Genius 12455 points
    Hi, It seems like you are receiving some data (CAL_CSI2_COMPLEXIO_CFG_l.RESET_DONE is set indicating LP transitions have completed & CAL_CSI2_STATUS0_l.FRAME != 0 indicates some frame are being received.) Can you please set CAL_CSI2_CTX0_l.DT = 1 by-passing all DT based filter and check? Regards, Sujith
  • 0 in reply to Sujith
    Intellectual 1000 points
    Hi Sujith,

    I tried recompiling with CAL_CSI2_CTX0_l.DT=1, and also configured the UB960 to only forward 1 channel of data. Reset_done is still set, and frame count is non-zero. However, it acts like before in that I don't see any messages received in the processor. I tried setting breakpoints in IssCaptureLink_drvProcessData() and IssCaptureLink_tskRun(). Is there a better place to check?

    Most of the example use-cases are for TDA3x, not the TDA2Px that we are using. The examples appear to use the ISS/CAL_B. However, TDA2Px appears to define the base address for CAM/CAL. Can I assume that the IssCaptureLink should be able to run on the TDA2Px without significant modification? (We have a custom board with AR1243 chips connected via CSI-2 to UB953/UB960 and into the TDA2Px on the TDA2Px EVM.)

    Thanks for any additional suggestions. I am eager to move beyond this issue...
  • 0 in reply to TG2718
    TI__Genius 12455 points
    Hi Todd,

    Can you check if anything at all is being captured, open a memory browser when capture is running and see if the memory contents change.
    Also, you could put a break point in function vcoreCaptDmaStartCb ()

    Regards,
    Sujith
  • 0 in reply to Sujith
    Intellectual 1000 points
    What memory addresses do you recommend monitoring to catch any response at the lowest possible level?

    I set a breakpoint in ti_components/drivers/pdk_01_09_00_17/packages/ti/drv/vps/src/vpslib/calcore/src/vpscore_calapi.c/vcoreCaptDmaStartCb() but it was not reached.

    That function is also defined in Processor_SDK_Vision_CCS/ti_components/drivers/pdk_01_09_00_17/packages/ti/drv/vps/src/vpslib/isscore/src/vpscore_captureapi.c, but it won't let me set a breakpoint there, saying no code is available. I presume this is expected on the TDA2Px?

    Any other breakpoints or other items to check?

    Thanks.
  • 0 in reply to TG2718
    TI__Genius 12455 points
    Hi Todd,

    You could look at address 0x489B 0204 + (0x10 * 1), register CAL_WR_DMA_ADDR_k. This should hold the destination memory location, where captured data would be written into.

    Regards,
    Sujith
  • 0 in reply to Sujith
    Intellectual 1000 points

    Hi Sujith,

    I am receiving data at the addresses listed in CAL_WR_DMA_ADDR_1-4, and can see data at these memory locations updating sensibly. The chirp parameters look fine too - I haven't scrutinized the radar data itself yet.

    I still can not find any code that responds to the incoming DMA transfers. I see CAL configuration happening when it starts up, but no breakpoints trigger once it is running. I tried setting breakpoints in vcoreCaptDmaStartCb(), vcoreCaptDmaStartCb(), CalEmMasterIsr(), etc. as well as in IssCaptureLink - but none of them ever triggered.

    Are there other tricks needed to get the Capture use-case running on the TDA2Px?

    I would greatly appreciate further help!

    Thanks.

  • 0 in reply to TG2718
    TI__Genius 12455 points
    Hi Todd,

    Can you please check on the interrupt cross-bar, please refer function Bsp_platformTda2xxXbarConfig () in file ti_components\drivers\pdk\packages\ti\drv\vps\src\platforms\src\bsp_platformTda2xx.c

    Check for

    #if defined (SOC_TDA2PX)
    #if defined (VPS_ISS_BUILD)
    /* XBAR CSL_XBAR_ISS_IRQ_INT0 to IPU1_32 */
    BspOsal_irqXbarConnect(CSL_XBAR_INST_IPU1_IRQ_32, CSL_XBAR_EVE3_IRQ_OUT0);

    Regards,
    Sujith
  • 0 in reply to Sujith
    Intellectual 1000 points

    The interrupt cross-bar is setup as follows (IRQ_71 should be configured in our case for the TDA2PX and CAL module, I believe):

    #if defined (SOC_TDA2PX)
#if defined (VPS_ISS_BUILD)
       /* XBAR CSL_XBAR_ISS_IRQ_INT0 to IPU1_32 */
       BspOsal_irqXbarConnect(CSL_XBAR_INST_IPU1_IRQ_32, CSL_XBAR_EVE3_IRQ_OUT0);
#endif
#if defined (VPS_CAL_BUILD)
       BspOsal_irqXbarConnect(CSL_XBAR_INST_IPU1_IRQ_71, CSL_XBAR_CAL_IRQ);
#endif
#endif

    ROV classic indicates that CalEmMasterIsr() is associated with that interrupt, but a breakpoint in CalEmMasterIsr() never triggers. Elsewhere, the code appears to configure that interrupt:

    Vps_commonInit(): Vps_calEmInit(uint32_t numInst, const calemInitParams_t *initPrms) sets it up. initPrms is set to gCalEmInitPrms.irqNum = 71 by VpsHal_getCalEmPlatformData().

    It appears that vpsissCalFrameEventNotifyCfg_t struct configures frame event notifications, which is what seems to be missing.

    VpsDrv_captControl() sets the above config for ISS or CAL (vpsdrv_captureApi.c line 1065):

    case IOCTL_VPS_CAPT_SET_FRAME_EVENT_NOTIFY_PRMS:

    {

    retVal = vpsDrvCaptSetIssSubFrmParams(instObj, (vpsissCalFrameEventNotifyCfg_t*) cmdArgs);

    }

    However, issCaptureLink code does not appear to callVpsDrv_captControl()/IOCTL_VPS_CAPT_SET_FRAME_EVENT_NOTIFY_PRMS at all.

    Can you please clarify how end of frame interrupts/events are supposed to work for issCaptureLink, and what I should do to get it working on the TDA2Px?

    Thanks!

  • 0 in reply to TG2718
    Intellectual 1000 points

    Following up on my previous post, I also tried editing my projects cfg.mk file so CAL_INCLUDE=yes and ISS-INCLUDE=no. Previously, I had CAL_INCLUDE=yes and ISS_INCLUDE=yes. I did not observe any change in behavior as a result of this.

    I am eagerly awaiting further suggestions for how to get the issCaptureLink code to respond to interrupts when CSI-2 frame data is available. Thanks!

  • 0 in reply to TG2718
    TI__Guru**** 476505 points

    Hi Todd,

    As per your above post, it seems that the interrupt cross bar is configured for interrupt 32, whereas CAL event manager is configured for interrupt 71. This could be reason why it never gets triggered. could you please change one of them to keep same interrupt and try it out?

    Rgds,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points
    Hi Brijesh,

    I don't think I understand your comments. The code posted above is from TI's examples without alteration. Aren't the two crossbar configurations independent (different crossbar settings for different interrupts)? Are you suggesting commenting one out, or making them both the same?

    Since then, I rebuilt with ISS-INCLUDE=no, which I believe should only leave me with the CAL settings. Is setting ISS-INCLUDE=no reasonable? It is counter-intuitive, due to the name iss-capture, but the CAL module is used for CSI-2 acquisition on the TDA2Px.

    Thanks for clarifying and for further suggestions.
  • 0 in reply to TG2718
    TI__Guru**** 476505 points
    Hi Todd,

    Oh sorry, i misread above code. Yes, both are configured for the irq number 71.
    I hope that you already checked the PHY reset status and initial handshake for CSI is completed.
    Can you first check CAL RAW status registers and see if any bit is set in any of the RAW_STATUS register? Please check in the CAMSS system.

    Regards,
    Brijesh
  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points

    Hi Brijesh,

    The end of frame status is being set in CAL_HL_IRQSTATUS_RAW_1, and sensible radar data from each chip arrives at the addresses specified in CAL_WR_DMA_ADDR_1-4.

    TDA2Px[0x489B0030] = 0x0000001E  CAL_HL_IRQSTATUS_RAW_1
        b7 = 0  IRQ_WDMA_END7
        b6 = 0  IRQ_WDMA_END6
        b5 = 0  IRQ_WDMA_END5
        b4 = 1  IRQ_WDMA_END4
        b3 = 1  IRQ_WDMA_END3
        b2 = 1  IRQ_WDMA_END2
        b1 = 1  IRQ_WDMA_END1
        b0 = 0  IRQ_WDMA_END0

    However, none of the IRQs appear to be enabled according to CAL_HL_IRQENABLE_SET_1, which is all 0s.

    Interestingly, CAL_HL_IRQSTATUS_2 indicates that WDMA_START IRQs are enabled and interrupts are indicated. This occurs via calls to Vps_calEmEnable(). My understanding is that these interrupts should cause vcoreCaptDmaStartCb() to be called, but it is not called for some reason.

    TDA2Px[0x489B0044] = 0x0000001E  CAL_HL_IRQSTATUS_2
        b7 = 0  IRQ_WDMA_START7
        b6 = 0  IRQ_WDMA_START6
        b5 = 0  IRQ_WDMA_START5
        b4 = 1  IRQ_WDMA_START4
        b3 = 1  IRQ_WDMA_START3
        b2 = 1  IRQ_WDMA_START2
        b1 = 1  IRQ_WDMA_START1
        b0 = 0  IRQ_WDMA_START0

    Shouldn't the issCaptureLink framework track WDMA_END as well?

    Can you please confirm that the build settings of ISS-INCLUDE=no, CAL-INCLUDE=yes should be appropriate for CSI-2 acquisition on the TDA2Px? There are also a bunch of potential build options for the VPS components. For the moment, I have not been explicitly building those libraries - just running gmake -s -j depend prior to building my application. Is that sufficient?

    Any other ideas of what I should try?

    Thanks.

  • 0 in reply to TG2718
    Intellectual 1000 points

    Here is some information to add to the previous post.

    The CAL interrupt is configured for IRQ_71, but it is never called. I looked at the IPU/Cortex-M4 NVIC Interrupt Set-Enable Register at address 0xE000E100+(4*2) and IRQ_71 is not enabled.

    Any idea why the standard issCaptureLink code would not enable the selected interrupt correctly?

    Thanks.

  • 0 in reply to TG2718
    TI__Guru**** 476505 points

    Hi Todd,

    That's strange, can you please put breakpoint in Vps_calEmInit and see if this init api is getting called and is registering irq 71 with BspOsal_registerIntr API? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points

    I confirmed that Vps_calEmInit() is called, and registers IRQ_71 with BspOsal_registerIntr().

    I just realized from the ARM v7-M Architecture Reference Manual that the NVIC defines its internal Interrupt numbers as used in the NVIC_ISER_1 register at address 0xE000E104 differently than I expected. Internal Interrupt # = External Interrupt # (IRQ #) - 16. Therefore, registering IRQ_71 actually sets internal Interrupt 55, and I see this happening.

    It looks like IRQ_71 is properly enabled, so I believe CalEmMasterIsr() should be called at the start of each CSI-2 frame. However, it is never called at all. Why not?

    I tried to force an interrupt by writing to NVIC_ISPR1, but its value is unchanged when I read it back. Am I required to disable interrupts before writing to this register?

    I was able to set IPU1_C0 STIR register (software triggered interrupt request) at 0xE000EF00 to int(55), and this caused CalEmMasterIsr() to run. Could there be some issue related to IPU1_C0 vs IPU1_C1 (the only IPU cores used in the code)? Is there a setting to enable/disable the CAL interrupt line? I believe the crossbar setting is correct.

    Any other suggestions? I really need to get this working soon. Thanks!

  • 0 in reply to TG2718
    Intellectual 1000 points

    I resolved the problem. IRQ_71 was also being used on the other IPU core by default.

  • 0 in reply to TG2718
    TI__Guru**** 476505 points
    Hi Todd,

    Did you change the default sw and used irq 71 on the other IPU? Was this enabled by default?

    Rgds,
    Brijesh
  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points

    Both IPU cores used IRQ 71 by default in the code provided. I changed CAL to something else to avoid the problem.

  • 0 in reply to TG2718
    TI__Guru**** 476505 points
    hi Todd,

    Surprisingly, we did not see this issue in the release code. In the released code, IPU is in SMP mode. Did you change anything?
    I just would like to understand why this is not seen in released code?

    Rgds,
    Brijesh
  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points

    I think this issue is with TI provided code, but I don't know what testing is done for the TDA2Px CAL module.

  • 0 in reply to TG2718
    TI__Guru**** 476505 points
    Hi Todd,

    In the released code, we use IPU2 subsystem, which runs BIOS in SMP mode.
    We have not seen this issue, we are running 2MP 4ch SRV usecase on this setup.
    Have you changed anything on SMP mode? or any other changes?

    Regards,
    Brijesh
  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points

    No, I don't believe I changed SMP or other relevant settings.

  • 0 in reply to TG2718
    TI__Guru**** 476505 points
    Hi Todd,

    This works perfectly fine on released VSDK, so i dont think any issue in VSDK release.
    Anyways, this issue is already resolved.

    Rgds,
    Brijesh
  • 0 in reply to Brijesh Jadav
    Intellectual 1000 points

    I would just reiterate that I do not think the conflict was introduced by my changes.