C File I/O (fread) Problem
in [DSP]
|
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 20:58 Tauno Voipio <tauno.voipio(a)notused.fi.invalid> writes: > 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? 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(a)ieee.org % til then, I'll leave her alone." http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO
From: Vladimir Vassilevsky on 26 Feb 2010 21:19 Randy Yates wrote: > Tauno Voipio <tauno.voipio(a)notused.fi.invalid> writes: > > >>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? > > > 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
From: Randy Yates on 26 Feb 2010 23:21 Vladimir Vassilevsky <nospam(a)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(a)ieee.org % 'Ticket To The Moon' http://www.digitalsignallabs.com % *Time*, Electric Light Orchestra
From: Jerry Avins on 26 Feb 2010 23:56 Randy Yates wrote: > Vladimir Vassilevsky <nospam(a)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. ����������������������������������������������������������������������
From: glen herrmannsfeldt on 26 Feb 2010 23:59
Randy Yates <yates(a)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 |