TMS320C671X: Error: Illegal opcode (403a0000) at pc = 0xb00085ec Illegal opcode at pc = 0xb00085ec

I've looked at this a bit, and I can see that you have some memory configuration issues.  The short answer is you're getting these invalid opcode messages because as the imgweight function is performing its loops, it winds up overwriting your code.  The invalid opcodes are really values of the normface array that overwrite the actual instructions that you want to execute.

You've got HUGE arrays defined as local variables in main.  Make these global arrays, which will put them in the .bss section of the memory map and they will be allocated at compile time.  That may solve the problem, because it keeps from having to put these arrays on the stack.   If not, you should instrument your code a bit and continue to debug.  Put in printfs and see how many times your loop executes before these errors occur.  Set breakpoints and step through, looing at the assembly and seeing if it makes sense.  If you had debugged a bit further, it would have been obvious that the code had been overwritten.  Anytime you see instructions in the disassembly that look like " .word 0x010101010", it's a sign that the program memory has been corrupted.

Regards,

Dan

Ohh i see..Thanks a lot Dan..

Well i debugged it over and over again but was not thinking it from that perpsective.

Yeah i know it executes upto a certain fixed number and then it gives this error.

I also checked the assembly to find the the opcode is sometimes 0x834000 

(which is strangely the total size of our data in hex).

Now thinking on what u said,we know that thats our error.

I thought that enough memory is allocated to everything also the data is about 20.5 Mb

(as these are eigenfaces of 26 VGA images),

i was not sure why this error is arising..

But thanks,now we know the error.

We tried a possible 2 solutions

1) Moved .TEXT to other memory(EMIFCE1)

2)Assigning the global data (like u hinted)

in both cases this problem got solved.BUT WE GOT A NEW ERROR OF RESOURCE CONFLICT:

"TMS320C671X: Error:   Memory Map Error: WRITE access by CPU to address 0x40000, 

which is RESERVED in Hardware."

We investigated the registers and variables and found that a data pointer has address 

0x00 and it grows from there.

It stops after growing 0x8000(32768) locations

Now why is this happening.We dont even want our variables to touch that sections of memory

Can u identify the possible problems in the memory configurations  

so we can execute our program without any conflicts.

Thanks in advance,

Mehul Saxena

I'll have to investigate a bit more, but first, let me say that your solution #2 is NOT a solution.  Here's one difference between #1 and #2.  

When you define something as a global, space gets allocated by it in the .bss section.  So the compiler/linker goes off and marks a specific set of space for this array in the .bss seciton.  If you look at the generated map file you should see the space allocated for these.  Also, if the linker doesn't have enough memory to store these, it will give you an error. 

When you have these defined as local variables, they get allocated on the stack.  Now the compiler does allocate some space for the stack as designated by the -stack directive in your linker command file.  You currently have -stack 0x2000, which is obviously way too small.  So, think about what happens when you declare these local variables in main.  These huge arrays just get pushed onto the stack.  But you won't get any immediate error message.  But think about what happens to all of the other memory that is allocated above the stack.  When you put any values in these arrays, you're overwriting some portion of memory that you don't mean to.  When you call a function, the register context and return parameters are pushed onto the stack, overwriting other memory that you are not intending.  Merely moving the .TEXT section to some other portion of memory may keep you from getting the specific error that you had been getting, but that doesn't prevent other memory from getting overwritten.  

I suspect that the next issue you are encountering comes from this code:

  if (b->size[1] == 0) {
  } else {
    ib = 0;
    for (jtilecol = 1; jtilecol <= mv[1]; jtilecol++) {
      ia = 0;
      for (k = 0; k < 76800; k++) {
       b->data[ib] = normface[ia];
        ia++;
        ib++;
      }
    }
  }

b->data is just a pointer to a memory location.  But when I get to the first instance of this code, b->data is not initialized.  So it's using 0 as the base address for the b->data array.  

Look at your call to dynamically allocate this memory.

    newData = calloc((uint32_T)loop_ub, (uint32_T)elementSize);
    if (emxArray->data != NULL) {
      memcpy(newData, emxArray->data, (uint32_T)(elementSize * oldNumel));
      if (emxArray->canFreeData) {
        free(emxArray->data);
      }
    }

    emxArray->data = newData;
    emxArray->allocatedSize = loop_ub;
    emxArray->canFreeData = TRUE;
  }

You call calloc, but you never check to see whether the newData pointer is null.  (Spoiler alert...it is).  So, you just assign zero to emxArray->data, and when you start iterating through the loop containing the line below.  You should always check to see if a returned pointer is null when dynamically allocating memory.  Otherwise, you run into difficult to debug issues.

b->data[ib] = normface[ia];

you're using the address 0x0 as the base for the b->data array. The loop goes on until you get to iteration 0x8000 (32768). At this point, what's the actual byte offset from the start of the array? Well, it's 0x8000 elements * the size of a void pointer (8 bytes) = 0x40000. So this is where it's trying to access address 0x40000.

You really need to make an attempt to step through this and see what's going on.  Add printfs that output every thousand values of k in the loops.  Try to find out exactly where the fails are occurring.  Once you've narrowed this down to a location, set breakpoints when you get to the error condition locations. Step through the assembly code and see exactly which instruction is making the access that is giving the error.

Keep in mind that you don't have unlimited memory.  Ask yourself "Why would calloc fail?".  The most likely answer is that there wasn't enough memory to be allocated. Assuming this is the case, how does calloc choose what portion of memory that it allocates from?  (Answer in the C compiler guide).  And how do you increase the size of that section (answer in the C Compiler guide).  

Regards,

Dan

Thanks Dan.

Well we increased both Stack and Heap size to Fit our Array and hoped that would be fine,

but then we got that error that i mentioned.

So we investigated the issues by Stepping like u said (before reading your reply)

and we also came to the same conclusion.

Its the pointer b->data that is getting initialized to 0x0

and yeah it will write till it gets to the area where the write permissions are available.

We have started reading the compiler guide and getting a lot of information and we are loking for the particular situation.

In the meantime i am also trying to reduce the size of the files by using QCIF resolution for images.

That would reduce the count from 76800 to 25344

(but this is only feasible if the desired accuracy is still maintained .I will test this and post here)

Returning to the solution that you mentioned,

We figured that as the calloc is failing, its using 0x0 as base address and then starts writing from it.

But then we know that calloc data is placed in the heap region.So i will first try to increase the heap size.

Also if that fail we would do more aggressive debugging like you mentioned.

I will post the result of this experiment in few days.

PLEASE GIVE US THE LINK OF THE APPROPRIATE COMPILER GUIDE

(we are not sure that the guide which we are reading is appropriate).

Right now i am working on this solution:-

As you mentioned that b->data is not initialized,we tried to initialize it to 0x90000000.

It is getting initialized there and its working fine.

But when i run w/0 stepping,we get the same error.

I guess at some point it is getting reinitialized to zero and that is the point of the error.

My work is to find that point now.

After i get that right,

i will make a post of creating a project step by step

and all the error that a user can face at every step.

Right now,i believe that i am in the last step

Thanks,

Mehul Saxena

Ohh i see...

thanks a lot Dan.Thats a good news.

I suspected that Heap is not enough.I set that 0x1000000 then it was not working.

So i modified the program for QCIF format.

My QCIF program worked PERFECTLY for current heap size.

Also i changed the heap size for the program 0x2000000.It is executing now.

Can you post the our working project that u modified so we can compare both of them and learn something from it.

I am verifying this answer.also our project is almost over.

I will make a post of creating a software and then loading it on hardware to make a stand-alone application

HOPE THIS LITTLE STEP OF MINE WILL BE  HELPFUL TO OTHERS.

Thanks,

Mehul saxena

Thanks a lot Dan..

I will post the updates on my current project Soon..

We are in the final stages.

Our post will be helpful to many..

mehul saxena said:

I am facing a strange problem that says:-

TMS320C671X: Error: Illegal opcode (403a0000) at pc = 0xb00085ec Illegal opcode at pc = 0xb00085ec  

I am using the Texas instruments simulator for TMS320C6713. I am using the Functional accurate mode.

We have successfully build our program and also able to load the data in all the three variables using "memory load" option.

Everything works fine till the last line of the code, where we call "imgweight" function.

We are using CCS v5 (version  5.1.0.09000 )

I have created a command file and assigned everything in the External memory.

The code works fine till the last line where we get the following error

How can this error arise if the compiler is the DEVICE SPECIFIC.

How can a comiler produce OPCODE THAT IS ILLEGAL.

I am attaching my project for more information. Please look into it and give me a solution.

Please Load the "AJAX.DAT" file on 0x80000000 location while checking.

It contains every data required to be processed.

Note:our program runs perfectly till the line(262) where the code:-

n=26;

is written.

Then when we execute the last line(263):-

imgweight(f, n, mt,y,w,normface);

we get this error.

I am adding the project:-

8686.embimgwt.zip

Thanks,

Mehul for posting this stuff.

I also got the same error and this conversation helped me a lot to clear my lot of doubts.

In my project i also declared a large array  (int Data_Bits[10000]).

default stack size was 0x1000 = 4096 bytes,

after building it successfully when i ran the program then i got this error and some times my CCS got crashed.

and now i just change the default size to 0x3000 = 12,288 bytes and my program is working correctly without that weird error.