You are here

Internal compiler errors in Creator 3.0 | Cypress Semiconductor

Internal compiler errors in Creator 3.0

Summary: 6 Replies, Latest post by SpiderKenny on 18 Feb 2015 04:20 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
user_189995688's picture
138 posts

 Hi everyone


I've installed PSoC Creator 3.0 and I'm getting strange errors in my project.

This builds without any issues in Creator 2.2

At the 'API Generation' step I get these errors:

--------------- Build Started: 10/01/2013 10:46:26 Project: MMRA_4L, Configuration: ARM GCC 4.7.3 Debug ---------------

cydsfit.exe "-.appdatapath" "C:\Users\Kenny Millar\AppData\Local\Cypress Semiconductor\PSoC Creator\3.0" "-.fdsnotice" "-.fdswarpdepfile=warp_dependencies.txt" "-.fdselabdepfile=elab_dependencies.txt" "-.fdsbldfile=generated_files.txt" "-p" "C:\_Work\repo\trunk\Hamilton Audio\MMRA - 4L\MMRA_4L.cydsn\MMRA_4L.cyprj" "-d" "CY8C5868AXI-LP035" "-s" "C:\_Work\repo\trunk\Hamilton Audio\MMRA - 4L\MMRA_4L.cydsn\Generated_Source\PSoC5" "--" "-yv2" "-v3" "-ygs" "-q10" "-o2" "-.fftcfgtype=LE"

Elaborating Design...

HDL Generation ...

Synthesis ...

Place and Route ...

Tech mapping ...

ADD: pft.M0040: information: The following 1 pin(s) will be assigned a location by the fitter: \USBUART:Dp(0)\

Info: mpr.M0037: Unused pieces of the design have been optimized out. See the Tech mapping section of the report file for details. (App=cydsfit)

Analog Placement ...

Analog Routing ...

Analog Code Generation ...

Digital Placement ...

Digital Routing ...

Bitstream Generation ...

Static timing analysis ...

API Generation ...

Error: bse.M0202: Internal Error (aborting): Object reference not set to an instance of an object. (App=cydsfit)

Stack Trace:

   at CyDesigner.Common.ProjMgmt.Model.CyBootloaderData.GetFlashUsage(ICyDcDevice device, String elfFile, UInt32& flashUsage)

   at CyDesigner.Common.ProjMgmt.Model.CyBootloaderData.get_Size()

   at CyDesigner.PSoC.CyDsFit.GetBootloadableInfo(CyPrjMgmtProjectPSoCExe project, CyDSBootloadableInfo& bootloadableInfo)

   at CyDesigner.PSoC.CyDsFit.GenerateDatasheetInfo()

   at CyDesigner.PSoC.CyDsFit.InvokeAPIGen(CyElabInstBindContext bindContext)

   at CyDesigner.PSoC.CyDsFit.Run(TimeSpan loadTime, TimeSpan createTime)

   at CyDesigner.PSoC.Program.InternalRun(CyApp myApp, String[] args)Error: cdf.M0005: CyDsFit aborted due to errors, please address all errors and rerun CyDsFit. (App=cydsfit)


nsf's picture
Cypress Employee
8 posts

I'm one of the engineers on the PSoC Creator team. Would you be able to send us a copy of your project (e.g., directly via email, if not via the forum)? It'd really help find the root cause this problem.

user_189995688's picture
138 posts

 I'd love to, but I don't know your email address.

You should be able to see mine though. Please email me with the address to send the project to.

I cannot post it to the public forum.

nsf's picture
Cypress Employee
8 posts


SpiderKenny, thanks you for helping us get to the bottom of this. Here is a summary of what was discovered and a workaround for anyone else who experiences this problem.

Projects created in PSoC Creator 2.2 SP1 and earlier that use bootloaders AND are using a device that is no longer supported in PSoC Creator 3.0 are at risk of this crash when their "bootloadable" project is build in PSoC Creator 3.0.

When building a "bootloadable" project, the system examines the HEX/ELF files generated by the "bootloader" project. In PSoC Creator 3.0 we updated to a newer version of GCC which caused the build output directory to change (e.g., the GCC toolchain was updated from 4.4.1 to 4.7.3 which changed the build output directory from ARM_GCC_441 to ARM_GCC_473).

The bootloadable component in PSoC Creator designs points us at the HEX/ELF files via the Dependencies tab of its configuration dialog. The problem is the old build output directory from PSoC Creator 2.2 SP1 or earlier still exists and has valid HEX/ELF files, but they were build for a device that PSoC Creator no longer supports. PSoC Creator 3.0 doesn't properly catch this and prompt users to update their bootloadable component, and the our backend tools are incorrectly assuming that the device in the HEX/ELF files are still valid.

This error can be worked around by manually deleting the old output directories in Windows Explorer (e.g., ARM_GCC_441 if you were using the GCC toolchain in PSoC Creator 2.2) and then updating your bootloadable component to point at the new output directories (e.g., ARM_GCC_473 if you are using the GCC toolchain in PSoC Creator 3.0).

user_189995688's picture
138 posts

 I see this problem is back with 3.1

I have a project that I cannot open in Creator 3.1 with the same error as before.

I have tired removeing the old output directories, but it doesn't help.

user_78878863's picture
2553 posts

Do you use a Bootloader in your project? Did you rebuild the bootloader project with Creator 3.1?

user_189995688's picture
138 posts


Yes I use a bootloader, we have thousands of systems out there with these chips in, and can't imagine what life would be like without a bootloader!

I managed to work around the issue by re-importing our Creator 2.2 version of the poject. I have to maintain two versions because about 800 of our customers have PSoC5 (Not 5LP) and Creator 3.x does not support that chip anymore. (Mind boggling curse from Cypress, thank you).

Anyway, the point is, this is Cypress' best, top of the range development system for it's Flaghsip PSoC Products, and it can't handle simple upgrades without throwing a major curveball at the user. 

We are phasing out Cypres chips in out products now, we just can't move forward with amateur development systems and poor backward support for chips.

Log in to post new comments.