CLA - skipping 'for-loop' indices

Robert,

Our expert will get back to you on this query.

Hi Robert, 

If you resume (F8) do you endup back at the mdebug stop?  If it does then the middle for loop made it to 3.   

I suspect it may have to do with source code debug with optimization on.  This can make it look like the PC is jumping to odd locations when it is not.  You can try looking at the disassembly (view->disassembly) window to try and workout where the code is going.  

Regards

Lori

Hi Lori,

The outer loop is 9, the inner 4.  When hitting F8, it does all outer 9, but with only a single inner iteration (idx_samp = 0) for each.  It stops at a different __mdebugstop() after the double loops.

I did a bit more debugging.  Both loops will work fully (outer all 9, inner all 4), if I cut down what is being done inside the inner loop.  But once putting back full calculations, it only does that single inner loop again.

I've also attached the disassembly surrounding that inner loop, in the work vs not-work case below.  First is not-work, second is working.  I'm still coming up to speed on the CLA assembly, but would appreciate your read on it.

Also, is there a way to step through the CLA assembly?  When in the disassembly window, F5 or F6 takes me to the next C line in the source window, so I'm not able to step through the individual assembly instructions associated with each C line.

Thanks,

Robert

Robert, 

To step through assembly use the green controls in the toolbar as shown below:

I'll take a look at the assembly and get back to you. 

Regards

Lori

Robert Wolfe said:

Both loops will work fully (outer all 9, inner all 4), if I cut down what is being done inside the inner loop. 

This leads me to wonder if it is a code-size issue.  For example, the size of the task/CLA code has grown past the end of the physical memory block and the next block was not assigned to the CLA by the C28x.  Double check the memory map (.map) file to view the size of the code and the C28x initialization to make sure all blocks needed to run the code are assigned to the CLA. 

Thanks for the idea, but I did that check, and it doesn't appear to be the issue.  LS3 is assigned for CLA run, 0x9800 to 0x9ffff.  CLA code is using through 0x9dbc.  Also, after further debug, it wasn't so much how much code was in the inner loop, but how it was arranged, in what manner the CLA variable were accessed or used.  After a day or two, I never quite was able to determine any pattern, to avoid or use.  I've since unrolled the inner loop, out of need to make progress, but at the cost of expanded code size (4 x the same series of repeated calculations, which was the inner loop).  I do believe the issue being encountered with the dual-loops is a compiler bug, and would appreciate any other ideas or things to try ... since I'll need to reclaim the code space consumed by having to unroll the inner loop, for other program use.

Thanks Lori, will do.  Will have to go back and recreate the dual-loop scenario.

Regards,

Robert