CCS/TMS320F28379D: code execution lands in boot ROM ESTOP

Reto, 

Once you step over Fapi_setActiveFlashBank(Fapi_FlashBank0), do you have any way of seeing what the Fapi_StatusType variable holds?

You can refer to this document: 

https://www.ti.com/lit/spnu629

Under Section 3.2.1, you can see how the variable oReturnCheck records the status of the function call, and the value of the variable will help you understand why the function call may be failing. 

Thanks, 

Anu

Anu,

Since the function does not return I do not get a return value. The code window shows: "Break at address "0x3fe494" with no debug information available, or outside of program code." The Disassembly shows "7625 ESTOP0".

In this situation, when I look with Memory Browser at the flash holding the code I was executing I get a repeated pattern that does not reflect the code that should be there.

trying to restart the code gets immediately stuck at the same ESTOP instruction.

When I terminate the debug session and power cycle the board, the application seems to work fine. (flash does not seem corrupt).

Running the application without debugger seems to trigger a reset condition when trying to archive the parameters. The storage sector is not written to.

Reto, 

I see, thanks for the info. I will look into this further and get back to you on Monday/Tuesday. 

Thanks,

Anu

Reto, 

Please refer to section 2.3.3 of https://www.ti.com/lit/spnu629 and check that your Flash API usage is as described there. I would make sure that everything is configured properly, such as the following:

1 EALLOW and EDIS are being called correctly

2. The clock and waitstates are configured properly for Flash API usage on your device

3. The Flash API functions and user functions that call the API functions are all copied and running out of RAM correctly

Thanks,

Anu

Anu,

1. I have used EALLOW before and EDIS after every Fapi_ call, as defined in the Flash api manual.

2. The flash wait states are configured as in the examples in TI's F2837xD_SysCtrl.c:InitFlash(). Due to my 200 MHz system clock, Flash0CtrlRegs.FRDCNTL.bit.RWAIT = 0x3;

3. According to my map file, many Fapi_ functions are still in flash, specifically the functions from F021_API_F2837xD_FPU32.lib like Fapi_setActiveFlashBank(). This may be the problem. I have not figured out yet how to make those calls RAM based.

However, one thing puzzles me a lot: Today, I single-stepped the same code that failed Friday, and it worked without a problem. This problem seems to be very sensitive on something that I could not identify yet. Just as it appeared out of the blue, it now seems to have disappeared for now.

Hi Reto,

0x3fe494 is ITRAP ISR address in BROM -> This tells me that an invalid opcode is fetched somewhere. 

On this device, all of the flash API functions should be copied to RAM before execution.  It may seem to work fine from flash at times, but there will be corner cases that would cause failure.  Hence, they should never be executed from flash.

Please take a look at the linker cmd file provided in C2000ware at C2000Ware_3_03_00_00\device_support\f2837xd\examples\dual\flash_programming\cpu01\flash_programming_cpu1_FLASH.cmd.  In this linker cmd file, you will notice that flash API is mapped to flash for load and RAM for run as shown below.

GROUP
{
.TI.ramfunc
{ -l F021_API_F2837xD_FPU32.lib}

} LOAD = FLASHD,
RUN = RAMLS03,

Thanks and regards,
Vamsi