Prev: Call for Papers: The 2010 International Conference of Signal and Image Engineering (ICSIE 2010)
Next: GMSK recover from I, Q sample data
From: Randy Yates on 26 Feb 2010 11:39 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 26 Feb 2010 12:14 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 26 Feb 2010 16:52 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 26 Feb 2010 17:50 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 26 Feb 2010 19:15
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 |