TMS320F28375S: Application crashes after migration from coff to eabi format

Robert,

I want to start with the code_start_branch.asm not being in the new .map file; that needs to be there to have the correct branch at boot up.  In the last snippet of the .cmd file I only see the "MEMORY" area but not the proceeding "SECTIONS" area.  I was looking at some .cmd files we have for EABI compiled projects,I've pasted one of our C2000Ware example linker files that is EABI compiled as a reference.

You can see that there are some differences in section names from EABI vs the older COFF format.  You should also see an allocation to place codestart at "BEGIN" which for flash boot is at 0x80000 length of 2.  This is where the code start branch will get placed.

MEMORY
{
PAGE 0 :  /* Program Memory */
          /* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
          /* BEGIN is used for the "boot to Flash" bootloader mode   */

   BEGIN           	: origin = 0x080000, length = 0x000002
   RAMM0           	: origin = 0x000123, length = 0x0002DD
   RAMD0           	: origin = 0x00B000, length = 0x000800
   RAMLS0          	: origin = 0x008000, length = 0x000800
   RAMLS1          	: origin = 0x008800, length = 0x000800
   RAMLS2      		: origin = 0x009000, length = 0x000800
   RAMLS3      		: origin = 0x009800, length = 0x000800
   RAMLS4      		: origin = 0x00A000, length = 0x000800
   RAMGS14          : origin = 0x01A000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
   RAMGS15          : origin = 0x01B000, length = 0x000FF8     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */

//   RAMGS15_RSVD     : origin = 0x01BFF8, length = 0x000008    /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   RESET           	: origin = 0x3FFFC0, length = 0x000002

   /* Flash sectors */
   FLASHA           : origin = 0x080002, length = 0x001FFE	/* on-chip Flash */
   FLASHB           : origin = 0x082000, length = 0x002000	/* on-chip Flash */
   FLASHC           : origin = 0x084000, length = 0x002000	/* on-chip Flash */
   FLASHD           : origin = 0x086000, length = 0x002000	/* on-chip Flash */
   FLASHE           : origin = 0x088000, length = 0x008000	/* on-chip Flash */
   FLASHF           : origin = 0x090000, length = 0x008000	/* on-chip Flash */
   FLASHG           : origin = 0x098000, length = 0x008000	/* on-chip Flash */
   FLASHH           : origin = 0x0A0000, length = 0x008000	/* on-chip Flash */
   FLASHI           : origin = 0x0A8000, length = 0x008000	/* on-chip Flash */
   FLASHJ           : origin = 0x0B0000, length = 0x008000	/* on-chip Flash */
   FLASHK           : origin = 0x0B8000, length = 0x002000	/* on-chip Flash */
   FLASHL           : origin = 0x0BA000, length = 0x002000	/* on-chip Flash */
   FLASHM           : origin = 0x0BC000, length = 0x002000	/* on-chip Flash */
   FLASHN           : origin = 0x0BE000, length = 0x001FF0	/* on-chip Flash */

//   FLASHN_RSVD     : origin = 0x0BFFF0, length = 0x000010    /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

PAGE 1 : /* Data Memory */
         /* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */

   BOOT_RSVD       : origin = 0x000002, length = 0x000121     /* Part of M0, BOOT rom will use this for stack */
   RAMM1           : origin = 0x000400, length = 0x0003F8     /* on-chip RAM block M1 */
//   RAMM1_RSVD      : origin = 0x0007F8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
   RAMD1           : origin = 0x00B800, length = 0x000800

   RAMLS5      : origin = 0x00A800, length = 0x000800

   RAMGS0      : origin = 0x00C000, length = 0x001000
   RAMGS1      : origin = 0x00D000, length = 0x001000
   RAMGS2      : origin = 0x00E000, length = 0x001000
   RAMGS3      : origin = 0x00F000, length = 0x001000
   RAMGS4      : origin = 0x010000, length = 0x001000
   RAMGS5      : origin = 0x011000, length = 0x001000
   RAMGS6      : origin = 0x012000, length = 0x001000
   RAMGS7      : origin = 0x013000, length = 0x001000
   RAMGS8      : origin = 0x014000, length = 0x001000
   RAMGS9      : origin = 0x015000, length = 0x001000
   RAMGS10     : origin = 0x016000, length = 0x001000

//   RAMGS11     : origin = 0x017000, length = 0x000FF8   /* Uncomment for F28374D, F28376D devices */

//   RAMGS11_RSVD : origin = 0x017FF8, length = 0x000008    /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   RAMGS11     : origin = 0x017000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
   RAMGS12     : origin = 0x018000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
   RAMGS13     : origin = 0x019000, length = 0x001000     /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */

   CPU2TOCPU1RAM   : origin = 0x03F800, length = 0x000400
   CPU1TOCPU2RAM   : origin = 0x03FC00, length = 0x000400
}

SECTIONS
{
   /* Allocate program areas: */
   .cinit              : > FLASHB      PAGE = 0, ALIGN(8)
   .text               : >> FLASHB | FLASHC | FLASHD | FLASHE      PAGE = 0, ALIGN(8)
   codestart           : > BEGIN       PAGE = 0, ALIGN(8)
   /* Allocate uninitalized data sections: */
   .stack              : > RAMM1       PAGE = 1
   .switch             : > FLASHB      PAGE = 0, ALIGN(8)
   .reset              : > RESET,      PAGE = 0, TYPE = DSECT /* not used, */

#if defined(__TI_EABI__)
   .init_array         : > FLASHB,       PAGE = 0,       ALIGN(8)
   .bss                : > RAMLS5,       PAGE = 1
   .bss:output         : > RAMLS3,       PAGE = 0
   .bss:cio            : > RAMLS5,       PAGE = 1
   .data               : > RAMLS5,       PAGE = 1
   .sysmem             : > RAMLS5,       PAGE = 1
   /* Initalized sections go in Flash */
   .const              : > FLASHF,       PAGE = 0,       ALIGN(8)
#else
   .pinit              : > FLASHB,       PAGE = 0,       ALIGN(8)
   .ebss               : >> RAMLS5 | RAMGS0 | RAMGS1,    PAGE = 1
   .esysmem            : > RAMLS5,       PAGE = 1
   .cio                : > RAMLS5,       PAGE = 1
   /* Initalized sections go in Flash */
   .econst             : >> FLASHF      PAGE = 0, ALIGN(8)
#endif

   Filter_RegsFile     : > RAMGS0,	   PAGE = 1

   SHARERAMGS0		: > RAMGS0,		PAGE = 1
   SHARERAMGS1		: > RAMGS1,		PAGE = 1
   SHARERAMGS2		: > RAMGS2,		PAGE = 1
   ramgs0           : > RAMGS0,     PAGE = 1
   ramgs1           : > RAMGS1,     PAGE = 1

#ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
        #if defined(__TI_EABI__)
            .TI.ramfunc : {} LOAD = FLASHD,
                                 RUN = RAMLS0,
                                 LOAD_START(RamfuncsLoadStart),
                                 LOAD_SIZE(RamfuncsLoadSize),
                                 LOAD_END(RamfuncsLoadEnd),
                                 RUN_START(RamfuncsRunStart),
                                 RUN_SIZE(RamfuncsRunSize),
                                 RUN_END(RamfuncsRunEnd),
                                 PAGE = 0, ALIGN(8)
        #else
            .TI.ramfunc : {} LOAD = FLASHD,
                             RUN = RAMLS0,
                             LOAD_START(_RamfuncsLoadStart),
                             LOAD_SIZE(_RamfuncsLoadSize),
                             LOAD_END(_RamfuncsLoadEnd),
                             RUN_START(_RamfuncsRunStart),
                             RUN_SIZE(_RamfuncsRunSize),
                             RUN_END(_RamfuncsRunEnd),
                             PAGE = 0, ALIGN(8)
        #endif
    #else
   ramfuncs            : LOAD = FLASHD,
                         RUN = RAMLS0,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_SIZE(_RamfuncsLoadSize),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         RUN_SIZE(_RamfuncsRunSize),
                         RUN_END(_RamfuncsRunEnd),
                         PAGE = 0, ALIGN(8)
    #endif

#endif

   /* The following section definitions are required when using the IPC API Drivers */
    GROUP : > CPU1TOCPU2RAM, PAGE = 1
    {
        PUTBUFFER
        PUTWRITEIDX
        GETREADIDX
    }

    GROUP : > CPU2TOCPU1RAM, PAGE = 1
    {
        GETBUFFER :    TYPE = DSECT
        GETWRITEIDX :  TYPE = DSECT
        PUTREADIDX :   TYPE = DSECT
    }

   /* The following section definition are for SDFM examples */
   Filter1_RegsFile : > RAMGS1,	PAGE = 1, fill=0x1111
   Filter2_RegsFile : > RAMGS2,	PAGE = 1, fill=0x2222
   Filter3_RegsFile : > RAMGS3,	PAGE = 1, fill=0x3333
   Filter4_RegsFile : > RAMGS4,	PAGE = 1, fill=0x4444
   Difference_RegsFile : >RAMGS5, 	PAGE = 1, fill=0x3333
}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

It also might be helpful to go to a recent C2000Ware example for F2837x, these are built with the EABI output option; you can take a look at the .cmd file there to see if there are some other differences.  My local path is C:\ti\c2000\C2000Ware_5_00_00_00\driverlib\f2837xd\examples\cpu1\

I'm not familiar with the ADCRESULTD file, but I believe the cinit tables, is where the binit for your flash to RAM copy is happening.

Let me know what you find and we can go from there.

Best,
Matthew

Matthew

Thank you for time investment and your reply.

your hint with the code_start_branch is quite helpful. I compared the coff map file with the eabi map file and it indeed there is no entry of code_start or an object of the CodeStartBranch.obj file. I'm now wondering, how did it happen, that the object file is missing there? And how do i set it up to generate it?
Regarding the Memory and Sections areas, I have not given fully information in the post. We separated the Sections and memory into separate files which I unfortunately not distincted in the post. The following snipped is the SECTIONS part of the linkerfile. It completes the last code snipped from my initial post.

SECTIONS
{
	/* Allocate program areas: */
	// data initialization section
	.cinit			: > FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
						FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
	// boot time initialization
	.binit			: > FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
						FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
	// C function initialization table
	.init_array			: > FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
						FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
	// text (program) section
	.text			: >> FLASHE | FLASHF | FLASHG | FLASHH | FLASHI PAGE = 0

	codestart		: > FLASHE PAGE = 0
	ramfuncs		: LOAD = FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
							 FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
					  RUN  = D01SARAM  PAGE = 0
					  RUN_START(RamfuncsRunStart),
					  LOAD_START(RamfuncsLoadStart),
					  LOAD_SIZE(RamfuncsLoadSize)
				{ -l IQmath_fpu32_eabi.lib
						(IQmath)
	            }

#ifdef __TI_COMPILER_VERSION
#if __TI_COMPILER_VERSION >= 15009000
	.TI.ramfunc 	: LOAD = FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
							 FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0,
					  RUN  = LS05SARAM PAGE = 1,
					  table(BINIT)
#endif
#endif

    /* Allocate uninitalized data sections: */
    // stack space
    .stack			: >  M01SARAM  | LS05SARAM    PAGE = 1 // > .stack output is not split
    // global variables
    .bss			: >> RAMGS0 | RAMGS1 | RAMGS3 | LS05SARAM  PAGE = 1 // >> .bss output is split
    // memory for malloc type functions
    .sysmem			: >  LS05SARAM | M01SARAM    PAGE = 1
    // console input/output functions
    .bss:cio		: >  LS05SARAM | M01SARAM    PAGE = 1

    /* Initalized sections go in Flash */
    // constant data
    .const			: > FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
    					FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
	// tables for switch statements
    .switch			: > FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
    					FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
	// argument buffer
    .args			: > FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
    					FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN PAGE = 0
	// reset vector
    .reset			: > RESET,     PAGE = 0, TYPE = DSECT /* not used, */

	/*** BLDC specific overlay ***/
  	ramBlm			:	LOAD = FLASHJ,		PAGE = 0
						RUN  = LOVERLAY,	PAGE = 2
						RUN_START(ramBlmRunStart),
						LOAD_START(ramBlmLoadStart),
						LOAD_SIZE(ramBlmLoadSize)

	/*** FOC motor specific overlay ***/
	ramFoc			:	LOAD = FLASHJ,		PAGE = 0
						RUN  = LOVERLAY,	PAGE = 3
						RUN_START(ramFocRunStart),
						LOAD_START(ramFocLoadStart),
						LOAD_SIZE(ramFocLoadSize)

	/*** DC motor specific overlay ***/
	ramDcm			:	LOAD = FLASHJ, 		PAGE = 0
						RUN  = LOVERLAY,	PAGE = 4
						RUN_START(ramDcmRunStart),
						LOAD_START(ramDcmLoadStart),
						LOAD_SIZE(ramDcmLoadSize)

	/* Section secureRamFuncs used by file SysCtrl.c */
	secureRamFuncs	:	LOAD = FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
							   FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN, PAGE = 0        /* Should be Flash */
                  		RUN  = LS05SARAM,    PAGE = 1        /* Must be CSM secured RAM */
						RUN_START(secRamRunStart),
						LOAD_START(secRamLoadStart),
						LOAD_SIZE(secRamLoadSize)

	IQmathTables	:	> FLASHE | FLASHF | FLASHG | FLASHH | FLASHI |
    					  FLASHJ | FLASHK | FLASHL | FLASHM | FLASHN	PAGE = 0

	.BootParameter	: > BOOT_PARAMETER, PAGE 1 /* begining of RAMGS0 */
	.ImageHeader	: > IMAGE_HEADER, PAGE 0
}

I checked the cmd linker file and we have an entry 

BEGIN			: origin = 0x080000, length = 0x000002

in the memorymap.cmd file. So I would say this is correct so far. Do you agree?

Meanwhile, I'll take a look at the examples

Best, Robert

Robert,

Thanks for adding this additional code, in the above snippet I see this at line 16

codestart        : > FLASHE PAGE = 0

This will allocate codestart somewhere in FLASHE.

If you change this to

codestart        : > BEGIN PAGE = 0 and rebuild it will place code_start_branch correctly.

You may need to manually add this to your project, typically it gets pulled in automatically but just to be sure it is located here in C2000Ware example:

C:\ti\c2000\C2000Ware_5_00_00_00\device_support\f2837xs\common\source\F2837xS_CodeStartBranch.asm

Best,
Matthew

Thank you for your reply.

I double checked your cmd file with mine and I already have tried by replacing FLASHE with BEGIN. Still same issue and no entry in .map file.

In our firmware, we have The CodeStartBranch.asm file in our project.

I figured out, that you use ALIGN(8) in the .cmd file. I also tried this and even flashing did not work. ALIGN(4) let the MCU flash but still the issue with crashing at memcpy.

Also, there is a compiler flag --unused_section_elimination=off which is set to on by default in eabi mode. Might it be, that the CodeStartBranch.asm file is just removed in the map file since it is not required?

Best regards.

Robert,

Would you be able to attach the older COFF based .map file and the latest EABI build .map file?  I think that will help me track down what is missing, etc.  I'm a bit stumped as to why codestartbranch is not getting placed.

If you are able to attach both .cmd files as well that will help also.

If you have concerns posted on the public forum, I can set up a private share as well.

Best,

Matthew

Hi Matthew,

I sent you a private message with the requested files.

Meanwhile, I could manage to map the CodeStartBranch object into the memory. it was required to retain manually the object using --retain'_code_start' linker command. Nevertheless, I can not understand why it did not map it automatically since the codestartbranch object is obviously required.

I ran into another problem: the allocation of some code fails and later the program stops its execution again. This is the code snipped where it occurs: malloc always returns NULL and let the application reboot later. I have no idea what might cause this issue. Do I need to modify the SYS/BIOS config for the eabi format?

static inline void* sysBiosHelperMalloc(size_t size)
{
	// Handle heap-overflow
	// If the SYS/BIOS Config "Error Function" is defined, the SYS/BIOS will handle
	// then heap-overflow.

	void* p = malloc(size);
	//LOG_printf( &trace, "new(%u) at %x", (Uint16)(size), (Uint16)((long)p) );
	if (p == 0)
	{
		LOG_FATAL(eConfig_FunctionId, ErrorCode::eErrMemory, "OutOfMem");
		Task_sleep(1000);
		WatchDog::reboot();
	}
	return p;
}

Best regards

Robert

Robert,

If you right click on the project and select "properties" then navigate to C2000 linker ->Basic Options, this will bring up the below screen(ignore my heap size this was a non BIOS example).  Can you comment on both your stack and Heap size?  If you increase your heap, does it address the malloc issue?  Since you are using Bios, I wonder if this is related to the original issue as well.

If there is a separate variable for the BIOS heap(in the BIOS), please look at that as well.  I'm going to see if I can get a BIOS expert to look at all the above to see if there is some relation here to your issues.

Best,
Matthew

Hi Matthew,

thank you for your reply. I added a screenshot of the c2000 Linker. We have no heap size defined there, since we are using SYS/BIOS. As far as we now, the SYS/BIOS overwrites the heap size of the linker anyway.

Nevertheless, we increased the heap size from 9216 to 10496 in the .cfg file (BIOS.heapSize = 10496;) and it still did not allocate the memory. Although we saw an increase of taskStackSection in the .bss section. Why is the heap mapped in the taskStackSection? This does  not make sense at all, I expected a heap object.

I'm thinking about setting up a meeting using MS Teams, to continue on this issue, since we both invested some time on it.

Best regards,

Robert

Thanks Robert, I've asked a colleague to take a look at the post as well.  Will follow up with them today.

Matt

Hi Matt

Are there any updates? I'm still facing the same issue.

Best regards

Robert

Robert,

Can you reply back with the versions of the following

1. C2000Ware
2. SysBios
3. Code Composer Studio

Can you also attach you SysBios configuration file(.cfg) so we can look at those settings.

After re-reading the thread again, just wanted to comment on the code_start_branch.asm; the "retain" is what we were missing.  Since this is a automatically called function via placing its location address in the flash boot location in flash, there is no official "use" of this function and hence EABI optimizes it out. The retain can also be placed in the .asm itself.  I've attached from the latest C2000Ware, in case you want to swap your existing file for this.  There is also a provision to set the watchdog to "off" because EABI has a much longer initialization than COFF.

F2837xD_CodeStartBranch.asm

Best,

Matthew

Hi Matthew,

Thank you for reaching me out again.

Yes, I figured out, that the code_start section can be retained either by linker flag (--retain='_code_start') or by inserting .retain in the CodeStartBranch.asm file like you provided. I also want to mention, that our CodeStartBranch.asm file looks exactly the same like yours, but we used the --retain flag instead the .retain command. Furthermore, we used _code_start as branch instead code_start like you did. Of course, we disabled the Watchdog by setting WD_DISABLE to 1. There was another thread here which proposed this solution.

I'm confused now. you mentioned in a previous post, that the codestartbranch is missing in the map file and this is wrong. But now you say it is not really required in sight of eabi therefore it needs to be retained manually? If so, this information is missing in the migration guide provided by you, I suggest to add a note, that it is required to add .retain below the section in the file.

Here's our .cfg file:

TeMotion_II.cfg

Our versions:

Compiler/Linker version: V22.6.1

Code Composer Studio: V12.5

SYS/BIOS: V6.83.00.18

XDCTools: V3.61.02.27

We are using rts library rts2800_fpu32_eabi.lib.

I'm not quite sure, what you mean with c2000 ware, I tried to provide as much information as I could.

Best regards

Robert

Robert,

Let me clarify the code_start_branch.asm aspect, I think I was unclear with my last post:

This file/asm is 100% required to be placed for the boot aspect to work correctly.  The reason it was missing is due to how EABI is removing "unused" functions.  Since the function code_start_branch()  is never explicitly called by any other function EABI "thinks" it is  not necessary. 

What EABI doesn't know/understand is there is still a boot vector that is fetched during flash boot, and we place the address of code_start_branch in this location so it is needed.  Agree that this needs to be better documented in the migration guide.

Will look at the info you have sent on your tool versions and get back with you.

C2000Ware is our unified SW support product, that contains all base module .c and .h files along with examples, etc.  If we know this we can better understand what versions of those device files you are using to build your project.

This is by default installed in this path C:\ti\c2000\  you should see one folder(or many) that look like the below on your machine. 

Best,

Matthew

Matthew.

Ok, thats clear.

I have been using C2000Ware_4_30_00_00 for a while and recently I downloaded C2000Ware_5_00_00_00 to get recent examples with eabi format, as you mentioned in a previous post.

Best, Robert

Any updates on this?

Robert,

Have you tried to use this tool in CCS: ROV   This may be able to give some insight on what is breaking as we execute the code.

Best,

Matthew

Hi Matthew,

Yes I tried to use the ROV. However, our application does not even come into the main function and therefore, the ROV does not even start.
To compare I tried ROV with an example project with SYS/BIOS. This works, the application jumps to main and ROV starts.

Have you talked with your colleague?

Best regards

Robert

Hi Robert,

Has the project ever booted to NMI handler in CCS debug? Another thing to be sure of disable the watchdog timer flag project CMD file. 

Hi Genatco,

Thanks for reaching me out. I am not quite sure, if I understood correctly.

I set a breakpoint in the DefaultIsr_Bios.c file at line 50:

The Stop cmd was not reached, the application crashed before.

Also, if I understood you mean the watchdog flag in the CodeStartBranch.asm file? If so, I double checked it several times, because your colleague mentioned it. the watchdog has been disabled all the time by setting the flag to 1.

I hope this answers your questions.

Best, Robert

I want to share other results. 

I checked the RESC register and compared the results with our coff-format. Both format have the same values in the RESC register which means, the pin status bits and the WDRSn bit are all set.

What I also discovered is the enabled NMIE bit using our eabi format, which crashes:

If I compare it with our coff-format and a basic eabi-example with SYS/BIOS it looks like

Might this cause the issue? As I read in another post (https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1008481/tms320f280049-nmiwdrs-default-and-how-to-disable-if-boot-rom-makes-it-enabled)
it cannot be disabled. 

Robert

Robert,

I'm going to send you a private message on the E2E chat, let's see if a conference call or code sharing is the right path forward.

Best,

Matthew

Hi Robert,

Ok RESC shows WDRSn bit being set, watchdog timer is driving an NMI in ROM bootloader handler. Obviously we don't need to put a break point in the NMI_ISR handler, it pops up in debug when an unhandled NMI exception occurs. CCS debug may not be showing the next emulator step into STOP() though CPU obviously asserted HLT instruction. Curious if *.asm enables WD where NMI stops in the resume call stack, click top to bottom lines, looking backwards to find what functions executed.

Perhaps check #pragma sections, adjust optimizations speed settings for eabi build functions that you suspect could crash LSRAM higher speeds. Likely mcopy(.TI.ramfunc) sections causing crash.  

#pragma FUNCTION_OPTIONS (MyNewFunction, "--opt_level=1 --opt_for_speed=2")

Robert,

NMIE bit get set in BOOTROM itself. When you check the value of NMIE, where does the PC points to ? Look like the failure in both case are happening while executing the BOOTROM itself. Have you looked at NMISHDFLG register to see if there is any error getting triggered ? You can also check the BOOT STATUS at address 0x2 to see the boot flow.

Regards,

Vivek Singh

Vivek,

I took a short look at your idea. There is no error triggered at NMISHDFLG.
I agree with you, that it fails sometime in the BootRom

Best, Robert

Did you check the BOOTROM status also ? What is the value for that ?

Hei Vivek, thank you for your reply.

I checked it at the address 0x2 and it is always 0. I have never seen a change of the value at address 0x2.

I hope, that gives you some information.

Best, Robert

Robert and I are working on this off forum, will reply back once we have some progress so others can be aware of what we find.

Best,

Matthew