BCP Process Completion Interrupt

Hi Pradeep,

The tests and examples provided with the TCI6618/C6670 PDK under bcp driver demostrate BCP interrupt handling. You should be able to run those tests on Simulator/EVM and understand the receive side interrupt handling process for BCP.

Regards
-Nitin

Hi Nitin,

Thanks for the reply.

I have referred the TI's test project for BCP and we were doing almost eveyrthing that is done over there.

Somehow now we have managed to get the interrupt in the Simulator mode and also the Modulation OP from BCP is verified,

but the issue is when running with EVM, we are running with a Rev1 EVM and facing the same issue of BCP completion interrupt not generated.

Please let me know, if there is anything specific to be done before running the BCP on EVM.

Thanks & regards,

Pradeep P

Hi Pradeep,

Since you mentioned MOD output, I assume the BCP is being used for LTE Downlink processing. Is that correct?

1. Are you using Silicon version 1.0 or 2.0?

2. If the Silicon version is 1.0, is the CRC sub-module being used in your application? Please note that the CRC sub-module can hang on some of the version 1.0 devices and therefore is considered non-functional. Please refer to Advisory 17 of TCI6618 Silicon Errata (http://www.ti.com/lit/er/sprz352c/sprz352c.pdf)

3. If Silicon version is 2.0 or CRC sub-module is not used, the first place to start debugging would be check if the packet is being processed correctly by the BCP. It's important to note that the completion interrupt is generated by Navigator subsystem specifically the accumulator, on receiving an output packet from BCP on the RxQueue, and not the BCP. Disable the accumulator configuration and check the BCP RxQueue count to see if an output packet is received on it using the QMSS Queue Peak region: 0x02a0 + (16 * QueueNum).

4. If the output packet is not received on the Rx Queue, there could be configuration error(s) in the BCP input packet.

5. If the output packet is received on the Rx Queue, then the problem could be in your accumulator configuration.

Regards
-Nitin

Nitin Sakhuja said:

Hi Pradeep,

Since you mentioned MOD output, I assume the BCP is being used for LTE Downlink processing. Is that correct?

Sorry for not mentioning this. Yes I a, using BCP for downlink processing

1. Are you using Silicon version 1.0 or 2.0?

My silicon version is 1.0

2. If the Silicon version is 1.0, is the CRC sub-module being used in your application? Please note that the CRC sub-module can hang on some of the version 1.0 devices and therefore is considered non-functional. Please refer to Advisory 17 of TCI6618 Silicon Errata (http://www.ti.com/lit/er/sprz352c/sprz352c.pdf)

I am aware of this silicon bug in Rev 1.0, so I tried not using the CRC submodule but still not getting the BCP completion interrupt

3. If Silicon version is 2.0 or CRC sub-module is not used, the first place to start debugging would be check if the packet is being processed correctly by the BCP. It's important to note that the completion interrupt is generated by Navigator subsystem specifically the accumulator, on receiving an output packet from BCP on the RxQueue, and not the BCP. Disable the accumulator configuration and check the BCP RxQueue count to see if an output packet is received on it using the QMSS Queue Peak region: 0x02a0 + (16 * QueueNum).

Not applicable as my rev is 1.0

4. If the output packet is not received on the Rx Queue, there could be configuration error(s) in the BCP input packet.

Possible, but how can the same code work when run on simulator?

5. If the output packet is received on the Rx Queue, then the problem could be in your accumulator configuration.

Again, I am confused as the same accumulator configuration is working on the simulator

Regards
-Nitin

Apart from this, when run on the simulator mode, I am configuring the target to be C6670 Cycle approximator (JFYI)

What I would like to know, is, any specific thing to be taken care of when running the code on the EVM, because in my case the code is working fine with all BCP submodules working with output matching with the reference output.

So I suspect, there can be two issues,

1. I am missing something that, needs to be done for the EVM

2. As you said, some issues in the BCP input configuration

What would you suggest me to try?

Thanks in Advance

Pradeep Prabhu

Pradeep,

Can you make sure that you enable BCP power domain your code? It is not required on Simulator but is needed on Silicon. Also, what I mentioned in point 3 is applicable irrespective of the Silicon version so please check the Rx queue as well as I suggested by disabling the accumulator.

Regards

-Nitin

Hi Nitin,

I am doing the enable BCP power domain. 

And regarding #3, are you suggesting to use polling method instead of Rx interrupt method?

If yes, then I have already tried the same. I have set the RxCfg.bUseInterrupts= 0 and also using the APIs Bcp_rxGetNumOutputEntries(), Bcp_recv()

but still no OP from BCP.

Can there be a chance of the BCP input configuration working on Simulator may not work for EVM? I mean the BCP header formation & data packing.

Also to let you know, I am using 2 different buffers for BCP header & data using 2 CPPI descriptors (which are linked during run time)

Anything else you may want to suggest?

Also by any chance do we need to also need to switch the SRIO power domains ON for BCP local operation?(I am not doing a remote device usage?)

Thanks in advance,

Pradeep Prabhu 

Pradeep,

I suggested you to try polling in order to isolate the problem location and to find out if the packet itself is being processed correctly by the BCP.

1. It's evident that that there is some problem with the input packet to begin with since BCP is not generating output on the RxQueue. As such, we should try to resolve the root cause first i.e. get the output from BCP, and then debug the interrupt generation if needed.

2. While the Simulator generates output, it might be reporting errors (which can be seen in the Simulator log, if enabled) that can cause the packet to fail on Silicon.

3. Additionally, The Simulator may not detect all possible error conditions so while a packet works on Simulator, it can fail on Silicon.

4. You can enable the BCP Data Logger in Free Run Mode and enable all data logger interrupts, and capture the data logger RAMS and the value of DLG_WRITE_PTR after the failure happens on Silicon. (BCP Data logger error interrupts are enabled using the core specific INTR_EN_SET_<coreId> registers as given in section 3.4.3.2 under table 3-13 of BCP user guide. For instance, the sub-module specific data logger error interrupts for core-0 can be enabled by setting INTR_EN_SET_0 (offset 0x90) in the sub-module address space. Example: The following statements enables all error interrupts for CRC and ENC on core-0:

*(Uint32 *)(CSL_BCP_CONFIG_REGS + 0x0D90) = 0x1FF; // Enable submodule error interrupts for core 0 (CRC)
*(Uint32 *)(CSL_BCP_CONFIG_REGS + 0x0790) = 0x1FF; // Enable submodule error interrupts for core 0 (ENC)

The corresponding interrupt enabled status can be read using INTR_EN_0 register (offset 0x8C) in the sub-module address space.)

5. It's not possible to list all the things that can go wrong with the input descriptor/packet so I would advise you to provide the following information in order for us to look into the issue:

    (a) BCP Header Descriptor
    (b) BCP Header data Buffer
    (c) BCP Payload Descriptor

Regards
-Nitin

Hi Nitin,

Thanks for your valuable reply.

I will try enabling the data loggers and see, if I can find something useful.

Regarding point 5, I can share you the code through some private channel, if there is a way of private conversation on this forum I can share the code.

Please let me know, if I can do it using private messages or so.

Thanks in advance,

Pradeep Prabhu

Hi Nitin,

Below is a small snippet of code I used for enabling the data logger for each of the BCP submodules in FREE run mode, please let me know, is this correct?

/* Configure the Data logger in free run mode */
*(UINT32 *)(BCP_CRC_DL_CTL_REG_BASE) = 0x4;
*(UINT32 *)(BCP_ENC_DL_CTL_REG_BASE) = 0x4;
*(UINT32 *)(BCP_RM_DL_CTL_REG_BASE) = 0x4;
*(UINT32 *)(BCP_MOD_DL_CTL_REG_BASE) = 0x4;

/* Enable the error interrupts for all DL submodules */
*(UINT32 *)(BCP_CRC_INT_EN_C0_REG_BASE) = 0x1FF;
*(UINT32 *)(BCP_ENC_INT_EN_C0_REG_BASE) = 0x1FF;
*(UINT32 *)(BCP_RM_INT_EN_C0_REG_BASE) = 0x1FF;
*(UINT32 *)(BCP_MOD_INT_EN_C0_REG_BASE) = 0x1FF;

where, the values of these macros are, as below,

#define BCP_CRC_DL_CTL_REG_BASE (CSL_BCP_CONFIG_REGS+0x0D00+0x00F0)
#define BCP_ENC_DL_CTL_REG_BASE (CSL_BCP_CONFIG_REGS+0x0700+0x00F0)
#define BCP_RM_DL_CTL_REG_BASE  (CSL_BCP_CONFIG_REGS+0x0600+0x00F0)
#define BCP_MOD_DL_CTL_REG_BASE (CSL_BCP_CONFIG_REGS+0x0800+0x00F0)

#define BCP_CRC_INT_EN_C0_REG_BASE (CSL_BCP_CONFIG_REGS+0x0D00+0x0090)
#define BCP_ENC_INT_EN_C0_REG_BASE (CSL_BCP_CONFIG_REGS+0x0700+0x0090)
#define BCP_RM_INT_EN_C0_REG_BASE (CSL_BCP_CONFIG_REGS+0x0600+0x0090)
#define BCP_MOD_INT_EN_C0_REG_BASE (CSL_BCP_CONFIG_REGS+0x0800+0x0090)

I tried this code on simulator, but after the BCP processing completion, I checked the data logger status register and found  nothing but 0xFFFFFFFF

Is this the way to enable the data logger? Or some other registers are to be set?

Thanks in Advance,

Pradeep Prabhu

Hi Nitin,

I executed the same code on the EVM and found that, the contents of all DLG status registers is 0x00020000

Referring back to the BCP user guide, 17th bit indicates if the DLG is running or idle. So here Is see the 17th bit set

Is it right?

Pradeep,

1. The Data Logger works only on Silicon so you won't see any valid data in the DLG_RAMS on Simulator.
2. Bit 17 of the DATA_LOGGER_STATUS register is set when an active capture is in progress. If it is set, it means that the logger is capturing data in the sub-module DLG_RAMS.
3. Bit 16 (DLG_MEM_HAS_ERROR) of the DATA_LOGGER_STATUS register is set if there is at least one error stored in any of the DLG_RAMS. If this bit is set, you can look into the DLG_RAMS for the sub-modules used. Check if any of the Bits 88:95 in each 128-bit quad word DLG_RAM entry are set. The interpretation of these error bits is sub-module dependent and details are given in the "Error bit definitions" sections towards the end of  each sub-module.

Regards
-Nitin 

Can help on this problem?

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/293538/1025864.aspx#1025864

Thanks very much  in advanced!

Alan