• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 55 subscribers
  • Views 10641 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

File I/O fread and fwrite operations failure

Vish
Prodigy 70 points
Other Parts Discussed in Thread: CCSTUDIO

 

Hi,

I am trying to read and write into files on my PC from the DSP Target (C6455) via JTAG using fopen, fread and fwrite function calls. I am able to open a new file on the host PC from the target but the fread and fwrite function calls are failing. They are just returning zeros. I am using DSP BIOS

Here is my code:

void openWriteInfoFile(void)

{

    FILE *fp;

    Int32 retVal, numCmds, currCmdLen;

    fp = fopen("hello.bin", "rb");

    retVal = fread(&numCmds, 4, 1, fp);

    retVal = fread(&currCmdLen, 4, 1, fp);

    fclose(fp);

}

I have even added 0x10000 bytes of heap in my DDR. It works some times but fails most of the time.

Thanks,

Vish

  • 0 in reply to Vish
    TI__Guru* 84110 points

    Would it be possible to add a test of fp to see if there is a problem opening the file?

  • 0 in reply to RandyP
    TI__Guru* 84110 points

    I built the attached project that was able to successfully create a hello.bin file and then to read that hello.bin file. Please give it a try to see if the exact same thing will work for you that worked for me. I will have to caution you that I was not able to get a DSK6455 so I ran this on a DM642 which is what I had at my fingertips. But the project rebuilt for your platform should still be a working example.

    I seem to recall that the fclose() might not "take" until the program has run to completion. Hopefully it does not require CCS to close, too, but it did not require that for me. I did run past the end of main() each time, though.

    I would recommend first stepping through the openReadInfoFile() function to see if it can read my hello.bin correctly.

    Then change the comments in main() to make it write and change the init values in openWriteInfoFile() so it will put new values into the hello.bin file.

    Then change the comments in main() back to run the read function.

    Please let us know how this works out for you.

    test_fio.zip
  • 0 in reply to Vish
    Prodigy 70 points

     

    Previos hello.txt file had issues uploading. Uploading new binary file (.txt extention) hello2.txt

  • 0 in reply to Vish
    Prodigy 70 points

    Randy P,

    Thanks for resolving the issue very quickly. Greatly appreciate it!! 

    From what I understand, the cause of the problem is that BIOS does not enable heap space by default. You have to go and enable the creation of heap yourself in the .tcf file>>System>>MEM. I guess fread and fwrite tries to dynamically allocate memory using malloc or something and it does not find a heap memory, it just bails on you. And because fopen and fwrite are BIOS system calls, a programmer has no idea what kind of functions are called inside of it. Now that every thing is working, it all makes sense. But I had no clue what was going on when it failed.

    Wish CCS compiler at least gives the programmers a warning when it sees function calls like MEM_alloc() and it does not see proper heap settings.

    Same kind of irritation happens with Stack settings with CCS. You have no idea it is the problem until you see it happen during run time. When there is a stack overflow, the program just gives you erroneous results and NMIs. You have no decent way of finding this out . It's just like a ticking time bomb waiting go off at often the wrong time.

    Just a concerning feed back from a (panic stricken) customer...  Really appreciate the pace at which this issue got resolved! Thanks Randy.

    Vish

     

  • 0 in reply to Vish
    TI__Mastermind 18130 points

    Vish said:

    From what I understand, the cause of the problem is that BIOS does not enable heap space by default. You have to go and enable the creation of heap yourself in the .tcf file>>System>>MEM. I guess fread and fwrite tries to dynamically allocate memory using malloc or something and it does not find a heap memory, it just bails on you. And because fopen and fwrite are BIOS system calls, a programmer has no idea what kind of functions are called inside of it. Now that every thing is working, it all makes sense. But I had no clue what was going on when it failed.

    Wish CCS compiler at least gives the programmers a warning when it sees function calls like MEM_alloc() and it does not see proper heap settings.

    Hi Vish,

    I can certainly understand the frustration caused by something that seems to be invisible. Normally any time a malloc (or similar dynamic memory function) is called it returns a status value to indicate success or failure. I would assume that if fopen did not return a valid address it would respond with an error code indicating as much. Also, just for reference this is not a BIOS function but is actually a part of the Run-Time Support Library. You can find the RTS source in C:\CCStudio_v3.3\c6000\cgtools\lib by default. Unfortunately the compiler is too 'dumb' to understand that some function calls may have a dependency on the existence of some memory or anything like that - but this is by design.

    Vish said:
    Same kind of irritation happens with Stack settings with CCS. You have no idea it is the problem until you see it happen during run time. When there is a stack overflow, the program just gives you erroneous results and NMIs. You have no decent way of finding this out . It's just like a ticking time bomb waiting go off at often the wrong time.
    The same sort of thing happens here as the stack is used dynamically at run-time. Nothing has any idea how much of your stack you will actually need. BIOS guesstimates your stack usage (look at the top of the object area in the graphical config) but because of recursion and memory delays or any number of other reasons this will never be an accurate representation of how much stack your system will use. Arguably the best way to discover stack overflow is to fill it with a known value. If things go wrong check the stack - if the top of the stack has been modified then you know that ist has overflown.