LP-XDS110: file load failed while debugging

Hi,

  - Can you repeat the same issue on another board?

  - I have sometimes seen this error but normally after a power cycle or reset, the error will go away after the second try.

  - Is your error permanent?

  - Before you see this error, for how long have you been using the chip succesfully?

  - Is the chip very hot when the error happens?

  - Can you unlock the device? See section 5.3.2 of this app note using dbgjtag.exe. https://www.ti.com/lit/pdf/spma075. You would use the below command.

   “dbgjtag.exe –f @xds110 –Y unlock,mode=tiva”

Can you repeat the same issue on another board?

YES

I have sometimes seen this error but normally after a power cycle or reset, the error will go away after the second try.

NO, It came all time

 Is your error permanent?

YES

 Before you see this error, for how long have you been using the chip succesfully?

All time successfully working

 Is the chip very hot when the error happens?

Chip was not HOT.

Note:

Actually i am working for boot loader sequence in my project. Initially i will set my address range in my firmware in the version 1.5.

First time it was debug successfully. If i modify another firmware(version 1.7)  with same address range it was not debugging. It shows the following error.

CORTEX_M4_0: GEL Output:
Memory Map Initialization Complete
CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00007F80 do not match Please verify target memory and memory map.
CORTEX_M4_0: GEL: File: D:\ACP Workspace\version 1.13\LAW_Master\Debug\LAW_Master.out: a data verification error occurred, file load failed.

My question is

1. Firstly i set the address range in 1.5 version it was successfully debugging

2. and i modified 1.7 version firmware with same address range it as not debugging.

My Requirement is

1. How to avoid the following error

CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00007F80 do not match Please verify target memory and memory map.

2. How to disable the option of comparing address like as above error?

And please suggest me i dont want to compare the address,i need to disable the comparing address like  Values at address 0x00007F80 do not match .   I want to debug the 1.7 version with the same address range.

So please guide me for resolving this error .

Thanks in advance.

Tom M said:

1. Firstly i set the address range in 1.5 version it was successfully debugging

2. and i modified 1.7 version firmware with same address range it as not debugging.

What is the difference 1.5 and 1.7? Is the .cmd file the same between the two?

Can you repeat the same issue on another of your custom board?

Can you repeat the same issue on a LaunchPad?

What is the difference 1.5 and 1.7? Is the .cmd file the same between the two?

I made some changes in firmware not in boot sequence. The modification done in other sequence like stepper,BLDC motor sequence.

Note:Actually it  is a complete motor firmware.I made some changes in motor sequences only not boot loader sequence.

Can you repeat the same issue on another of your custom board?

Yes, I tried some other boards but i can't able to debug.

Can you repeat the same issue on a LaunchPad?

YES

Tom M said:

I made some changes in firmware not in boot sequence.

Are you using a bootloader? What do you mean by boot sequence?

Can you show your .cmd file?

Can you look at the .map file and compare between the working and the not-working version. The map file should provide some clues. 

Are you using a bootloader? What do you mean by boot sequence?

This is the boot  loader logic

if((address==0xff))
{

UARTIntEnable(UART3_BASE, UART_INT_RX | UART_INT_RT);// UART 3 only enable the boot loader purpose
boot_loading();// disable all interrupts except UART 3
}

Can you look at the .map file and compare between the working and the not-working version. The map file should provide some clues.

First i debug the 1.5 version.It was debug successfully.

Next i try to debug 1.7 version its not debugging.

Then i check and verify the uniflash software. It shows the following error. 

I open the memory ma in uniflash the memory mismatched from  0x00004000 this address.

Please suggest me how could i resolve this issue. I try to convey  my issue,if you need more information please let me know.

Thanks a lot for your supporting. Keep support us.

Where are the .cmd files for both the 1.5 and 1.7 versions?

Did you look at the .map files and what is the difference?

You keep saying it is not working on debug mode? Does it work on run mode (without the debugger connected?)

Where the screenshot for the memory starting at 0x4000 for the working version?

If 0x4000 is where your application will reside then you should have the vector table at 0x4000? Your screenshot does not seem to have the correct vector table.

Thanks for your time.,

Where are the .cmd files for both the 1.5 and 1.7 versions?

This is the difference between 1.5 and 1.7 .cmd files.

Did you look at the .map files and what is the difference?

Its also had some differences comparing both files.

You keep saying it is not working on debug mode? Does it work on run mode (without the debugger connected?)

Without debugger it was build successfully. But not debugging.

Where the screenshot for the memory starting at 0x4000 for the working version?

This is the screen shot  for the memory starting at 0x4000 for the working version .

Please guide me  how could i find the mistake in this stage.

Which one this the working cmd file?

Please expect delayed response until Wednesday as I'm currently out of office on travel. 

Thanks for the reply.,

Please expect delayed response until Wednesday as I'm currently out of office on travel. 

Its okay No issue.

Which one this the working cmd file?

Thanks for this question. Let me explain..

Actually in the cmd of v1.5 is  

--retain=g_pfnVectors

MEMORY
{
FLASH (RX) : origin = 0x00000000, length = 0x00080000
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

My issue is, i could not talk about version 1.7. In the same version V1.5, first of all i changed the address range,

After i changed this address first time it was debugging, no issues. Once i stop the debugger the second time it was not debugging, in the same version V1.5(Not V1.7).

I need the solution why it was not debugging the 2nd time(the same version). It  shows the below popup.

Hope  you understand my issue. If you need any information please let me know.And thank you for your prompt response.

Thanks for your valuable response.And i will try, C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_serial and an example application that go along with the bootloader at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo1.

Why is your bootloader starting at 0x7F000 and not 0x0?

The maximum code size of Bootloader is 4K Bytes. The RAM size need by CBL is 128K Bytes for receiving the new flash code that would be received from GUI and also for the internal variables

Flash Block Size: 0x4000 (16Kb). Minimum size that can be erased or programmed

Custom Boot Loader should be loaded into the designated address 0x7F000

This is the reason of using 0x7F000.

Is this any wrong in tm4c1294kcpdt.cmd file? Please suggest me.

Thank You

Hi,

Tom M said:

The maximum code size of Bootloader is 4K Bytes.

Your bootloader may only occupy 4k but a flash page is 16K. A flash is erased page by page. Your bootloader occupies the same page as the application from 0x7C000 to 0x7FFFF. If the bootloader sends a command to erase your application, it will erase the entire page from 0x7C000 to 0x7FFFF including the bootloader itself. 

The TivaWare bootloader starts at 0x0. After reset, the processor runs from 0x0 where bootloader resides. The bootloader determines if there is a valid application. For example, the application may reside at 0x4000.  If there is a valid application at 0x4000, the bootloader will jump to it and run the application. If there is not an application or if the bootloader is instructed to update the firmware based on an pin input, the bootloader will use the chosen interface like UART, SPI or others to load the application firmware. Once the application is running, it can jump back to the bootloader if it needs to update the application again.  This is basically how a bootloader works. I don't know why you must have the bootloader at the end of the flash rather than at the beginning of the flash. It is up to you but it is a custom bootloader you need to create rather than referencing a bootloader example that is already available. If you choose to use your own custom bootloader, you must have the bootloader occupy the last 16kB, not just 4kB. You must instruct your custom bootloader not to erase the last 16kB flash page so the bootloader is not erased. 

Hi.,

Thank you

I tried Custom Boot load from 4kbytes to 16kbytes.I did the following changes

I changed tm4c1294kcpdt.cmd  file.

i changed address too for 16kbytes.

But this time i faced different error like, When i changed any modification this time the verification failed dialog box not open. This time the debugger goes to fault ISR.

Then i open debugger window click the XDS110 Debug (Running).Then I press the Pause button it goes to Fault ISR Mode.

I did step  by step process what you said in the above reply. It goes to Fault ISR  mode.

Please suggest me what can i do from this stage.

Thank yo very much for your huge support.

Hi.,

Thank you

I tried Custom Boot load from 4kbytes to 16kbytes.I did the following changes

I changed tm4c1294kcpdt.cmd  file.

i changed address too for 16kbytes.

But this time i faced different error like, When i changed any modification this time the verification failed dialog box not open. This time the debugger goes to fault ISR.

Then i open debugger window click the XDS110 Debug (Running).Then I press the Pause button it goes to Fault ISR Mode.

I did step  by step process what you said in the above reply. It goes to Fault ISR  mode.

Please suggest me what can i do from this stage.

Thank yo very much for your huge support.

Tom M said:

I tried Custom Boot load from 4kbytes to 16kbytes.I did the following changes

Your FLASH_BOOTLOADER starts at 0x7F000 and the length is 0x4000 (16k). The length should be 0x1000 (4k). Is there a strong reason why you cannot use the TivaWare bootloader as a reference? I strongly recommend you use the TivaWare bootloader or at least play with it to understand how it works and if you need to adapt to your requirement for a different starting bootloader address then you can do so. 

Okay Thank you .,

Please refer any example for setting memory address related to my query. I am confused to how choose memory address for my boot loader project. Plaese send me the link.

Thanks

I don't understand your question. As I mentioned before, the bootloader example is at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_serial and the example application that goes with it is at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo1. Have you tried the example yet?

Yeah i tried ,  But i faced some issue while running in that code

In that code the memory is

MEMORY
{
FLASH (RX) : origin = 0x00000000, length = 0x00010000
SRAM (RWX) : origin = 0x20000000, length = 0x00010000
}

1.  After i did any modification the debugger goes to fault ISR mode.Again i had debugging issue while trying this.

Hi,

  I know the reason fort the faults. The example is created for devices that support 1MB of flash and 256kB of SRAM. For the example application, the boot_demo1, you must change the length of the flash to 512kB for TM4C1294KNCPDT. As mentioned, I strongly suggest you first run the example as is on the LaunchPad which has the TM4C1294NCPDT processor supporting 1MB. Run on the LaunchPad first and there is nothing to modify. Once you get it working, you can adapt by changing the .cmd so you can run on your custom board with TM4C1294KNCPDT.

See below necessary changes in boo_demo1_ccs.cmd:

FROM:

/* The starting address of the application. Normally the interrupt vectors */
/* must be located at the beginning of the application. */
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000/* System memory map */

MEMORY
{
/* Application stored in and executes from internal flash */
FLASH (RX) : origin = APP_BASE, length = 0x000fc000
/* Application uses internal RAM for data */
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

TO:

/* The starting address of the application. Normally the interrupt vectors */
/* must be located at the beginning of the application. */
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000/* System memory map */

MEMORY
{
/* Application stored in and executes from internal flash */
FLASH (RX) : origin = APP_BASE, length = 0x0007c000
/* Application uses internal RAM for data */
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}