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
C File I/O (fread) Problem
Started by ●February 26, 2010
Reply by ●February 26, 20102010-02-26
On Feb 26, 11:39�am, Randy Yates <ya...@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 YatesSomeone on the TI forum determined the problem: I wasn't specifying the "b" option in fopen. fopen(file, "rb") --Randy
Reply by ●February 26, 20102010-02-26
On 26.2.10 7:14 , Randy Yates wrote:> On Feb 26, 11:39 am, Randy Yates<ya...@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") > > --RandyOUCH! 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
Reply by ●February 26, 20102010-02-26
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:> On 26.2.10 7:14 , Randy Yates wrote: >> On Feb 26, 11:39 am, Randy Yates<ya...@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
Reply by ●February 26, 20102010-02-26
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
Reply by ●February 26, 20102010-02-26
Tauno Voipio <tauno.voipio@notused.fi.invalid> writes:> On 26.2.10 7:14 , Randy Yates wrote: >> On Feb 26, 11:39 am, Randy Yates<ya...@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?Hi Tauno, There is a 0x1a near there, yes. I do feel a bit foolish. I've known about the "b" flag for decades - just got careless. But also, TI's C file I/O has a history of squirrelishness (sp?), so I was suspecting that type of nonsense. Additionally, the exact same code ran fine when retargeted for pc/cygwin. -- Randy Yates % "Maybe one day I'll feel her cold embrace, Digital Signal Labs % and kiss her interface, mailto://yates@ieee.org % til then, I'll leave her alone." http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO
Reply by ●February 26, 20102010-02-26
Randy Yates wrote:> Tauno Voipio <tauno.voipio@notused.fi.invalid> writes: > > >>On 26.2.10 7:14 , Randy Yates wrote: >> >>>On Feb 26, 11:39 am, Randy Yates<ya...@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? > > > Hi Tauno, > > There is a 0x1a near there, yes. > > I do feel a bit foolish. I've known about the "b" flag for decades - > just got careless. But also, TI's C file I/O has a history of > squirrelishness (sp?), so I was suspecting that type of nonsense. > Additionally, the exact same code ran fine when retargeted for > pc/cygwin.A peer review of the code would reveal that error at once. However what is good about chasing such silly problem is that you probably fixed a dozen of suspicious places elsewhere, and now you can cite the documentation by heart. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●February 27, 20102010-02-27
Vladimir Vassilevsky <nospam@nowhere.com> writes:> [...] > However what is good about chasing such silly problem is that you > probably fixed a dozen of suspicious places elsewhere, and now you can > cite the documentation by heart.It will be a warm winter in Greenland before I forget the blasted "b" in an fopen() again! -- Randy Yates % "Ticket to the moon, flight leaves here today Digital Signal Labs % from Satellite 2" mailto://yates@ieee.org % 'Ticket To The Moon' http://www.digitalsignallabs.com % *Time*, Electric Light Orchestra
Reply by ●February 27, 20102010-02-27
Randy Yates wrote:> Vladimir Vassilevsky <nospam@nowhere.com> writes: >> [...] >> However what is good about chasing such silly problem is that you >> probably fixed a dozen of suspicious places elsewhere, and now you can >> cite the documentation by heart. > > It will be a warm winter in Greenland before I forget the blasted "b" in > an fopen() again!That time may arrive all too soon! :-) This snow we've been having is a direct consequence of warm Pacific Ocean weather. BTW, Microsoft inherited that need from CP-M. Jerry -- Leopold Kronecker on mathematics: God created the integers, all else is the work of man. ����������������������������������������������������������������������
Reply by ●February 27, 20102010-02-27
Randy Yates <yates@ieee.org> wrote: (snip)>>> Someone on the TI forum determined the problem: I wasn't specifying >>> the "b" option in fopen. fopen(file, "rb")(snip)> There is a 0x1a near there, yes.> I do feel a bit foolish. I've known about the "b" flag for decades - > just got careless. But also, TI's C file I/O has a history of > squirrelishness (sp?), so I was suspecting that type of nonsense. > Additionally, the exact same code ran fine when retargeted for > pc/cygwin.It is pretty strange, overall. You should expect problems with X'OD' and/or X'0A', as those are the line terminator characters. Cygwin is supposed to work like unix, so better do I/O like unix. The X'1A' is left over from CP/M, where the directory counts blocks but not bytes. Text files indicate the end of file with X'1A'. Somehow that tradition was kept with MSDOS, even though the file system does keep the file length in bytes. There was no need for it, but they did it anyway. That is a separate question from the use of control-Z for terminating terminal/console input. Unix uses control-D for that, but doesn't terminate file input when it finds a control-D. -- glen
