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.

For loop doesn't enter only in debug mode

Other Parts Discussed in Thread: CCSTUDIO

Hello All,

I am running a code on ARM Cortex A8 using TI code composer.

Upon placing a breakpoint at the following for loop in the edma3resmgr.c file from EDMA package:

for (resMgrIdx = 0u; resMgrIdx < EDMA3_MAX_RM_INSTANCES; resMgrIdx++)
                {
                temp_ptr_rm_inst = ((EDMA3_RM_Instance *)(ptrRMIArray) + (phyCtrllerInstId*EDMA3_MAX_RM_INSTANCES) + resMgrIdx);

                if (NULL != temp_ptr_rm_inst)
                    {
                    if (NULL == temp_ptr_rm_inst->pResMgrObjHandle)
                        {
                        /* Handle to the EDMA3 HW Object */
                        temp_ptr_rm_inst->pResMgrObjHandle = rmObj;
                        /* Handle of the Res Mgr Instance */
                        rmInstance = temp_ptr_rm_inst;

                        /* Also make this data structure NULL, just for safety. */
                        edma3MemZero((void *)((EDMA3_RM_InstanceInitConfig *)(ptrInitCfgArray) + (phyCtrllerInstId*EDMA3_MAX_RM_INSTANCES) + resMgrIdx),
                                    sizeof(EDMA3_RM_InstanceInitConfig));

                        break;
                        }
                    }
                }

            /* Check whether a RM instance has been created or not */
            if (NULL == rmInstance)
                {
                result = EDMA3_RM_E_MAX_RM_INST_OPENED;
                edma3OsProtectExit (phyCtrllerInstId,
                                    EDMA3_OS_PROTECT_INTERRUPT,
                                    intState);

When loading the image using Code Composer, the breakpoint hits and when stepping over, the loop works fine and the rmInstance is initialized well.

However, when I use my bootloader to load and execute the image, the breakpoint hits, but when stepping over, the for loop is skipped, and the execution jumps to if (NULL == rmInstance). Hence the loop is skipped, rmInstance is still NULL, which causes the system to go for exception and halt.

Assembly stepping (in both happy and unhappy scenario) showed me an instruction:

80000c1c:                        9A00002F BLS             $C$DW$L$EDMA3_RM_open$29$E

With happy scenario, it is OK, with unhappy scnario, this instruction causes the jump to the mentioned line

Any idea about that ?

The code is run on A8 core of the VisionMid chip with code composer 5.2.0.00069 with EDMA package version edma3_lld_02_11_04_01

Thank You everybody

  • Hi Ahmed,

    I suspect that when using the CCS (happy) case, your GEL file is initializing your environment better than the bootloader (non happy) case. I will recommend to compare the working case settings (CCS GEL files + C/H files) and non-working case settings (bootloader C/H files).

    Which version of bootloader (u-boot) you are using?

    Check the value of EDMA3_MAX_RM_INSTANCES in working and in non-working case.

    Check the value of temp_ptr_rm_inst in working and in non-working case.

    BR
    Pavel
  • Hi Pavel,

    Thank You for your kind interest.

    The bootloader I use is home-made one, and I've included all the routines existing in the GEL files to the initialization of my bootloader.

    I still didn't get the point that what does the GEL file has to do with a for loop being skipped ? Can you please suggest some points that may cause the loop to skip so that I consider in my investigation ?

    EDMA3_MAX_RM_INSTANCES is always = 8, and the temp_ptr_rm_inst points to valid RM array.
  • Even on atomic level, the instruction BLS moves inside the loop in the good scenario, and skips the loop and jumps to the next block with the bad scenario
  • Ahmed Shokry said:
    The bootloader I use is home-made one, and I've included all the routines existing in the GEL files to the initialization of my bootloader.

    Double check that you do not miss something to include from the official GEL file to your home-made bootloader.

    Ahmed Shokry said:
    I still didn't get the point that what does the GEL file has to do with a for loop being skipped ?

    Are you saying that the for loop is skipped with the GEL file case? From your initial post I understand that the GEL file case works fine (for loop is executed as expected), while bootloader case fail (for loop is skipped).

    Have you test the bootloader case with no breakpoint? Will the bootloader case fail (for loop skipped) if there is no breakpoint?

    BR
    Pavel

  • Ahmed Shokry said:
    if (NULL == temp_ptr_rm_inst->pResMgrObjHandle) { /* Handle to the EDMA3 HW Object */ temp_ptr_rm_inst->pResMgrObjHandle = rmObj; /* Handle of the Res Mgr Instance */ rmInstance = temp_ptr_rm_inst; /* Also make this data structure NULL, just for safety. */ edma3MemZero((void *)((EDMA3_RM_InstanceInitConfig *)(ptrInitCfgArray) + (phyCtrllerInstId*EDMA3_MAX_RM_INSTANCES) + resMgrIdx), sizeof(EDMA3_RM_InstanceInitConfig)); break; }

    Can you also check the value of temp_ptr_rm_inst->pResMgrObjHandle in working and non-working case, is it the same? In the non-working case, can you check if the flow enters in the if (NULL == temp_ptr_rm_inst->pResMgrObjHandle)?

    BR
    Pavel

  • Hello Pavel,

    I am sure that everything in GEL file is copy-pasted into the initialization of the bootloader. I did this task earlier.

    You understand me right, with GEL file, the loop executes.

    However, The point I was missing (just rephrasing it to avoid misunderstanding) is that can I find in the GEL file that - when missing from the bootloader - can affect a for loop and cause its execution to be skipped.

    Testing the bootloader without breakpoints yields that the application is launched, but fails to initialize the DMA. When debugging, I landed on the posted for loop being missed, the then the rmInstance is being used while keeping NULL.

    Thank you very much for your kind support

  • Hello Pavel,

    In Working Scenario:

    temp_ptr_rm_inst->pResMgrObjHandle = NULL, so it enters the if (temp_ptr_rm_inst->pResMgrObjHandle == NULL) and get initialized with rmObj, which equals 0x8022B790

    In Non-working Scenario:

    temp_ptr_rm_inst->pResMgrObjHandle cannot be obtained because temp_ptr_rm_inst is initialized with NULL and the loop doesn't execute, so temp_ptr_rm_inst doesn't update its value and is kept NULL.

    if (NULL == temp_ptr_rm_inst->pResMgrObjHandle) is never hit in the bad scenario because the loop is skipped.

  • Ahmed Shokry said:
    In Non-working Scenario:

    Ahmed Shokry said:
    temp_ptr_rm_inst->pResMgrObjHandle cannot be obtained because temp_ptr_rm_inst is initialized with NULL

    But in one of your previous posts you state that in both cases (working and non-working) temp_ptr_rm_inst points to valid RM array.

    Can you clarify on that point?

    BR
    Pavel

  • Hello Pavel,

    No. In good scenario only.

    Actually ptrRMIArray is the array itself and its address is assigned to temp_ptr_rm_inst in the first line of the loop, so when the loop executes, temp_ptr_rm_inst has valid address and this is the good scenario, when the loop doesn't enter (which is my problem yet), temp_ptr_rm_inst has null pointer and stuff doesn't work well.

  • Ahmed,

    So the problem is in the below line of code:

    temp_ptr_rm_inst = ((EDMA3_RM_Instance *)(ptrRMIArray) + (phyCtrllerInstId*EDMA3_MAX_RM_INSTANCES) + resMgrIdx);

    I can recommend you to check every member of this line and compare between working and non-working case, there should be difference. And when you find the difference, you should debug further to see why there is difference.

    May be also important, are you using the same compiler in working and non-working case?

    BR
    Pavel

  • The execution even doesn't reach this line.

    The breakpoint stops at the for loop line, then stepping over yields skipping the loop and jumping to the line after for block
  • By the way, the following is the assembly instructions associated with for loop header: for (resMgrIdx = 0u; resMgrIdx < EDMA3_MAX_RM_INSTANCES; resMgrIdx++) in the happy scenario:

    for (resMgrIdx = 0u; resMgrIdx < EDMA3_MAX_RM_INSTANCES; resMgrIdx++)
    $C$L31:
    80000c04: $C$L31+0 E3A0C000 MOV R12, #0
    80000c08: E58DC010 STR R12, [R13, #16]
    80000c0c: E59FC7AC LDR R12, $C$CON20
    80000c10: E59D0010 LDR R0, [R13, #16]
    80000c14: E59CC000 LDR R12, [R12]
    80000c18: E15C0000 CMP R12, R0
    80000c1c: 9A00002F BLS $C$DW$L$EDMA3_RM_open$29$E

    While the following is the assembly instructions for the same for loop in the bad scenario:

     714                                       for (resMgrIdx = 0u; resMgrIdx < EDMA3_MAX_RM_INSTANCES; resMgrIdx++)
                                   $C$L31:
    80000c04: $C$L31+0               E3A0C000 MOV             R12, #0
    80000c08:                        E58DC010 STR             R12, [R13, #16]
    80000c0c:                        E59FC7AC LDR             R12, $C$CON20
    80000c10:                        E59D0010 LDR             R0, [R13, #16]
    80000c14:                        E59CC000 LDR             R12, [R12]
    80000c18:                        04B599B4 LDREQT          R9, [R5], #2484
    80000c1c:                        9A00002F BLS             $C$DW$L$EDMA3_RM_open$29$E

    It is clear that there is an extra instruction: 

    80000c18:                        04B599B4 LDREQT          R9, [R5], #2484




    which appears only when I use my bootloader.

    This instruction affects the Z and C flags, and hence affects the decision taken by the last instruction: BLS, which takes the execution out of the loop. Any updates given this new information please ?

  • Ahmed,

    Ahmed Shokry said:
    The execution even doesn't reach this line.

    The breakpoint stops at the for loop line, then stepping over yields skipping the loop and jumping to the line after for block

    You stated in one of your previous posts that EDMA3_MAX_RM_INSTANCES is 8 in both working and non-working case. Can you now check this code:

    resMgrIdx = 0u;

    Verify that in non-working case, resMgrIdx is really initialized with 0.

    BR
    Pavel

  • Ahmed Shokry said:

    It is clear that there is an extra instruction: 

    80000c18:                        04B599B4 LDREQT          R9, [R5], #2484




    which appears only when I use my bootloader.

    Are you using the same toolchain (compiler,linker) for working and non-working case? Sometimes different toolchains generate different assembly code from the same C code. If you are using the same toolchain for both cases, verify that the toolchain settings are the same for both cases.

    BR
    Pavel

  • Yes, EDMA3_MAX_RM_INSTANCES is 8 in both cases.
    and resMgrIdx is 0 in both cases as well
  • Actually I compiled once and got one image which is being tried in the two scenarios: Bootloader (Bad) and CCS Loading (Good)
  • Ahmed Shokry said:
    Actually I compiled once and got one image which is being tried in the two scenarios: Bootloader (Bad) and CCS Loading (Good)

    Let me clarify. You create CCStudio project with GEL file and c/h files and create out file within the CCS environment. And this out file works fine in CCS.

    But the same out file fail in your custom u-boot? You load and run your u-boot and use this out file as a u-boot stand alone application? Can you provide the exact steps to load/run u-boot and then to start this out file?

    BR
    Pavel