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.

  • TI Thinks Resolved

CCS/EVMK2G: A15 File I/O over JTAG binary mode FILE I/O behaviour is similar to text mode FILE I/O

Expert 1190 points

Replies: 9

Views: 395

Part Number: EVMK2G

Tool/software: Code Composer Studio

Hi,

I Am trying to open an AAC file in binary mode and try reading a block of 2048 bytes. But, fread reads only 948 bytes. After that feof says file as reached end returning true.

I tried opening another AAC file binary mode reading block size of 2048 bytes now it read 1038 bytes, again it says it reached end of file. However both the file size in few 10's of KB's.

I tried opening normal text file in binary mode then read block of 2048 bytes then read was proper it was not eof since file had still much more content.

Even using file I/O seek SEEK_END file sizes returned are proper. When I checked content of respective files 948 and 1038 offsets I find character 0x1A (Ctrl+Z).

This behavior of interpreting Ctrl+Z as end of file is expected in when file is open in text mode. But, not sure Y this can happen in binary mode.

I am using CCSV8 and GCC version 6.

Below is code,
#include <stdio.h> int main(void) { FILE *infile = NULL; char buf[2048]; if ((infile = fopen("file.ac3","rb")) == NULL) { fprintf(stderr, "FIO: error opening input file\n"); return 1; } /* determine file length */ fseek(infile, 0, SEEK_END); printf("file size :%ld\n",ftell(infile)); rewind(infile); fread(buf, 1, 2048, infile); printf("file size :%ld\n",ftell(infile)); if(feof(infile)) { printf("file reached end of file\n"); } return 0; }

Below is my Makefile,

SYSBIOS=c:\ti\bios_6_73_00_12
XDCTOOLS=c:\ti\xdctools_3_50_08_24_core
XDCPATH = $(SYSBIOS)/packages
CONFIGURO = $(XDCTOOLS)/xs --xdcpath="$(XDCPATH)" xdc.tools.configuro -b config.bld
TARGET = gnu.targets.arm.A15F
PLATFORM = ti.platforms.evmTCI66AK2G02
CC = $(A15TOOLS)/bin/arm-none-eabi-gcc
LDFLAGS = -nostartfiles -static -Wl,--gc-sections -Wl,-T,sysbios/linker.cmd -Wl,-Map,task.map -mfloat-abi=hard --specs=nosys.specs
LDLIBS = -lgcc -lc -lm -lrdimon -L$(SYSBIOS)/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard --specs=nano.specs"

linker.cmd : sysbios.cfg    
    $(CONFIGURO) -c $(A15TOOLS) -t $(TARGET) -p $(PLATFORM) -r release $<
    
all: linker.cmd    
    $(CC) file_io.c @sysbios/compiler.opt  $(LDFLAGS) -o file.out $(LDLIBS)


By XDC config file(sysbios.cfg) as enabled host mode support.

K2GEVM has XDS200 onboard JTAG, I would like to know flow of these file I/O over JTAG so that I can try out few more experiments to isolate cause of problem

Thanks & Regards,

Vishwanath Patil

  • Vishwanath Patil
    K2GEVM has XDS200 onboard JTAG, I would like to know flow of these file I/O over JTAG so that I can try out few more experiments to isolate cause of problem

    For programs using the GCC ARM compiler, the TI WIki page Semihosting gives an overview of how stdio.h functions map to semihosting calls.

    ARM has documentation on the arguments for each semihosting call. E.g. for SYS_OPEN

    Vishwanath Patil
    This behavior of interpreting Ctrl+Z as end of file is expected in when file is open in text mode.

    I can repeat the behavior with a program built using:

    - Cortex-A15 core in an EVMK2H (66AK2H14)
    - CCS  8.3.0.00009
    - SYS/BIOS 6_73_01_01
    - GCC ARM compiler 6.3.1

    The program performs the following:
    a. Fills a 8192 byte buffer with a repeating incrementing byte pattern.

    b. Creates a binary file using fopen() mode "wb".

    c. Write to the file with a single fwrite() call for 8192 bytes.

    d. Closes the file.

    e. Opens the file reading in binary mode using fopen() mode "rb".

    f. Reads the contents of file with a single call fread().

    g. Verifies the contents of the file read contains the expected pattern.

    h. Closes the file.

    When the test is run using CCS 8.3 under a Ubuntu 18.04 PC it passes.

    Whereas when the test is run using CCS 8.3 under a Windows 10 it fails with the symptoms:

    1. The A15_binary.dat file written to disk is 8224 bytes, rather than the 8192 bytes expected.

    2. The fread() call only returns 26 bytes, rather than the 8192 bytes expected.

     When I single stepped the _swiopen() function found that the mode parameter to the SYS_OPEN call is not being set correctly:

    a. For "wb" is being set to 4, which is for "w", rather than 5.

    b. For "rb"is being set to 0, which is for "r", rather than 1.

    The linker map file shows the _swiopen() call is being linked from bios_6_73_01_01/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard\librdimon_nano.a(rdimon-syscalls.o), so the problem appears to be in the run time library which is part of SYS/BIOS.

    The test program is attached. 66AK2H14_A15_BIOS_binary_file_io.zip

  • In reply to Chester Gillon:

    Hi ,

    Even though I did try with older version of "bios_6_52_00_12", I couldn't try stepping in and checking parameters. Even older version has same issue. Since you told Linux machine it works I am not sure whether RTS libarary as issue or librdimon_nano.a device side library as issue. If it is librdimon_nano.a then I thought issue should be there in both windows and linux it is just an opinion.

    However I will try stepping in and check if I have same observation and I will update.


    Thanks & Regards,

    Vishwanath Patil

  • In reply to Vishwanath Patil:

    Vishwanath Patil
    If it is librdimon_nano.a then I thought issue should be there in both windows and linux it is just an opinion.

    I think that is because under Windows "rb" and "r" cause different behaviour for binary .vs. text files, whereas under Linux they are both handled as binary without any translation.

    I will try and find the source code for the librdimon_nano.a which is delivered with SYS/BIOS. When I was stepping in and checking parameters in the SemiHosting calls was only going by the disassembly.

  • In reply to Chester Gillon:

    Hi Experts.

    Even in "rb" mode, the fread() is unable to read expected number of bytes from the specified file. Whenever fread() finds "1A" in the file, returns EOF. Please let us know correct tool versions for fread() to work in expected way.

    regards,

    Lakshmi Sankar

    PATHPARTNER

  • In reply to Chester Gillon:

    Chester Gillon
    I will try and find the source code for the librdimon_nano.a which is delivered with SYS/BIOS. When I was stepping in and checking parameters in the SemiHosting calls was only going by the disassembly.

    The SYSBIOS Manifest identifies the version of the original newlib source, plus a patch for any modifications made by TI.

    By obtaining the newlib source code, the CCS debugger can then display the source when stepping into the fopen() call.

    With bios_6_73_01_01 there is the __sflags function in newlib\libc\stdio\flags.c which converts the text mode string passed to fopen() into a binary mode:

    /*
     * Return the (stdio) flags for a given mode.  Store the flags
     * to be passed to an open() syscall through *optr.
     * Return 0 on error.
     */
    
    int
    _DEFUN(__sflags, (ptr, mode, optr),
           struct _reent *ptr  _AND
           register char *mode _AND
           int *optr)
    {
      register int ret, m, o;
    
      switch (mode[0])
        {
        case 'r':			/* open for reading */
          ret = __SRD;
          m = O_RDONLY;
          o = 0;
          break;
    
        case 'w':			/* open for writing */
          ret = __SWR;
          m = O_WRONLY;
          o = O_CREAT | O_TRUNC;
          break;
    
        case 'a':			/* open for appending */
          ret = __SWR | __SAPP;
          m = O_WRONLY;
          o = O_CREAT | O_APPEND;
          break;
        default:			/* illegal mode */
          ptr->_errno = EINVAL;
          return (0);
        }
      while (*++mode)
        {
          switch (*mode)
    	{
    	case '+':
    	  ret = (ret & ~(__SRD | __SWR)) | __SRW;
    	  m = (m & ~O_ACCMODE) | O_RDWR;
    	  break;
    	case 'b':
    #ifdef O_BINARY
    	  m |= O_BINARY;
    #endif
    	  break;
    #ifdef __CYGWIN__
    	case 't':
    	  m |= O_TEXT;
    	  break;
    #endif
    #if defined (O_CLOEXEC) && defined (_GLIBC_EXTENSION)
    	case 'e':
    	  m |= O_CLOEXEC;
    	  break;
    #endif
    	case 'x':
    	  m |= O_EXCL;
    	  break;
    	default:
    	  break;
    	}
        }
    #if defined (O_TEXT) && !defined (__CYGWIN__)
      if (!(m | O_BINARY))
        m |= O_TEXT;
    #endif
      *optr = m | o;
      return ret;
    }

    And the _swiopen() function in libgloss\arm\syscalls.c converts the binary mode into the Semihosting SYS_OPEN mode parameter:

    int
    _swiopen (const char * path, int flags)
    {
      int aflags = 0, fh;
    #ifdef ARM_RDI_MONITOR
      int block[3];
    #endif
      
      int fd = newslot ();
    
      if (fd == -1)
        {
          errno = EMFILE;
          return -1;
        }
      
      /* It is an error to open a file that already exists. */
      if ((flags & O_CREAT) 
          && (flags & O_EXCL))
        {
          struct stat st;
          int res;
          res = _stat (path, &st);
          if (res != -1)
            {
    	  errno = EEXIST;
    	  return -1;
            }
        }
    
      /* The flags are Unix-style, so we need to convert them. */ 
    #ifdef O_BINARY
      if (flags & O_BINARY)
        aflags |= 1;
    #endif
      
      /* In O_RDONLY we expect aflags == 0. */
    
      if (flags & O_RDWR) 
        aflags |= 2;
    
      if ((flags & O_CREAT)
          || (flags & O_TRUNC)
          || (flags & O_WRONLY))
        aflags |= 4;
    
      if (flags & O_APPEND)
        {
          /* Can't ask for w AND a; means just 'a'.  */
          aflags &= ~4;
          aflags |= 8;
        }
      
    #ifdef ARM_RDI_MONITOR
      block[0] = (int) path;
      block[2] = strlen (path);
      block[1] = aflags;
      
      fh = do_AngelSWI (AngelSWI_Reason_Open, block);
      
    #else
      asm ("mov r0,%2; mov r1, %3; swi %a1; mov %0, r0"
           : "=r"(fh)
           : "i" (SWI_Open),"r"(path),"r"(aflags)
           : "r0","r1");
    #endif
      
      /* Return a user file descriptor or an error. */
      if (fh >= 0)
        {
          openfiles[fd].handle = fh;
          openfiles[fd].pos = 0;
          return fd;
        }
      else
        return error (fh);
    }

    Note that in the source for the above functions, the handling of binary mode is inside conditional compilation blocks for #ifdef O_BINARY

    The CCS debugger disassembly shows the following for the __sflags() function:

              __sflags():
    80019190:   E5D13000            ldrb       r3, [r1]
    80019194:   E3530072            cmp        r3, #0x72
    80019198:   0A000020            beq        #0x80019220
    8001919c:   E3530077            cmp        r3, #0x77
    800191a0:   0A000005            beq        #0x800191bc
    800191a4:   E3530061            cmp        r3, #0x61
    800191a8:   1A000008            bne        #0x800191d0
     57             o = O_CREAT | O_APPEND;
    800191ac:   E3A0CF82            mov        r12, #0x208
     56             m = O_WRONLY;
    800191b0:   E3A03001            mov        r3, #1
     55             ret = __SWR | __SAPP;
    800191b4:   E3A00F42            mov        r0, #0x108
    800191b8:   EA000002            b          #0x800191c8
     51             o = O_CREAT | O_TRUNC;
    800191bc:   E3A0CC06            mov        r12, #0x600
     50             m = O_WRONLY;
    800191c0:   E3A03001            mov        r3, #1
     49             ret = __SWR;
    800191c4:   E3A00008            mov        r0, #8
     37       {
    800191c8:   E52DE004            str        lr, [sp, #-4]!
    800191cc:   EA000007            b          #0x800191f0
     60             ptr->_errno = EINVAL;
    800191d0:   E3A03016            mov        r3, #0x16
    800191d4:   E5803000            str        r3, [r0]
     61             return (0);
    800191d8:   E3A00000            mov        r0, #0
     99       }
    800191dc:   E12FFF1E            bx         lr
     65             switch (*mode)
    800191e0:   E35E002B            cmp        lr, #0x2b
    800191e4:   0A000008            beq        #0x8001920c
    800191e8:   E35E0078            cmp        lr, #0x78
     87       	  m |= O_EXCL;
    800191ec:   03833B02            orreq      r3, r3, #0x800
     63         while (*++mode)
    800191f0:   E5F1E001            ldrb       lr, [r1, #1]!
    800191f4:   E35E0000            cmp        lr, #0
    800191f8:   1AFFFFF8            bne        #0x800191e0
     97         *optr = m | o;
    800191fc:   E183300C            orr        r3, r3, r12
    80019200:   E5823000            str        r3, [r2]
     99       }
    80019204:   E49DE004            pop        {lr}
    80019208:   E12FFF1E            bx         lr
     68       	  ret = (ret & ~(__SRD | __SWR)) | __SRW;
    8001920c:   E3C0001C            bic        r0, r0, #0x1c
     69       	  m = (m & ~O_ACCMODE) | O_RDWR;
    80019210:   E3C33003            bic        r3, r3, #3
     68       	  ret = (ret & ~(__SRD | __SWR)) | __SRW;
    80019214:   E3800010            orr        r0, r0, #0x10
     69       	  m = (m & ~O_ACCMODE) | O_RDWR;
    80019218:   E3833002            orr        r3, r3, #2
     70       	  break;
    8001921c:   EAFFFFF3            b          #0x800191f0
     45             o = 0;
    80019220:   E3A0C000            mov        r12, #0
     43             ret = __SRD;
    80019224:   E3A00004            mov        r0, #4
     44             m = O_RDONLY;
    80019228:   E1A0300C            mov        r3, r12
    8001922c:   EAFFFFE5            b          #0x800191c8
    61          errno = 0;

    The CCS debugger disassembly shows the following for the _swiopen() function:

              _swiopen(), newslot():
    800173c8:   E59F30F8            ldr        r3, [pc, #0xf8]
    553       {
    800173cc:   E92D47F0            push       {r4, r5, r6, r7, r8, r9, r10, lr}
    800173d0:   E1A0A000            mov        r10, r0
    800173d4:   E1A09001            mov        r9, r1
    116         for (i = 0; i < MAX_OPEN_FILES; i++)
    800173d8:   E3A04000            mov        r4, #0
    800173dc:   E1A07003            mov        r7, r3
    553       {
    800173e0:   E24DD058            sub        sp, sp, #0x58
    117           if (openfiles[i].handle == -1)
    800173e4:   E7935184            ldr        r5, [r3, r4, lsl #3]
    800173e8:   E3750001            cmn        r5, #1
    800173ec:   E1A06184            lsl        r6, r4, #3
    800173f0:   0A000024            beq        #0x80017488
    116         for (i = 0; i < MAX_OPEN_FILES; i++)
    800173f4:   E2844001            add        r4, r4, #1
    800173f8:   E3540014            cmp        r4, #0x14
    800173fc:   1AFFFFF8            bne        #0x800173e4
    563             errno = EMFILE;
    80017400:   EB000114            bl         __errno
    80017404:   E3A03018            mov        r3, #0x18
    564             return -1;
    80017408:   E3E05000            mvn        r5, #0
    563             errno = EMFILE;
    8001740c:   E5803000            str        r3, [r0]
    564             return -1;
    80017410:   EA000028            b          #0x800174b8
    592         if ((flags & O_CREAT)
    80017414:   E59F30B0            ldr        r3, [pc, #0xb0]
    590           aflags |= 2;
    80017418:   E2095002            and        r5, r9, #2
    592         if ((flags & O_CREAT)
    8001741c:   E1190003            tst        r9, r3
    595           aflags |= 4;
    80017420:   13855004            orrne      r5, r5, #4
    597         if (flags & O_APPEND)
    80017424:   E3190008            tst        r9, #8
    600             aflags &= ~4;
    80017428:   13C55004            bicne      r5, r5, #4
    606         block[2] = strlen (path);
    8001742c:   E1A0000A            mov        r0, r10
    601             aflags |= 8;
    80017430:   13855008            orrne      r5, r5, #8
    605         block[0] = (int) path;
    80017434:   E58DA000            str        r10, [sp]
    606         block[2] = strlen (path);
    80017438:   FAFFB892            blx        strlen
    607         block[1] = aflags;
    8001743c:   E58D5004            str        r5, [sp, #4]
    606         block[2] = strlen (path);
    80017440:   E58D0008            str        r0, [sp, #8]
    110         asm volatile ("mov r0, %1; mov r1, %2; " AngelSWIInsn " %a3; mov %0, r0"
              do_AngelSWI():
    80017444:   E3A05001            mov        r5, #1
    80017448:   E1A00005            mov        r0, r5
    8001744c:   E1A01008            mov        r1, r8
    80017450:   EF123456            svc        #0x123456
    80017454:   E1A05000            mov        r5, r0
    619         if (fh >= 0)
    80017458:   E3550000            cmp        r5, #0
    8001745c:   BA000005            blt        #0x80017478
    622             openfiles[fd].pos = 0;
    80017460:   E3A03000            mov        r3, #0
    80017464:   E0876006            add        r6, r7, r6
    621             openfiles[fd].handle = fh;
    80017468:   E7875184            str        r5, [r7, r4, lsl #3]
    622             openfiles[fd].pos = 0;
    8001746c:   E5863004            str        r3, [r6, #4]
    623             return fd;
    80017470:   E1A05004            mov        r5, r4
    80017474:   EA00000F            b          #0x800174b8
    626           return error (fh);
    80017478:   E1A00005            mov        r0, r5
    8001747c:   EBFFFED8            bl         error
    80017480:   E1A05000            mov        r5, r0
    80017484:   EA00000B            b          #0x800174b8
    569             && (flags & O_EXCL))
    80017488:   E2093C0A            and        r3, r9, #0xa00
    568         if ((flags & O_CREAT) 
    8001748c:   E3530C0A            cmp        r3, #0xa00
    80017490:   E1A0800D            mov        r8, sp
    80017494:   1AFFFFDE            bne        #0x80017414
    573             res = _stat (path, &st);
    80017498:   E1A01008            mov        r1, r8
    8001749c:   E1A0000A            mov        r0, r10
    800174a0:   EBFFFFAF            bl         _stat
    574             if (res != -1)
    800174a4:   E3700001            cmn        r0, #1
    800174a8:   0AFFFFD9            beq        #0x80017414
    576       	  errno = EEXIST;
    800174ac:   EB0000E9            bl         __errno
    800174b0:   E3A03011            mov        r3, #0x11
    800174b4:   E5803000            str        r3, [r0]
    627       }
    800174b8:   E1A00005            mov        r0, r5
    800174bc:   E28DD058            add        sp, sp, #0x58
    800174c0:   E8BD47F0            pop        {r4, r5, r6, r7, r8, r9, r10, lr}
    800174c4:   E12FFF1E            bx         lr

    The disassembly for the __sflags() and _swiopen() functions, for which the CCS debugger has annotated with the source statements, shows that the O_BINARY conditional compilation blocks are NOT included.

    Therefore, the cause of the problem is that the GNU newlib which is included with SYS/BIOS hasn't not been compiled to support the binary mode option to fopen(). I have not yet investigated how the SYS/BIOS newlib is built.

  • In reply to Lakshmi Sankar:

    Lakshmi Sankar
    Even in "rb" mode, the fread() is unable to read expected number of bytes from the specified file. Whenever fread() finds "1A" in the file, returns EOF. Please let us know correct tool versions for fread() to work in expected way.

    As mentioned in the previous post, I think the newlib which is used by SYS/BIOS needs to be re-compiled to include support for binary mode in the fopen() parameters.

    I haven't yet investigated re-compiling the SYS/BIOS newlib, but a work-around I found that it is possible modify the GEL script used for the Cortex-A15 to intercept the Semihosting SYS_OPEN and force the mode of all files to be binary.

    For my test example running on a Cortex-A15 in an EVMK2H the following was added to the xtcievmk2x_arm.gel GEL script:

    #define SYS_OPEN 0x1
    
    /* Opcode for the Semihosting Trap Instruction used for "A+R Profile" with "A32" Instruction Set as per
     * https://developer.arm.com/docs/100863/latest/the-semihosting-interface */
    #define SVC_INSTRUCTION 0xEF123456
    
    /* After the program is loaded install a breakpoint on the Semihosting trap instruction in the _swiopen function.
     * This uses a fixed offset into the _swiopen function which was determined for
     * bios_6_73_01_01/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard\librdimon_nano.a
     * 
     * Other BIOS versions may have a different offset to the Semihosting trap instruction, and so a sanity check is made
     * that the Semihosting trap instruction is present at the expected offset before installing a breakpoint.
     * 
     * The breakpoint is set on the Semihosting trap instruction, rather than SVC_ Handler, to avoid conflict with the
     * Semihosting handler in the CCS debugger.
     */
    OnFileLoaded()
    {
        unsigned int *expected_svc_instruction=_swiopen + 0x88;
        unsigned int instruction = *expected_svc_instruction;
        
        if (instruction == SVC_INSTRUCTION)
        {
            GEL_BreakPtAdd (expected_svc_instruction);
            GEL_TextOut ("Patched into _swiopen for forcing binary mode\n");
        }
        else
        {
            GEL_TextOut ("Failed to patch into _swiopen, as SVC instruction not at expected address (*%x=%x)\n",,,,,expected_svc_instruction,instruction);
        }
    }
    
    /* After the target has halted, check if have halted at a Semihosting trap instruction and:
     * a. If a SYS_OPEN request force the file mode to be binary.
     *    This is a work-around since as of bios_6_73_01_01 the GNU runtime hasn't been compiled with support for O_BINARY.
     *    This means programs which require to access binary files will work on CCS hosted under Windows.
     *    
     *    The correct fix would be to compile the BIOS GNU runtime to support binary mode in the fopen() call. 
     * b. Automatically resume the target.
     */
    OnHalt()
    {
        unsigned int instruction=*PC;
        if (instruction == SVC_INSTRUCTION)
        {
            if (R0 == SYS_OPEN)
            {
                /* Parameters for the SYS_OPEN Semihosting call parameters as defined by
                 * https://developer.arm.com/docs/100863/latest/semihosting-operations/sys_open-0x01
                 * 
                 * The least significant mode bit being set means binary mode. */ 
                unsigned int *filename = R1;
                unsigned int *mode = R1+0x4;
                unsigned int *filename_len = R1+0x8;
                unsigned int binary_mode_mask = 0x1;
    
                /* If the SYS_OPEN mode isn't binary, then modify the mode to force the host to open it as binary, and report
                 * that have modified the mode. Since GEL doesn't support reading strings from the target, the actual filename for
                 * which are modifying the mode isn't reported. */
                unsigned int original_mode = *mode;
                if ((original_mode & binary_mode_mask) == 0)
                {
                    unsigned int modified_mode = original_mode | binary_mode_mask;
                    *mode = modified_mode;
                    GEL_TextOut ("Changed SYS_OPEN mode from %u->%u to force binary mode for filename of length %u at address %x\n",,,,,
                                 original_mode, modified_mode, *filename_len, *filename);
                }
            }
            GEL_Run();
        }
    }

    With the above, the test program then correctly created and read back a binary file using SYS/BIOS 6_73_01_01 and CCS 8.3 running under Windows. The following output was displayed in the CCS debugger Console to indicate the modified GEL script was changing the file mode:

    arm_A15_0: GEL Output: Patched into _swiopen for forcing binary mode
    arm_A15_0: GEL Output: Changed SYS_OPEN mode from 0->1 to force binary mode for filename of length 21 at address 0x8001B85C
    arm_A15_0: GEL Output: Changed SYS_OPEN mode from 4->5 to force binary mode for filename of length 14 at address 0x80019390
    arm_A15_0: GEL Output: Changed SYS_OPEN mode from 0->1 to force binary mode for filename of length 14 at address 0x80019390

    The first SYS_OPEN mode change is when the GNU run-time library startup opens the special :semihosting-features file to access Semihosting extensions

    The second SYS_OPEN mode change is the test program calling fopen ("A15_binary.dat", "wb") and the third is is the test program calling fopen ("A15_binary.dat", "rb")

  • In reply to Chester Gillon:

    Chester Gillon
    Therefore, the cause of the problem is that the GNU newlib which is included with SYS/BIOS hasn't not been compiled to support the binary mode option to fopen().

    I performed a test with a bare-metal program for a Cortex-A15 using GNU 7.2.1 compiler installed by CCS, and the runtime provided with the GNU compiler does support passing the binary mode option from fopen() to the Semihosting SVC_Handler.

    I.e. the problem is only apparent in the GNU runtime which has been rebuilt for SYS/BIOS (which is re-entrant for SYS/BIOS applications for Cortex-A GNU targets)

  • In reply to Chester Gillon:

    I am also able to reproduce the issue. I filed a big for this, tracking ID: CCDSK-3413

    Thanks
    ki

    -----------------------------------

    Did you read the CCS Forum Guidelines & FAQ? If not, PLEASE read it. If you haven't read it in awhile, please read it again to see if any updates were made.

    Having CCS problems? Check out the CCS Troubleshooting Guide

    Looking for CCS Training? Check out the CCS Training Site

    Curious about the status of a bug and know the tracking ID? Track it via the public bug tracking portal

    NOTE: When a bug is filed and a tracking ID is provided, the thread may then be suggested as "TI Thinks Resolved". Why? Please read the first FAQ of the CCS Forum Guidelines & FAQ

  • In reply to Ki-Soo Lee:

    Hi Guys,

    Thanks for responding quickly. I regret that I couldn't try out similar experiment as u guys. Next week me or my team will try the same and ask for support if required.

    Thanks & Regards,

    Vishwanath Patil

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.