From: Randy Yates on


I'm using CCS 3.3.82.13 along with the cgtools 6.1.13. the target is
the CPU cycle-accurate 64xx simulator.

I'm building an application to read some test vectors into the DSP
from the PC filesystem using the C file I/O system (fopen, fread,
fwrite, fclose, feof).The application is a simple C application (no
DSP/BIOS) running in the 512kB core SRAM.

The problem is in the fread()/feof() functions. I'm first reading a
few bytes of header information with fread(), then I begin reading 16-
bit samples in chunks of BUFFER_LENGTH. The header fread()s work
perfectly. However, after 50 or so bytes of samples are read (the
exact number changes somewhat), fread() begins returning 0 bytes read
and feof() returns true, even though the actual file size is about 32k
bytes.

Here are the things I've tried:

1. Varying the BUFFER_LENGTH from 1 to 16 to 128 to 256 to 1024 - no
change.

2. Increasing the heap (.sysmem) and stack (.stack) to 128k bytes
each. no change.

3. Creating a linker command file and explicitly placing all the
sections.

4. Aligning the .cio section to a 256-byte boundary.

5. Upgrading the toolchain (the previous version was 6.0.x).



Please help!



--Randy Yates

From: Randy Yates on
On Feb 26, 11:39 am, Randy Yates <ya...(a)ieee.org> wrote:
> I'm using CCS 3.3.82.13 along with the cgtools 6.1.13. the target is
> the CPU cycle-accurate 64xx simulator.
>
> I'm building an application to read some test vectors into the DSP
> from the PC filesystem using the C file I/O system (fopen, fread,
> fwrite, fclose, feof).The application is a simple C application (no
> DSP/BIOS) running in the 512kB core SRAM.
>
> The problem is in the fread()/feof() functions. I'm first reading a
> few bytes of header information with fread(), then I begin reading 16-
> bit samples in chunks of BUFFER_LENGTH. The header fread()s work
> perfectly. However, after 50 or so bytes of samples are read (the
> exact number changes somewhat), fread() begins returning 0 bytes read
> and feof() returns true, even though the actual file size is about 32k
> bytes.
>
> Here are the things I've tried:
>
>   1. Varying the BUFFER_LENGTH from 1 to 16 to 128 to 256 to 1024 - no
> change.
>
>    2. Increasing the heap (.sysmem) and stack (.stack) to 128k bytes
> each. no change.
>
>   3. Creating a linker command file and explicitly placing all the
> sections.
>
>   4. Aligning the .cio section to a 256-byte boundary.
>
>   5. Upgrading the toolchain (the previous version was 6.0.x).
>
> Please help!
>
> --Randy Yates

Someone on the TI forum determined the problem: I wasn't specifying
the "b" option in fopen. fopen(file, "rb")

--Randy
From: Tauno Voipio on
On 26.2.10 7:14 , Randy Yates wrote:
> On Feb 26, 11:39 am, Randy Yates<ya...(a)ieee.org> wrote:
>> I'm using CCS 3.3.82.13 along with the cgtools 6.1.13. the target is
>> the CPU cycle-accurate 64xx simulator.
>>
>> I'm building an application to read some test vectors into the DSP
>> from the PC filesystem using the C file I/O system (fopen, fread,
>> fwrite, fclose, feof).The application is a simple C application (no
>> DSP/BIOS) running in the 512kB core SRAM.
>>
>> The problem is in the fread()/feof() functions. I'm first reading a
>> few bytes of header information with fread(), then I begin reading 16-
>> bit samples in chunks of BUFFER_LENGTH. The header fread()s work
>> perfectly. However, after 50 or so bytes of samples are read (the
>> exact number changes somewhat), fread() begins returning 0 bytes read
>> and feof() returns true, even though the actual file size is about 32k
>> bytes.
>>
>> Here are the things I've tried:
>>
>> 1. Varying the BUFFER_LENGTH from 1 to 16 to 128 to 256 to 1024 - no
>> change.
>>
>> 2. Increasing the heap (.sysmem) and stack (.stack) to 128k bytes
>> each. no change.
>>
>> 3. Creating a linker command file and explicitly placing all the
>> sections.
>>
>> 4. Aligning the .cio section to a 256-byte boundary.
>>
>> 5. Upgrading the toolchain (the previous version was 6.0.x).
>>
>> Please help!
>>
>> --Randy Yates
>
> Someone on the TI forum determined the problem: I wasn't specifying
> the "b" option in fopen. fopen(file, "rb")
>
> --Randy

OUCH!

This is a Microsoftism - did the file contain a MS-DOS EOF
(Control-Z, 0x1a) at the point of breakage?

--

Tauno Voipio
tauno voipio (at) iki fi

From: glen herrmannsfeldt on
Tauno Voipio <tauno.voipio(a)notused.fi.invalid> wrote:
> On 26.2.10 7:14 , Randy Yates wrote:
>> On Feb 26, 11:39 am, Randy Yates<ya...(a)ieee.org> wrote:

>> Someone on the TI forum determined the problem: I wasn't specifying
>> the "b" option in fopen. fopen(file, "rb")

> OUCH!

> This is a Microsoftism - did the file contain a MS-DOS EOF
> (Control-Z, 0x1a) at the point of breakage?

Well, it is standard C. For unix, it doesn't matter as unix uses
X'0A' as the line terminator. For other systems, it does.

Even more, there are systems with record oriented file systems that
keep track of record boundaries. It gets even more interesting
in that case.

-- glen
From: Les Cargill on
Randy Yates wrote:
>
> I'm using CCS 3.3.82.13 along with the cgtools 6.1.13. the target is
> the CPU cycle-accurate 64xx simulator.
>
> I'm building an application to read some test vectors into the DSP
> from the PC filesystem using the C file I/O system (fopen, fread,
> fwrite, fclose, feof).The application is a simple C application (no
> DSP/BIOS) running in the 512kB core SRAM.
>
> The problem is in the fread()/feof() functions. I'm first reading a
> few bytes of header information with fread(), then I begin reading 16-
> bit samples in chunks of BUFFER_LENGTH. The header fread()s work
> perfectly. However, after 50 or so bytes of samples are read (the
> exact number changes somewhat), fread() begins returning 0 bytes read
> and feof() returns true, even though the actual file size is about 32k
> bytes.
>
> Here are the things I've tried:
>
> 1. Varying the BUFFER_LENGTH from 1 to 16 to 128 to 256 to 1024 - no
> change.
>
> 2. Increasing the heap (.sysmem) and stack (.stack) to 128k bytes
> each. no change.
>
> 3. Creating a linker command file and explicitly placing all the
> sections.
>
> 4. Aligning the .cio section to a 256-byte boundary.
>
> 5. Upgrading the toolchain (the previous version was 6.0.x).
>
>
>
> Please help!
>
>
>
> --Randy Yates
>

Did you try FILE *f=fopen(path,"rb"); ? You have to open it binary....

--
Les Cargill