LAUNCHXL-F28379D: Entering into illegal ISR when DELAY_US is called, even after doing memcopy at the initial

hi Akshay,

Which example of the C2000ware are you trying to run ?

Does the code work when you use the CPU1_FLASH configuration?

Can you check if this post is useful?
e2e.ti.com/.../572414

Regards.

No I am not running any C2000ware example.

I have tried 

#ifdef _FLASH
memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
#endif

also. It is there in my code. Can you review my code?

Thanks,

Akshay Godase

Hi team,

Is there any document which guides you to understand how to debug when code enters into Illegal ISR....?

If yes, please send me, if no please let me know the steps to be carried out for debugging?

Thanks,
Akshay

Akshay,

This function is a macro that is coded in asm vs C to give an exact cycle count in micro-seconds.  Just want to make sure you have included this file in your pjt located at   C:\ti\c2000\C2000Ware_1_00_06_00\device_support\f2837xd\common\source\F2837xD_usDelay.asm

The reason this needs to be ran from RAM, is again related to the cycle counts being accurate and the RAM being 0WS.

In terms of debugging a Illegal ISR, you will need to do the following:\

1)Once in the Illegal ISR and Halted; open the CPU Registers window on the core you are debugging(View-Registers then expand the Core Registers)

2)Find the Stack Pointer, SP register.

3)The stack pointer value will be a 16-bit immediate address where the stack is being maintained in memory

4)When any ISR is called(including illegal) there is certain information saved to the stack, the relevant info here is the return address.  This will be the address after the illegal instruction was fetched.

5)Decoding the SP contents are as follows, you can see where the code tried to execute an instruction but got an illegal(usually 0x0000 or 0xFFFF) back. In terms of how the code got there, you can look back further in the stack or at the RPC register for normal function calls' return address

Let us know what you find, I suspect that the macro is not getting placed where it needs to, but this should point us to where the linker thinks it SHOULD be and we can work from there.

Best,
Matthew

Hi Matthew,

This issue is resolved partially now. I had some part of code like:

#pragma CODE_SECTION(GetMax,".xtraCode")

Uint8 GetMax(Uint16* Array, Uint8 Length){

Uint16 Max;

Uint8 i;

Uint8 MaxIndex;

i=0;

Max=0;

for(i=0;i<Length;i++){

if(Array[i]>Max){

MaxIndex=i;

Max=Array[i];

}

}

return MaxIndex;

}

This .bigcode was not defined in my linker command file.  I commented out this file and code started working fine but in the "debug" mode.

When I tried to flash the code using this option,

nothing happened. I tried to reset the launchpad and I was expecting data on UART which was available when I was working in debug mode but it failed. Also I was expecting at least change in LED which is part of my code debug. Nothing worked as it works in debug mode. I want to know an issue. Can you please guide me?

Thanks,

Akshay Godase 

Akshay,
In most of our example projects in C2000Ware we have dual Build Targets; one for SRAM and one for FLASH.

The source code is the same, but what changes is the following:

1)In the "predefined" symbols(in project properties/advanced options/predefined symbols) a _FLASH symbol is added, to enable the compilation of any .if statements in the C source
2)The linker (.cmd) file is changed from the RAM to the FLASH versions, to account for different loading/running addresses.

I'm not sure if you are using different build options or just changing your source/linker manually. My point is that if you are relying on any of the automatic compilation includes from TI's source files then the _FLASH symbol will need to be added to your predefines.

Let me know if this is accounted for in the above.

Best,
Matthew