• AVR Freaks

AnsweredHot!PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix

Author
willyvmm
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/12/12 12:59:49
  • Location: 0
  • Status: offline
2020/01/01 17:19:20 (permalink)
5 (1)

PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix

Hi.
 
Some of you probably know that tt's not possible to compile/build EZBL for PIC32MM_GPM series using XC32 never than 2.10.
It took me few days to analyse and track down the issue, I had to analyse a part ot the toolchain inlcluding java ezbl tools and pic32mm libs.
Finally i've found that the support is broken since xc32 v.2.15 ... really ...
 
the details:
Both DFP and libs contains kind of configuration file called "configuration.data" for every single chip flavor, describing SRF registers (or whatever it's called) used by #pragma directives.
fx:
Daytona Configuration Word Definitions: 0001
CWORD:BFC017C4:FFFFFFFF:FFFFFFFF
CSETTING:00000008:SOSCHP:Secondary Oscillator High Power Enable bit
[...]

 
the libs attached to xc32 v.2.10 are correct. But since v.2.15 something happened and  some of the registers got wrong address starting with 9FC01 instead of BFC01 !
Ofcourse there is no memory area/section defined ... so ...
 
the effect:
The compiler/linker has to be very creative, The compiled/linked code contains some sections called .config_9FC017xx with VMA != LMA. EZBL java tools (ezbl_tools.jar) is not able to process that kind of sections. Simply drops a null pointer exception.
 
the way:
I had to go the whole way back from the java tool to the source of this problem. Fortunate i was able to trace down this issue within few days using java debugger , grep , text editor, and some luck. The hardest part was to realize that the configuration files are doubled (xc32 and DFP) ...
 
the fix:
The fix i made is only for linux. I assume MPLABX, XC32, and DFP are the newest version and installed in default location. If not or windows user,  ... wait for official support or modify the code.
Simply run the two lines in shell. It will fix the config files.
I give no warranty for the code. You run it for your own responsibility, but is working well for me. Every changed file will have created a backup copy with .bak extension.
sudo find /opt/microchip/xc32/v2.30/pic32mx/lib/proc/32MM0*GPM*/configuration.data -print -exec sed -i.bak 's/9FC01/BFC01/g' {} \;
sudo find /opt/microchip/mplabx/v5.30/packs/Microchip/PIC32MM-GPM-0XX_DFP/1.1.26/xc32/32MM0*GPM*/configuration.data -print -exec sed -i.bak 's/9FC01/BFC01/g' {} \;

 
the final:
With the simple fix i was able to build EZBL with XC32 v.2.30 for pic32mm0064gpm028 :D
I hope you will enjoy this :)
 
the microchip:
@Microchip
  • Could you please confirm the issue, and the way i have fixed it?
  • If the above is correct, could you please release a official fix?
 
Thank you.
post edited by willyvmm - 2020/01/01 17:26:34
#1
ric
Super Member
  • Total Posts : 25592
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix 2020/01/01 18:15:02 (permalink)
+1 (1)
This sounds like some good detective work :)
willyvmm
@Microchip
  • Could you please confirm the issue, and the way i have fixed it?
  • If the above is correct, could you please release a official fix?
 

This forum is NOT an official channel to Microchip.
Most of the people here are just other users like you and me.
The only official way to notify them is via a Support Ticket at
http://support.microchip.com
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#2
JPortici
Super Member
  • Total Posts : 894
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix 2020/01/01 22:53:57 (permalink)
0
--
#3
willyvmm
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/12/12 12:59:49
  • Location: 0
  • Status: offline
Re: PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix 2020/01/02 02:05:16 (permalink)
0
Thanks @ric.
Support ticket created.
#4
HowardSchlunder
MCU16 Applications
  • Total Posts : 746
  • Reward points : 0
  • Joined: 2007/06/14 16:26:19
  • Location: Chandler, AZ
  • Status: offline
Re: PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix 2020/01/08 13:05:27 (permalink) ☼ Best Answerby willyvmm 2020/01/18 08:16:29
+3 (3)
Hello willyvmm,
 
I can confirm the issue you have described. XC32 v2.15 and newer place #pragma config word data for all PIC32MM targets in the cacheable kseg0 0x9FCxxxxx memory range instead of the uncached kseg1 0xBFCxxxxx memory range like it used to with XC32 v2.10 and prior toolchain releases. All PIC32MM devices, including the PIC32MM0064GPL036 Family and PIC32MM0256GPM064 Families, clock the flash memory 1:1 with the system execution clock, so a cache would provide no benefit and the hardware therefore does not implement any type of caching. Consequently, kseg1 and kseg0 virtual addresses are both physically uncached and equivalent to each other. The config word data could be placed at either address and the chip will behave exactly the same.
 
Unfortunately, the convention inside XC32 is to generate the corresponding config word sections with the address in the section name, and this is what breaks compatibility with EZBL v2.11. ezbl_tools.jar expects to find the config words in sections with names like ".config_BFC017C0", but XC32 v2.15+ #pragma configs are creating them named like ".config_9FC017C0". ezbl_tools.jar crashes with a null pointer exception as a result.
 
To resolve this compatibility issue, replace the [boot_project_name]/ezbl_integration/ezbl_pic32mm.ld linker script with the attached one. This file maps config words with kseg1 or kseg0 names back to the 0xBFCxxxxx address range that ezbl_tools.jar expects. The modified linker directives look like this:
  /* Config Words */
  .config_BFC017C0 0xBFC017C0 : { KEEP(*(.config_?FC017C0)) } > configsfrs
  .config_BFC017C4 0xBFC017C4 : { KEEP(*(.config_?FC017C4)) } > configsfrs
  .config_BFC017C8 0xBFC017C8 : { KEEP(*(.config_?FC017C8)) } > configsfrs
  .config_BFC017CC 0xBFC017CC : { KEEP(*(.config_?FC017CC)) } > configsfrs
  .config_BFC017D0 0xBFC017D0 : { KEEP(*(.config_?FC017D0)) } > configsfrs
  .config_BFC017D4 0xBFC017D4 : { KEEP(*(.config_?FC017D4)) } > configsfrs
  .config_BFC017D8 0xBFC017D8 : { KEEP(*(.config_?FC017D8)) } > configsfrs
  .config_BFC017DC 0xBFC017DC : { KEEP(*(.config_?FC017DC)) } > configsfrs
  .config_BFC017E0 0xBFC017E0 : { KEEP(*(.config_?FC017E0)) } > configsfrs
  .config_BFC017E4 0xBFC017E4 : { KEEP(*(.config_?FC017E4)) } > configsfrs

The question marks are wildcard characters, so this linker script is compatible with both XC32 v2.10- and XC32 v2.15+.
 
When building the Bootloader project, ezbl_tools.jar will generate the [boot_project_name].merge.ld linker script for the Application project using ezbl_pic32mm.ld as a template. Therefore, the Application's linker script will automatically inherit this same update and doesn't require any manual changes.
 
Modifying processor configuration.data files, while probably a workable technical solution and deserving of kudos for impressive investigative/problem solving effort, is not recommended. Such a change would only work on your machine, not others such as colleagues or successors that might have to one day maintain or start from your same Bootloader project source tree. Additionally, your own machine would need re-patching each time a new XC32 release or DFP is used. 
 
In the next release of EZBL (post v2.11), this identical linker script change will be implemented in the distribution. A release date for this is not currently known.
 
 
Howard Schlunder
Microchip Technology, Inc.

Attachment(s)

Attachments are not available: Download requirements not met
#5
willyvmm
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/12/12 12:59:49
  • Location: 0
  • Status: offline
Re: PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix 2020/01/18 08:16:04 (permalink)
0
Thank you for explanation :)
The corrected linker file seems to be working fine. I'm new in PIC32 so i didn't knew about the kseg0 and kseg1 differences.
I absolutely agree that using of hacked tools may be unpredictable. So it's why i've asked You for official patch/solution.
 
Anyway, Thank you very much for the official solution.
 
Best
willy.
#6
NKurzman
A Guy on the Net
  • Total Posts : 18266
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: offline
Re: PIC32MM0xxxGPMxxx support broken in XC32 and DFP - not possible to compile EZBL + fix 2020/01/18 10:38:47 (permalink)
0
Each memory location has 3 addresses.
Physical
Cachable
Non cachable.

The correct address is dependent on how it will be used.
#7
Jump to:
© 2020 APG vNext Commercial Version 4.5