28027 illegal operation

Harrison,

Yes, you can find which instruction when executed can cause Illegal operation.

when you get an Illegal ISR, the PC value (pointing to the instruction after the illegal instruction) is saved on the stack.

Inside your illegal_ISR routine, please make this your first instruction.

MOVL     ACC,*-SP[2] ; ACC = return PC value from stack

Set a breakpoint at this instruction. Once it hits the breakpoint, single step. Now, the address of the instruction which triggered illegal isr is ACC-1.

Regards,

Manoj

Hi Harrison,

you can find exact location where TRAP is raised following : http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/40471/232783.aspx#232783

Regards, Mitja

Hi Mitja,

your link doesn't work, but I searched the link below

http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/40471/140885.aspx#140885

I followed your last post, but one thing for the instruction asm ("  B  $,UNC") is the offset has limit.

is this the link you talk about?

thank you

Harrison,

Is this problem resolved? Did my suggestion work?

Regards,

Manoj

I put your code and wait for its happening now.

thanks

Okay. Hope it helps you.

-Manoj

ok,the problem was reproduced.

it did trap the illegal operation and ACC's content is 0x3F622E, as you said,minus 1, we get the address triggering this, it is 0x33f622d and its instruction is LRETR.

 this is indeed in the code flash area, I tracked in the project.map and it is related to load start function, which is TI's assembly code, and LRETR is just return instruction.

so, I don't understand why this return instruction can cause illegal operation?

can ti have look at this if this code is wrong or any clues that I can continue trying to see if something else is wrong?

the code example and demo kit is HVPSFB, and the project is PCMC. 

I am stuck at here now, as this problem may happen a few minutes after running, or may not happen for a day.

by the way, thanks a lot for the trap code, it is really helpful.

thank you

here is related memory address which trigers the illegal operation:

0x3f6204:

 2821 0004 87BE C5BE C4BE 83BE 8ABE 82BE 86BE 0003 7602 7622 761F 002A 1A00 0001
CC06 F0FF 1AA9 0300 9606 CC06 FFF0 5003 9606 CC07 FFE0 5005 9607 1A04 01FF 1A05
01FF 761A F607 7700 FF69 0006 1901 56C3 FFFF 0006(this is0x003F622D= ACC-1)

this is the address in ACC:0x3f622E

0x3f622E:RamfuncsLoadEnd, .text, __text, DLOG_BuffInit

thanks

so far it has trapped 3 illegal operations, the first and the second are the same, the third is also the instruction LRETR, which is the end of one task, but this task is a normal task , not like the other two which is the load start.

thanks

Harrison,

I believe CPU takes an illegal itrap interrupt because it executes 0xFFFF at 0x3F622D. Try setting a breakpoint at 0x3F622D and hit run.Once it hits a breakpoint, single step and see whether it enters Illegal ISR routine.

Regards,

Manoj

Hi Harrison,

yup you've got the right link. Sorry about that, have to recheck when posting.

Anyhow I don't understand what you mean by branch instruction offset having limit? I am still on code generation tools v5, but as far as I can remember symbol "$" translates into current instruction address, thus the said line should basically act a infinite loop. And until now it has always worked for me. I would really like to hear your input on this.

Following your discussion I am extrapolating that you are using some kind of OS? This is where LRET instruction can (and obviously will) cause problems. From my experience, if you have any problem in OS kernel (more specifically task switching mechanism) when returning/entering into a different task, the OS might load CPU state with a slight offset (SP aligment on C28xx is really a PITA), thusthe CPU will continue execution somewhere else, not where was intended. If you are willing to elaborate on your setup I might be able to give a fresh/different perspective (that is what these forums are all about)

Regards, Mitja

Hi Mitja,

Thanks a lot for your post which is informative indeed.

I refered the instuction below which is described in TI's instruction guide(TMS320C28x CPU and Instruction Set Reference Guide)

B 16bitOff,COND

this is offset and conditional instruction; I didnot find your instruction B, $,UNC in this guide and when I tried to build with the absolute address using your code, CCS says the OFFset is too large.

this is why I couldn't use it.

how are you able to build the code without errors? could you post an simple example?

regarding the second question, yes  I am using a simple CPU timer based task kenerl, but this is a TI example. it using 3 CPU timers and each timer triggers a different set of tasks, about 1 to 3 tasks and I increased the tasks to 6 in timer1 based tasks.

I am very interested in what you said about the problem in task-switching , as so far it looks like very similar to what you said,the more tasks I added into the code, the more frquently the problem happens and everytime the problem happens, it may point any locations; however, sometimes no problem at all.

Appreciate it a lot for your input.

Hi Manoj,

the problem was reproduced many times now,but each time ACC shows different adderess, occasionly , ther are two or three are the same, but generally, it points anywhere in the memory.

thanks

Can you send the snapshot of the contents of memory pointed by the stack pointer?

-Manoj

ok, when it happens next time, I will catch one and post it here.the previous ones are not saved.

thanks

ok, this time,it doesn't trig the illegal operation trap.

it just says cannot read ACC,and request a rude retry; after I did,it stll cannot read anything, but the code is running.

when i paused the code and made a signle step exeucation, I found it actually stuck at this address:0x1F07F4,it loops here forever.

please have  a look at the attached.1018.problem1.pdf

next time , if it triggers an interrupt, I will post it again.

thank

HI Harrison,

regarding the example just open a CPU timers example from peripheral header files and put the following line at the start of main:

asm(" B $,UNC");

you should not substitute "$" with anything else, and "UNC" makes this branch unconditional.

Regarding the source of your problems:

1. Do you by any chance use _disable_interrupts and _enable_interrupts compiler intrinsics?

2. Do you have any assembly code in your project (besides what is provided by TI)

3. Are you sure you are always exiting interrupts (increase a counter at the beginning of the interrupt and decrease at the end, if it is no at zero you've got problems) ?

4. You might have stack overflow errors (most likely by your symptoms and code description).

Fill the stack with known value:GEL script: GEL_MemoryFill(stack_start,1,stack_end-stack_start,0xBEEF);

and you need to declare symbols in linker file:

.stack:     >       D_M1,  /* or whereever*/
                        RUN_START(_stack_start),
                        RUN_END(_stack_end),    
                                            PAGE = 1

Good luck, Mitja

Many thanks,Mitja.

yes, the instruction works, I misunderstood it by replacing with an absolute address, sorry.

regarding others question, I will try and let you know later.

Again, appreciate it a lot.

Manoj Santha Mohan said:

Can you send the snapshot of the contents of memory pointed by the stack pointer?

-Manoj

ok, here it caught another illegal operation and please see the snapshots attached.

the first one show it stoped and trapped in the interrupt code, ACC number:0x0000828f;

the second one show the memory of the related code.

the last one show the memory at 0x0000828f;

thank you,0334.snapshotall.pdf

HI Mitja,

1)I didn't find this disable and enable interrupt in compiler option.

2)I only use simple Assembly like NOP and the pair of  EDIS and ELLOw.

3)I didn't write any interrupt code of my own,all are TI's,basically I just add very simple tasks into TI demo code.

4)yes, my guess is stack flow too, just don't understand why.I will try you linker file.

Thanks a lot.

Hello,

where is the linker file located?I ddin't find it.

Thank you,

You can easily check whether address 0x828F causes the breakpoint. Try the following:

1. Set a breakpoint @ 0x828F. 
2. Hit Run.
3. Once it hits the breakpoint, Single step and check whether PC enters Illegal ISR routine.

Regards,

Manoj

For linker file, look under build options somewhere.

/Rant:

I hate how TI hid/automated some of the compilation configuration options in CCS4. Programing for C2000 requires the programmer to know the hardware, memory map, linker options and compiler libraries. While automating these task enables a quick start for newbies, it works until they hit the boundaries of generic setup proposed by TI. There is a lot more questions (noise) on these forums about basic programing concepts, since then.

/end Rant

What you should be able to see is where does your stack start, and under linker options you should see the stack size, thus you can calculate stack end address. So if you look at the SP value when you hit the trap interrupt, you can at least see where are you with the available stack space.

Mitja

Hi Manoj,

I have a very interesting discovery,please have a look at the the attached.

watch: row No.956 at 0x3F624F was compiled as ESTOP0?

 this is after one successful compile with no mistakes, I only found the proble when it stops here.

what happened?8117.wrong_compiled.pdf

Harrison,

ESTOP0 is emulation stop 0. Executing ESTOP0 shouldn't trigger Illegal ISR. Please find description of ESTOP0 attached below.

Regards,

Manoj

Manoj Santha Mohan said:

Harrison,

ESTOP0 is emulation stop 0. Executing ESTOP0 shouldn't trigger Illegal ISR. Please find description of ESTOP0 attached below.

Regards,

Manoj

Hi  Manaoj,

I knew ESTOP is the insrtuction, my point is I didn't have this instruction in my code and I didn't add this breakpoint either.

 the code is mytimer = 0, which should not be compiled into ESTOP.

in another word, the compliler made a mistake.

please have a look at that memmory snapshot again.

thanks

4530.Fdisassembly2.pdf

Manoj Santha Mohan said:

Harrison,

ESTOP0 is emulation stop 0. Executing ESTOP0 shouldn't trigger Illegal ISR. Please find description of ESTOP0 attached below.

Regards,

Manoj

Hi Manoj,

please have a look at the attached, the same code, but it was compiled correctly this time.

mytimer1= 0 was compiled to MOV @0x3b,#0

Okay, now I understand. How did you get this fixed? Did it solve your problem.

-Manoj

Manoj Santha Mohan said:

Okay, now I understand. How did you get this fixed? Did it solve your problem.

-Manoj

I did nothing.

after I found this mistake, then I rebulid it , the second time it is right..

this puzzles me as I begin worrying that some illegal operations might be indeed are illegal due to wrong compiling.

it just happen that this wrong comoling results in ESTOP, so I can know it; if it was compiled into something else, then I might never find it.

I am using CCS(0004), does this version has ever had problems with compiling mistakes?

thanks

thanks

Harrison,

I am really glad that your problem has been resolved. And it is interesting to note the whole episode is due to a compiler issue. I have personally not heard of any such issue before. It will of great help to us if you can provide any extra information which can help us resolve this issue. So, can you provide any other information other than the ones posted in this forum. I shall bring this issue to our CCS compiler groups attention.

Regards,

Manoj

Manoj Santha Mohan said:

Harrison,

I am really glad that your problem has been resolved. And it is interesting to note the whole episode is due to a compiler issue. I have personally not heard of any such issue before. It will of great help to us if you can provide any extra information which can help us resolve this issue. So, can you provide any other information other than the ones posted in this forum. I shall bring this issue to our CCS compiler groups attention.

Regards,

Manoj

Hi Manoj,

the problem has not been solved, it just didn't happen this time; I have been in this kind of trouble for a few months.

I 'd like to offer more information as I believe it would happen again,however, you need to let me know what kind of information you want; I don't know what will help your guys to identify this problem.

thank you 

Hi Harrison,

by your description it was probably just a case of compiler (linker more specifically)  placing the "DSP2802x_DefaultsIsr.c" differently each build, thus once you observed ESTOP0 at a certain address and once you didn't.

Did you check the SP value when the fault happens?

Regards, Mitja

Hi Mitja,

please have a look at the snapshots again.

if it is the linker that inserted ESTOP into the code, then Mytimer1 = 0 should be compiled to something like "MOV,xx,0"; .i.e. everthing should be compiled right, it is just one more estop, whic was inserted by linker somehow.

however, it is not the case becasue Mytimer1 = 0 was not compiled into any instructions, it was simply compiled as ESTOP.

I remmeber I checked SP and didn't think it was wrong, but I will check it again next time to make sure.

thanks

Hi Harrison,

I must apologize for not looking at the snapshot and only guessing by briefly reading the description.

I somewhat learned to trust the compiler and the TI tools after years of blaming them, only to find out later that it was my fault at in the end, so I always consider the mistakes in the code.

It is truly weird to see the ESTOP0 instruction where it is(was). As the location is in FLASH so there is no possibility for even a runaway pointer to write (or copy) at that location. On the other hand I seriously doubt it that the compiler has support to generate ESTOP0 instruction, so your conclusion about the linker seems on the spot.

Do you have any optimization enabled?

Do you by any chance have and use FLASH API in your system?

I have to ask: Are your FLASH wait-states set up according to specs?

Coming back to the first problem: Do you allow nesting of interrupts?

Regards, Mitja

Hi Mitja,

that's alright.

I agree with you that mostly it is code's fault.I never doubted compiler either until I saw this one.

even at this time, I doubt if this is the problem of miscomunication of the debugger, but I don't know, the fact is the code stops at this instruction.

regarding your questions , please see below and please let me know if you need more inofrmation.

optimization is disabled;

I don't have any additional flash API systems, actually my code is originally a TI example project: HVPSFB-PCMC project, I only added a few very simple tasks and the rest remian unchanged.

this is to say, I didn't touch interrupt setting at all: if the TI original code allows interrupt nesting, then it is; I am not sure on this and looking at this now; you can have at look  at the project by using controlsuite: HVPSFB-pcmc,too.

I didn't change the wait setting either, it remains TI original, so the setting should be right.

thank you.

I read the code related to interrupt, I don't see it has nested interrupt.

thanks