A question about turbo-coprocessor simulation in CCS

Hi all:

    I have written a programme using the turbo-coprocessor to perform
the turbo decoding.
To check the bit error rate, I used a loop to decode for 100 times. The
data to be decoded
is read from a data file in PC side, and the decoding output is also
written into a data file in PC side.
The file I/O routines are fscanf and fprintf.
After one single decoding procedure is done, the programme should run
into the EDMA interrupt service routine.
But there is a very strange question:
When I run the programme only in CCS, the 100-times loop could only run
for 33 times, and then the EMDA ISR could not be executed.
When I download the programme into a C6416 DSK, the loop could only run
for 18 times.

What the hell is the problem?
Any reply would be appreciated.


                                                  liqiyue

liqiyue@gmail.com wrote:

   ...

> What the hell is the problem?

Have you checked for stack overflow? If your loop leaves the stack with 
an extra element on each iteration, the number of iterations before a 
crash will depend on the size of memory.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

SGksIHRoYW5rcyBmb3IgcmVwbHkKClRoZXJlIGlzIG5vIHN0YWNrIG92ZXJmbG93LgpJIHRoaW5r
IHRoZSBwcm9ibGVtIGlzIG1lbW9yeSB1c2FnZSByZWxhdGVkLCBidXQgSSBjYW4ndCBmaW5kIGl0
IG91dAoKIkplcnJ5IEF2aW5zINC0tcCjugoiCj4gbGlxaXl1ZUBnbWFpbC5jb20gd3JvdGU6Cj4K
PiAgICAuLi4KPgo+ID4gV2hhdCB0aGUgaGVsbCBpcyB0aGUgcHJvYmxlbT8KPgo+IEhhdmUgeW91
IGNoZWNrZWQgZm9yIHN0YWNrIG92ZXJmbG93PyBJZiB5b3VyIGxvb3AgbGVhdmVzIHRoZSBzdGFj
ayB3aXRoCj4gYW4gZXh0cmEgZWxlbWVudCBvbiBlYWNoIGl0ZXJhdGlvbiwgdGhlIG51bWJlciBv
ZiBpdGVyYXRpb25zIGJlZm9yZSBhCj4gY3Jhc2ggd2lsbCBkZXBlbmQgb24gdGhlIHNpemUgb2Yg
bWVtb3J5Lgo+Cj4gSmVycnkKPiAtLQo+IEVuZ2luZWVyaW5nIGlzIHRoZSBhcnQgb2YgbWFraW5n
IHdoYXQgeW91IHdhbnQgZnJvbSB0aGluZ3MgeW91IGNhbiBnZXQuCj4goaWhpaGloaWhpaGloaWh
paGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGl
oaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWhpaGloaWh
paGloaWhpaGloaWhpQo=

liqiyue@gmail.com wrote:
> Hi, thanks for reply
> 
> There is no stack overflow.
> I think the problem is memory usage related, but I can't find it out

If the amount of memory needed increases with each iteration, the 
problem is somewhere in the code -- including subroutines -- executed by 
the loop. Memory leaks are usually caused by unbalanced stack or alloc() 
operations. What else?

Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

> If the amount of memory needed increases with each iteration, the
> problem is somewhere in the code -- including subroutines -- executed by
> the loop. Memory leaks are usually caused by unbalanced stack or alloc()
> operations. What else?

I do use mem_alloc() function to allocate memory, as the decoded data
need to be
8-bytes aligned.
But I allocate the memory at the beginning of the main function --
before the iterations, and
I free it at the end of the function.
Any problem?

liqiyue@gmail.com wrote:
> Hi all:
>
>     I have written a programme using the turbo-coprocessor to perform
> the turbo decoding.
> To check the bit error rate, I used a loop to decode for 100 times. The
> data to be decoded
> is read from a data file in PC side, and the decoding output is also
> written into a data file in PC side.
> The file I/O routines are fscanf and fprintf.
> After one single decoding procedure is done, the programme should run
> into the EDMA interrupt service routine.
> But there is a very strange question:
> When I run the programme only in CCS, the 100-times loop could only run
> for 33 times, and then the EMDA ISR could not be executed.
> When I download the programme into a C6416 DSK, the loop could only run
> for 18 times.
>
> What the hell is the problem?
> Any reply would be appreciated.
>

Start by simplifying the setup. What if you take out the file i/o? Does
that change the behavior? Now put in just the reads. Try using
lightweight i/o functions like fread / fwrite instead of formatted i/o.
Do not assume that TI's stdlib stuff is bug free. They are a hardware
company.

John

liqiyue@gmail.com wrote:
>> If the amount of memory needed increases with each iteration, the
>> problem is somewhere in the code -- including subroutines -- executed by
>> the loop. Memory leaks are usually caused by unbalanced stack or alloc()
>> operations. What else?
> 
> I do use mem_alloc() function to allocate memory, as the decoded data
> need to be
> 8-bytes aligned.
> But I allocate the memory at the beginning of the main function --
> before the iterations, and
> I free it at the end of the function.
> Any problem?

Do you have a way to dump memory after the crash? Loading it with tracer 
words (like FEED CODE or DEAD BEEF) before the program is run may help 
to reveal where memory gets tromped on.

Do you check the return from mem_alloc()? It will tell you if there's 
not enough memory to fill the request, but only if you look.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

> Do you have a way to dump memory after the crash? Loading it with tracer
> words (like FEED CODE or DEAD BEEF) before the program is run may help
> to reveal where memory gets tromped on.
>
> Do you check the return from mem_alloc()? It will tell you if there's
> not enough memory to fill the request, but only if you look.

The programme doesn't crash at all. It just stops at the while loop
that waiting for the EDMA interrupt. But after 33-times interrupt,
nothing happens.
MEM_alloc() function does successfully allocate memory every time, even
in the iteration where the programme halts.

liqiyue@gmail.com wrote:
>> Do you have a way to dump memory after the crash? Loading it with tracer
>> words (like FEED CODE or DEAD BEEF) before the program is run may help
>> to reveal where memory gets tromped on.
>>
>> Do you check the return from mem_alloc()? It will tell you if there's
>> not enough memory to fill the request, but only if you look.
> 
> The programme doesn't crash at all. It just stops at the while loop
> that waiting for the EDMA interrupt. But after 33-times interrupt,
> nothing happens.

How do you know it didn't crash? What sign of life does it give?

> MEM_alloc() function does successfully allocate memory every time, even
> in the iteration where the programme halts.

You wrote before that you allocate memory once for all. From the above, 
it seems that you allocate each time around the loop. Did I misread "But 
I allocate the memory at the beginning of the main function -- before 
the iterations, and I free it at the end of the function"?

Mem-alloc() doesn't physically go out and check that the memory it 
assigns is actually there (although it would be good to have a 
troubleshooting version that did). It allocates from a table. Does that 
table match the memory you really have?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

OK. Now the problem has been solved.
It is the memory usage problem. I use EDMA_intAlloc() function to
allocate a tcc in every iteration, but I forgot to free it.

Thanks very much and sorry for my poor english.
^_^