• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2015 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.

CIO functions do not work on MSP430 / CCSv5.2 (tested FR5739)

Mario Willeit
Prodigy 550 points

Hello,

customer wants to do file IO with MSP430 but has problems (scanf crashes).

The following C-code was used for testing on the MSP430F5739 avalboard :
(Stack size set to 256,  heap size set to 512, BUFSIZ in stdio.h set to 32)

#include <stdio.h>

void main() {

FILE *fid;
char sMy[32]={0};
volatile int i;

fid =fopen("myfileX.txt","w");      //fid : fd=3, buf=pos=bufend=buf_stop=0, flags=32
i=fprintf(fid,"Hello, world X \n");  //returns 16 bytes written but created file is empty
i=fclose(fid);                               //returns 0
fid =fopen("myfileX.txt","r");        //fid : fd=3, buf=pos=bufend=buf_stop=0, flags=16
i=fscanf(fid, "%s", sMy);              //crashes => debugger continues with previous line when single stepping 
i=fclose(fid);
} 

What has the customer done wrong ? Why is the file empty ? Why does fscanf crash ? Any idea ?

Best regards,
Mario

  • 0
    Guru 227245 points

    I wonder where 'myfileX.txt' goes to (when writing it) or comes from (when reading it), since by default the MSP does not have an OS or a file system (the post contains no info about any used framework or storage drivers).

    This would explain the crash: The code does not check for any error returned from fopen. If fopen fails, fprintf will go into the void and the fscanf tries to scan from thin air, And since it scans for a string, it will possibly scan until it has filled all memory with dummy values.

    Just an idea.

  • 0
    TI__Guru 56650 points

    Mario,

    Jens got the point here. What is the customer trying to do actually? could you describe it more in detail this will help us to understand the problem and (at least) suggest (another) solution instead of using FILE CIO.

  • 0 in reply to Leo Hendrawan
    TI__Prodigy 550 points

    Ihend, Jens,

    the File CIO is part of a verification procedure. The customer has to verify that the code on the target system (MSP430) produces the
    same results as when simulating on the PC (e.g. using Matlab). Comparing result files is an easy way to do so. The customer has
    already done a similiar (successful) project with our C6000 family ....

    The MSP Compiler manual mentions (page 129) :

    7.2 The C I/O Functions
    The C I/O functions make it possible to access the host's operating system to perform I/O. The capability
    to perform I/O on the host gives you more options when debugging and testing code.

    And that's where the file is created (Debug directory of the workspace) ..... the debugger has to be connected (I should have mentioned this earlier).

    So in general it should work. But in particular it doesn't. The question is if there is a bug in the compiler or if this feature is no longer supported
    or (most likely) what has the user done wrong ?

    Thank you for your support,
    Mario

  • 0 in reply to Mario Willeit
    Guru 227245 points

    Mario Willeit said:
    And that's where the file is created (Debug directory of the workspace) ..... the debugger has to be connected

    Okay, that explains much.

    Mario Willeit said:
    The customer has to verify that the code on the target system (MSP430) produces the same results as when simulating on the PC (e.g. using Matlab). Comparing result files is an easy way to do so.

    Using a feature that is provided by the debugger through intrusion into the program flow wouldn't count as a valid verification in my eyes.

    On the MSP side, the functions are more or less empty code and the debugger intercepts the function calls, fetching or injecting data as required.
    A validation test would require the whole code running on the target system, with or without debugger.

    Anyway, the comment that the file stays empty is an indicator that things don't work as expected. And using sscanf on an empty file where writing has obviously failed before, may fail or not - it is further down ont eh list of things to check.
    Once writing succeeded, reading is the next step. Unless it is known why nothing is written to the file, the failure of fscanf may have way too many reasons to bother checking.

    e.g. if interception of incoming and outgoing data fails, fscanf may be 100% okay - the stub code inside the MSP simply won't ever get updated information from the debugger and will continue scanning and copying - perfectly okay, but at the end crashing the MSP due to lack of an EOF signal.

    I don't know how the functions are implemented in detail. But I can imagine that the FR5739 simply does not have enough hardware breakpoints available to hook into all f- functions. The FR57xx only has a small EEM with three hardware breakpoints on memory access. Other MSPs have up to eight.

  • 0
    Guru 92251 points

    Mario Willeit said:
    What has the customer done wrong ? Why is the file empty ? Why does fscanf crash ? Any idea ?

    With the posted code I was able to repeat the problem. The code isn't disabling the watchdog.

    By disabling the watchdog at the start, the program then ran correctly (no crashes, myFileX.txt contains the expected contents and sMy contained the expected contents):

    #include <msp430.h>
    #include <stdio.h>

    void main() {

        FILE *fid;
        char sMy[32]={0};
        volatile int i;

        WDTCTL = WDTPW | WDTHOLD; //Disable Watchdog timer to prevent reset during
        fid =fopen("myfileX.txt","w"); //fid : fd=3, buf=pos=bufend=buf_stop=0, flags=32
        i=fprintf(fid,"Hello, world X \n"); //returns 16 bytes written but created file is empty
        i=fclose(fid); //returns 0
        fid =fopen("myfileX.txt","r"); //fid : fd=3, buf=pos=bufend=buf_stop=0, flags=16
        i=fscanf(fid, "%s", sMy);  
        i=fclose(fid);
    }

    After reset the watchdog is set to expire after 32 milliseconds. When the debugger halts the target after ever step it disables the watchdog, but single stepping over file I/O calls probably takes more than 32 milliseconds which then leads to a watchdog reset.

  • 0 in reply to Chester Gillon
    Guru 227245 points

    Chester Gillon said:
    By disabling the watchdog at the start, the program then ran correctly

    Good catch. It's easy to forget the WDT. MSPGCC 3.2.3 (which I use) did automatically disable it during inititialization of the global variables. And in my own 'framework', I no longer do so, but I serve it from within the timer interrupt. But of course for most other situations, it eitehr has to be enabled at beginning of main, or served.

**Attention** This is a public forum