CCS/TMS320C6748: Write Error: Invalid File ID in CIO FIle

Pierce J

Part Number: TMS320C6748

Tool/software: Code Composer Studio

Hello!

I am working with the C6748 development kit. I am using Code Composer v7 to read from the GPIO pins and store the results in an array. When I try to run my code, I get the error shown below:

[C674X_0] Write error: Invalid File ID (30091) in CIO message!

I have been looking at other posts about this issue and have followed some of the suggestions made, such as increasing the stack and heap size and am putting .sysmem into DDR2 memory. Based on these changes, I feel like I should have more than enough space for the data I'm collecting. I am also using a malloc function for my "array" which I believe should be allocating everything into the heap. I do have one printf statement which I read could cause problems, but I see nothing wrong with it.

My code is below:

/**
* main.c
*/

#include "gpio.h"
#include <stdio.h>
#include "soc_C6748.h"
#include "lcdkC6748.h"
#include "hw_syscfg0_C6748.h"
#include <stdlib.h>
#include "psc.h"
#include "hw_types.h"
#define _SOC_C6748_H_

//#define EMIFA_READ_SETUP_RESETVAL (0x00)
//#define EMIFA_READ_STROBE_RESETVAL (0x00)
//#define EMIFA_READ_HOLD_RESETVAL (0x00)
//#define EMIFA_TA_RESETVAL (0x00)

int main(void)
{

PSCModuleControl(SOC_PSC_1_REGS, HW_PSC_GPIO,
PSC_POWERDOMAIN_ALWAYS_ON,
PSC_MDCTL_NEXT_ENABLE);

HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(0)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(1)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(2)) = 0x44444444;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(3)) = 0x44444444;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(4)) = 0x88888844;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(5)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(6)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(7)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(8)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(9)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(10)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(11)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(12)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(13)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(14)) = 0x00000088;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(16)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(17)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(18)) = 0x88888888;
HWREG(SOC_SYSCFG_0_REGS + SYSCFG0_PINMUX(19)) = 0x88888888;

unsigned int i = 0;
for (i = 0; i<= 144; i++){
GPIODirModeSet(SOC_GPIO_0_REGS, i, GPIO_DIR_INPUT);
}

int *data;
data = (int *)malloc(sizeof(int)*2500000);
unsigned int x = 0;
for (x = 0; x<= 2500000; x++){
data[x]=HWREG(SOC_GPIO_0_REGS + GPIO_IN_DATA(2));
}
printf("%d\n",sizeof(data)/sizeof(data[0]));
}

I am fairly new to code composer and the development kit, so I could just be making a silly mistake.

Any help would be appreciated!

over 8 years ago

0 Pierce J over 8 years ago

Prodigy 70 points

I forgot to mention in my post that this code seemed to work fine yesterday, but has started giving this error today. I'm not sure if I did something yesterday that fixed the error or did something today to cause it. I am very confused by it. I was using an actual array instead of the malloc function, but from what I understand malloc should have only helped.

0 Chester Gillon over 8 years ago in reply to Pierce J

Guru 92251 points

Pierce J said:
I was using an actual array instead of the malloc function, but from what I understand malloc should have only helped.

If the heap size isn't sufficient malloc() will return a null pointer which may cause the program to overwrite something else in memory.

From the posted code the heap size needs to be > 10,000,000 bytes.

The Heap Size can be set from the Project Properties -> Build -> C6000 Linker -> Basic Options -> Heap size for C/C++ dynamic memory allocation (--heap_size, -heap).

0 Pierce J over 8 years ago in reply to Chester Gillon

Prodigy 70 points

Thanks for the reply Chester.

I was looking into this issue more yesterday. It seems that the program doesn't have a problem allocating all the data, but creates this error when the printf statement at the bottom runs. If I understand correctly, I believe the printf function is part of the .cio section of the memory map. I tried mapping this section to a bigger memory area. Doing this caused the error below:

[C674X_0] Invalid CIO command (0) in the CIO buffer at address (0xD9000148) was not recognized. Please check the device and program memory maps.

Here is a picture of my memory map:

MEMORY
{
DSPL2ROM o = 0x00700000 l = 0x00100000 /* 1MB L2 Internal ROM */
DSPL2RAM o = 0x00800000 l = 0x00040000 /* 256kB L2 Internal RAM */
DSPL1PRAM o = 0x00E00000 l = 0x00008000 /* 32kB L1 Internal Program RAM */
DSPL1DRAM o = 0x00F00000 l = 0x00008000 /* 32kB L1 Internal Data RAM */
SHDSPL2ROM o = 0x11700000 l = 0x00100000 /* 1MB L2 Shared Internal ROM */
SHDSPL2RAM o = 0x11800000 l = 0x00040000 /* 256kB L2 Shared Internal RAM */
SHDSPL1PRAM o = 0x11E00000 l = 0x00008000 /* 32kB L1 Shared Internal Program RAM */
SHDSPL1DRAM o = 0x11F00000 l = 0x00008000 /* 32kB L1 Shared Internal Data RAM */
EMIFACS0 o = 0x40000000 l = 0x20000000 /* 512MB SDRAM Data (CS0) */
EMIFACS2 o = 0x60000000 l = 0x02000000 /* 32MB Async Data (CS2) */
EMIFACS3 o = 0x62000000 l = 0x02000000 /* 32MB Async Data (CS3) */
EMIFACS4 o = 0x64000000 l = 0x02000000 /* 32MB Async Data (CS4) */
EMIFACS5 o = 0x66000000 l = 0x02000000 /* 32MB Async Data (CS5) */
SHRAM o = 0x80000000 l = 0x00200000 /* 128kB Shared RAM */
DDR2 o = 0xC0000000 l = 0x20000000 /* 512MB DDR2 Data */
}

SECTIONS
{
.text > SHRAM
.stack > SHRAM
.bss > SHRAM
.cio > DDR2
.const > SHRAM
.data > SHRAM
.switch > SHRAM
.sysmem > DDR2
.far > DDR2
.args > SHRAM
.ppinfo > SHRAM
.ppdata > SHRAM

/* COFF sections */
.pinit > SHRAM
.cinit > SHRAM

/* EABI sections */
.binit > SHRAM
.init_array > SHRAM
.neardata > SHRAM
.fardata > SHRAM
.rodata > SHRAM
.c6xabi.exidx > SHRAM
.c6xabi.extab > SHRAM
}

Again, I'm pretty new to the board so I could be making a silly mistake.

0 George Mock over 8 years ago in reply to Pierce J

TI__Guru**** 250520 points

Please work through the suggestions in the article Tips for using printf, some of which have already been mentioned in this thread. I realize that will take a while, and I'm sorry about that. But I think that is the best way forward at this point.

Thanks and regards,

-George

0 Pierce J over 8 years ago in reply to George Mock

Prodigy 70 points

Thanks for the link George!

I was actually able to fix this issue by putting the .far section back into SHRAM and making sure my heap was big enough for the malloc function to allocate all that data into it. I don't have enough knowledge to know exactly why this fixed it. Looking at this document, www.ti.com/.../spru187o.pdf, it seems that global and static variables are put in the .far section. Since I had .far in DDR2, which is external memory, maybe the printf statement tried to access something saved in DDR2 but couldn't reach it?? Whatever it was, I think I have the issue resolved for now at least.

0 Archaeologist over 8 years ago in reply to Pierce J

TI__Guru* 84285 points

The only way it would be possible for printf not to be able to "reach" .far is if there was a relocation overflow, which would show up at link time as a warning. Did you get any warning or error messages from the linker?

I'm glad you were able to get the program working. Just for the record, how much heap and stack were you allocating in the linker command file? That is, what were the values of the --heap and --stack command line options?

0 Pierce J over 8 years ago in reply to Archaeologist

Prodigy 70 points

I did not get any errors or warnings from the linker. Just the error above for the printf statements.

My heap size was 0x1000000 and my stack size was 0x10000

Code Composer Studio™︎

Code Composer Studio forum

CCS/TMS320C6748: Write Error: Invalid File ID in CIO FIle