Tool chain for continuous integration

[IgVi_1394436]

Hello everyone,

Our company has been developing several products with PsoC 4 BLE. Until now we've always been using PsoC creator for developing prototypes and pilots firmware. Right now we've started mass production and we want to configure our PSoC 4 developments at bamboo server for continuous integration. So we've begun to develop our own scripts and makefiles to achieve the target based on gcc tool chain 4.9.3 integrated in PSoC Creator  4.0 Update 1 (4.0.0.432).

Unfortunately, we've found a problem we cannot find a proper solution. Basically, the final .hex files running the tool chain in continuous integration and running Creator are completely different. Following the thread we've tried to simplify as much as possible the problem and we notice that objects (.o) created during compilation stage from inside PSoc Creator and from command line are different, even using the same tool chain and compiler options.

Find attached both command line, one for PSoc creator and the other for cmd tool for continuous integration.  Find also the resulting objects as well as a resulting cmd output for cmd execution and finally a comparison snapshot of both final objects.

Let's comment that sometimes I have found some similar behaviour for other compilers and other uC's, usually regarding differences in compilation date, file path's, enviroment variables, etc. that were embedded in the object file content, and so the output became different. But in this case we don't find a connection between that and the completely different generated objects.

For us it does not matter if final firmware behaves the same or not, but it's required to get exactly the same output binary. In any other case we cannot trust the results and cannot go to continuous integration.

Can you help ?

Please don't hesitate to ask me for further information if required.

Thanks in advance,

Ignasi Villagrasa.

EGO Appliance Controls S.L.U.

SW Group Leader

[AnkitaS_51]

Hello Ignasi ,

Hex file created by PSoC Creator has extra data  as explained properly at these links:

https://www.cypress.com/file/409516/download  (page#08-09)

Flashing Cypress PSoC Creator output data files with J-Flash - SEGGER Wiki

[SOLVED] J-Flash Error: Program does not fit into selected flash sectors - J-Link/Flasher related - ...

[IgVi_1394436]

Thanks for answering at first.

I'm aware that hex files in Creator are adding extra information. But this is not the topic. Take into consideration that we're not even evaluating Hex file anymore. I'm talking about compilation stage only. This is the reason why I only send you .o files and command line calls regarding object generation. And the merge comparison is between equivalent object files. So the extra information Creator is adding after the linking stage is out of the scope.

The question would be:

What is Psoc Creator doing different during compilation stage for creating different object files (.o) ?

[ScottA_91]

Any reason why you're not using CyPrjMgr to just build it for you?

https://www.cypress.com/file/137441/download

Page 362

[IgVi_1394436]

Several reasons for not using it:

1) We're forced to unnecessary drag complete PSoc Creator Stuff in revision control system. Estimated 500MB necessary for command line integration.

2) We don't want to rebuild HDL Generation, as we consider it as a one step process, not linked to building chain. In fact, if something has to be changed regarding HDL generation, it should be made from inside Psoc Creator IDE. Then HDL Generation will also be run from there in a single step and it's not required the stage being included as a dependency in makefile. In other words, for us HDL generation is Hardware related, not Software at all.

3) Makefiles compatibility with other tool chains we're using with gcc.

4) Problems using CyPrjMgr in preliminary tests we don't know how to cope with. (See attached log)

Based on explained reasons, we believe the best way to proceed is to use a makefile as simple and compatible as possible using direct gcc commands, understanding that PSoc Creator is also using them as the tool chain, directly or indirectly.

From there we've tried to simplify the problem we find until we've arrived at the compilation stage and simple object files comparison.

So, our current concern is quite simple to explain:

Why do the same files compiled under the same tool chain and options output different if compiled from command line or from PSoc Creator ?

That's the question I'm pretty sure Cypress has an explanation for, as it's the manufacturer who controls PSoc Creator and knows exactly what the enviroment is internally doing.

[ScottA_91 · Accepted solution]

Well, everything PSoC Creator does should be in the output window, but if you want to verify that, you can always install procmon (Process Monitor - Windows Sysinternals | Microsoft Docs​) and follow the actual API calls.  (You'll need to set filters.)  That will tell you everything that's done including command lines and such.