• AVR Freaks

Helpful ReplyXC16 v1.26 build failing -- (944) data conflict at address...

Author
awolfe
Starting Member
  • Total Posts : 80
  • Reward points : 0
  • Joined: 2009/08/20 09:52:07
  • Location: Ashland, OH
  • Status: offline
2016/03/08 13:46:17 (permalink)
0

XC16 v1.26 build failing -- (944) data conflict at address...

I updated to v1.26.  It worked for several compiles... but has now started giving me this error at the end of the compile.
 
"C:\Program Files (x86)\Microchip\xc16\v1.26\bin"\\xc16-bin2hex dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.elf -a  -omf=elf  
"Creating unified hex file"
nbproject/Makefile-XC16_24FJXXGA004.mk:445: recipe for target 'dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.hex' failed
make[2]: Leaving directory 'C:/occammd_drop/Software/DropSlave/DropSlave_Valve1/firmware/DROP_Valve1_R1.X'
nbproject/Makefile-XC16_24FJXXGA004.mk:78: recipe for target '.build-conf' failed
make[1]: Leaving directory 'C:/occammd_drop/Software/DropSlave/DropSlave_Valve1/firmware/DROP_Valve1_R1.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
(944) data conflict at address 8h between dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.hex and dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.hex
make[2]: *** [dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.hex] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
It is giving me this error on multiple projects (all using the same chip).  There are no errors higher up in the output.  I have no idea how to resolve this.  I have already tried uninstalling and reinstalling v1.26.  v1.25 builds the same projects without issue.  I am using "Clean and Build Project".  I have also tried clearing MPLAB X cache directory, just to try it, with no effect.
 
Any help would be appreciated.

A Wolfe
#1
dtruex
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2010/07/21 16:11:50
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/03/14 11:10:12 (permalink)
+1 (1)
Do you have anything in the loadable folder?  It looks like the project is trying to merge two instances of the same hex file for some reason.
 
(944) data conflict at address 8h between
dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.hex and dist/XC16_24FJXXGA004/production/DROP_Valve1_R1.X.production.hex
#2
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/03/16 12:04:24 (permalink)
0
I am having the exact same problem.  Just updated from 1.21 to 1.26.  I do have a loadable hex image (bootloader), but this was not a problem before and there should not be any overlap since we have remapped the IVT in the application.
#3
jjones11
New Member
  • Total Posts : 7
  • Reward points : 0
  • Joined: 2016/03/24 15:22:31
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/03/28 13:14:35 (permalink)
+2 (2)
I think I can contribute constructively to this problem.  I recently upgraded my tool chain to v1.26. I use MPLAB X v3.26, the ICD3 hockey-puck, and the dsPIC33FJ256MC710A PIC. All this stuff runs on my Win7-Pro 64-bit i7 PC.

I have analyzed and overcome this issue.  I was getting the same error 944 from the XC16 v1.26 Tool Chain.

For me, the issue is only present when I build for Release Mode, but Release Mode is needed to build the flash-image. Debug Mode does not experience this issue because of the way the debug image is built.

In Release Mode, we use a Bootloader and a Runtime image. Our Bootloader holds the ivt (interrupt vector table) and the aivt (alternate interrupt vector table). The ivt is used by the Bootloader, and the aivt is pre-loaded with vectors to a jump-table located at a fixed location within the Runtime. The Runtime is "fixed" in PIC-memory via a custom .gld linker-file. Accordingly, the Runtime does NOT have an ivt or aivt, and its start-code enables usage of the aivt when it initializes - so an interrupt bounces from the Bootloader's aivt to the Runtime fixed jump-table, and into the Runtime's interrupt-handler.

Both the Bootloader and the Runtime get their .hex files built separately and correctly, but in Release Mode, the Compiler Tool Chain also combines both hex-files into the "unified" hex file to create the MPLAB X Program file that the ICD3 hockey-puck uses to flash the full Bootloader+Runtime into the PIC's memory.

It all works great and lasts a long time! That is, until we switched to the XC16 v1.26 Tool Chain.

The XC16 v1.26 Tool Chain seems to force inclusion of an ivt into our Runtime hex file, even though:
  • A) We don't use or reference it. This used to be all that was needed.
  • B) I have added explicit "DISCARD" instructions in the Runtime's linker-script file to eliminate the .ivt Section, to no effect.
  • C) I have even clicked the "Remove unused sections" in the Properties for the Runtime's xc16-ld, also to no effect.
Since the ivt is inappropriately included in the Runtime hex file (you can see it in the Runtime's Map file), it clashes with the ivt in the Bootloader when the Tool Chain tries to put together the "unified" hex file, and we get error 944.

Unfortunately, the fix was to drop back to the v1.25 Tool Chain, and everything works fine again.
 
@awolfe - I agree with dtruex - you're unifying two copies of the same hex-file and you should get error 944.
@jmag99 - I think you likely have the same issue I described here.

Jeff
post edited by jjones11 - 2016/03/28 13:16:35
#4
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/03/31 05:52:15 (permalink)
0
I would agree that I have the same problem as you, but I think Microchip should fix this.  I will submit a support ticket referencing this thread.
#5
cawilkie
Administrator
  • Total Posts : 1977
  • Reward points : 0
  • Joined: 2003/11/07 12:49:11
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/04/18 14:28:39 (permalink)
+1 (1)
Prior to xc16 v1.25, one could prevent the ivt from being generated by omitting it from the linker script.
 
Now that it is no longer in the linker script, one can prevent the compiler from generating a vector table by using the linker option --no-isr.   This will prevent the linker from generating a default handler, and filling in the unused slots with that vector.   If there are used slots, then the linker will still generate a vector table.
 
The linker will also respect any vector table that is included in another way.  Ie, a vector table that is created in an object file:
 
.section .ivt, code, address(0x04)
.pword <some value>
; and so on
 
Will prevent the linker from creating a vector table.   Adding "noload" will also prevent the linker from generating a vector table, and will also cause the generated table to be ignored by programmers and the xc16-bin2hex.
 
For example, this will prevent the linker script from generating a .ivt on a dsPIC30F6014
 
.section .myivt, code, address(0x04), noload
.space 0x78 ; length of the .ivt section
 
Doing this will create a ivt section which is explicitly marked "NEVER_LOAD" and create a new-form group of vector slots which are not marked "LOAD".  Therefore neither region will be loaded by a programmer.
 
If this is not what this thread is looking for, then please submit an example so that we can ensure we properly support these legacy projects.
 
Regards
Calum
#6
cktcon
New Member
  • Total Posts : 5
  • Reward points : 0
  • Joined: 2011/01/24 12:29:31
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/05/20 11:38:14 (permalink) ☄ Helpfulby awolfe 2016/06/09 09:12:23
+1 (1)
I found this thread to be useful in debugging an ivt issue with a legacy project that built fine with an XC16 compiler suite previous to v1.26, but did not build with the updated suite.  I am hoping this post will help others who have had this issue with v1.26.  This is rather lengthy, so skip to the bottom to see the solution if you wish.
 
We are using a PIC24E series processor (PIC24EP256MC206), and working with code that utilizes a bootloader and application firmware solution.  Since the PIC24E does not have an alternate ivt, and both the bootloader and application code utilize interrupts, the interrupts have to be re-routed to the application when it is running.  This is done by filling the ivt with the address of the re-routing code found in the bootloader.  As an example, the code to route the T1 interrupt is located in an assembly file, and looked like this:
__T1InterruptRerouter:
    btsc RCON,#9;              ;** RCON.CM is bit 9 is used to select between boot/app int
    goto __T1Interrupt;        ;** bootrom interrupt
    goto 0x4114;               ;** location of application interrupt
The __T1InterruptRerouter label (along with the other re-routing functions) went into the linker (.gld) file in the .ivt __IVT_BASE section like this:
    LONG( ABSOLUTE(__T1InterruptRerouter));     /* IRQ 3 */

The project was built with the linker option "Create default ISR".  The bootloader built fine, however, when I went to merge the bootloader hex file with the application hex file (the app had the ivt table stripped out), I got this error from the srec_cat utility:
srec_cat: SC020-Boot_v00.01.02.hex: 6: contradictory 0x00000008 value (previous = 0x36, this one = 0xE0)
 
Looking at the hex file, I saw the issue, there were two lines that allocated values to address 8:
:020000040000fa
:040008003612b400f8
and
:10000800e0020000e0020000e0020000e002000060
As proof, when I selected the Project->Properties->Building->Normalize hex file option, I got the output error noted in the original post above:
(944) data conflict at address 8h between dist/default/production/Boot.X.production.hex and dist/default/production/Boot.X.production.hex
 
So, the linker was inserting this garbage vector for T1 into the hex file as well as my valid T1 vector.  Looking at the hex file more carefully, all other vectors had this same value overwriting them (when I looked at the binary of the vector table, all vectors had 36 12 B4 in them).
I defined my own __DefaultInterrupt routine, and unchecked the option Project->Properties->xc16-ld->General->Create default ISR.
This worked to get rid of all but three of these garbage vectors, T1, U1TX, and U1RX, the three interrupts being used in the bootloader.
Here is what I found, by using the default interrupt names for these three interrupt handlers, _T1Interrupt, _U1RXInterrupt, and _U1TXInterrupt, but not installing them into the ivt, three random garbage vectors were created in the hex file anyway, each causing a conflict with the existing correct vectors (not the corresponding T1, U1RX, and U1TX vectors either, but different vectors) .  When I replaced the interrupt function names with non-default names, _T1Int, _U1RXInt, and _U1TXInt, the garbage vectors went away and the hex file was fine.  Apparently, the linker really really wants to put the default names into the hex file, so it does (previously it wouldn't because the name wasn't included in the linker file).  So here's my solution:
  1. Create your own __DefaultInterrupt routine
  2. Uncheck the option Project->Properties->xc16-ld->General->Create default ISR
  3. Rename all default interrupt names, for example instead of _T1Interrupt, _T1Int, and refer to that name instead.
  4. Check the option Project->Properties->xc16-gcc->Preprocessing and messages->Disable ISR warn
  5. Check Project->Properties->Building->Normalize hex to have the build check for overlapping memory space, or uncheck to generate the hex file and look at it yourself.
So bottom line, if a default interrupt name is installed in your program, it will get installed into the hex file regardless of whether you want it there or not, even if there is already a vector there.  If there is a vector already there, a "garbage" vector is generated and may (if it is inserted in the hex file after the valid vector) override the correct vector.
 
As an additional note, I found that (as expected) identical code could be generated by implementing an explicit ivt (using .section .ivt, code, address(0x04) in an assembly file as noted above) or by using the linker file to remap the vectors.  Using the explicit table did NOT fix the garbage vector issue unless I followed the steps outlined above.
I hope this helps someone, it was a devil of a problem...
#7
awolfe
Starting Member
  • Total Posts : 80
  • Reward points : 0
  • Joined: 2009/08/20 09:52:07
  • Location: Ashland, OH
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2016/06/09 09:12:00 (permalink)
0
I do have a bootloader in my Loadables.
 
@cktcon - Your finding a solution is quite impressive.  Great post!
 
For now I've stuck to v1.25.  Hoping that it will just be fixed in v1.27 since @jmag99 indicated he was going to submit it.  Otherwise, I may revisit this topic later.

A Wolfe
#8
rgbyford
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2014/01/02 14:03:46
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/01/26 10:44:57 (permalink)
0
Thank you to the people who generated the solution to this!
 
As a by the way, the problem is still present in V1.30.
 
#9
jmag99
Super Member
  • Total Posts : 486
  • Reward points : 0
  • Joined: 2007/09/21 08:04:33
  • Location: RI, United States
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/01/26 10:56:31 (permalink)
+1 (1)
I was able to work around this issue in XC16 V1.30 by setting the output type to ELF and adding the --no-ivt flag to the linker.
#10
rgbyford
New Member
  • Total Posts : 23
  • Reward points : 0
  • Joined: 2014/01/02 14:03:46
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/01/26 12:11:45 (permalink)
+1 (1)
Agreed.  That seems to do the trick.  :-)
#11
Antecer
New Member
  • Total Posts : 4
  • Reward points : 0
  • Joined: 2016/01/09 08:30:35
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/04/02 05:59:37 (permalink)
0
error: (168) unknown option "--no-ivt"
 
why that?
#12
rodims
Super Member
  • Total Posts : 1515
  • Reward points : 0
  • Joined: 2009/02/10 11:08:59
  • Location: 51.9627, 7.6262
  • Status: online
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/04/02 06:08:00 (permalink)
+1 (1)
Because your XC16 does not yet support it ?
#13
Antecer
New Member
  • Total Posts : 4
  • Reward points : 0
  • Joined: 2016/01/09 08:30:35
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/04/02 06:14:07 (permalink)
0
rodims
Because your XC16 does not yet support it ?

I am use the XC8 v1.41 PRO
#14
rodims
Super Member
  • Total Posts : 1515
  • Reward points : 0
  • Joined: 2009/02/10 11:08:59
  • Location: 51.9627, 7.6262
  • Status: online
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/04/02 08:25:38 (permalink)
+1 (1)
Why do you post in XC16 forum  and append your question to an old thread ?
Still your compiler does not support it, that's what the message says.
 
#15
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/04/02 13:20:58 (permalink)
+1 (1)
Antecer
rodims
Because your XC16 does not yet support it ?

I am use the XC8 v1.41 PRO

As above, why are you trying to add that option to XC8?
No device supported by XC8 has an IVT, so why are you referencing it at all?
 
#16
binaryman
Super Member
  • Total Posts : 194
  • Reward points : 0
  • Joined: 2015/11/19 17:11:04
  • Location: Saint Louis, Missouri USA
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2017/04/12 17:24:22 (permalink)
+1 (1)
XC16 v v1.31 and v1.30
MPLAB-X v3.55
 
I have a boot loader for pic 24FJ64GA004 would not work because of verify errors causes by a bug in a compiler upgrade a year ago. The problem is because unwanted interrupt vectors are appearing in the hex file causing verify errors within the boot loader.  I came across this thread.  Suggesting a problem in the compiler and a possible work around.  I discovered that V 1.31 has a new check box featured
 
No Interrupt Vector Table ......[ X ]
 
When checked this fixed the problem. 
 
If you are working with a boot loader that has linker scripts make sure you follow the step shown in the attached picture.
  
Dan
St Louis, Missouri
 
 
 
 
 
post edited by binaryman - 2017/04/12 19:38:39

Attached Image(s)

#17
SinCitiesSin
Starting Member
  • Total Posts : 89
  • Reward points : 0
  • Joined: 2016/11/15 08:12:41
  • Location: 0
  • Status: offline
Re: XC16 v1.26 build failing -- (944) data conflict at address... 2018/04/12 09:23:25 (permalink)
0
dambrose
XC16 v v1.31 and v1.30
MPLAB-X v3.55
 
I have a boot loader for pic 24FJ64GA004 would not work because of verify errors causes by a bug in a compiler upgrade a year ago. The problem is because unwanted interrupt vectors are appearing in the hex file causing verify errors within the boot loader.  I came across this thread.  Suggesting a problem in the compiler and a possible work around.  I discovered that V 1.31 has a new check box featured
 
No Interrupt Vector Table ......[ X ]
 
When checked this fixed the problem. 
 
If you are working with a boot loader that has linker scripts make sure you follow the step shown in the attached picture.
  
Dan
St Louis, Missouri
 
 
 
 
 




What if this still does not work?
#18
Jump to:
© 2019 APG vNext Commercial Version 4.5