This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Code Composer v5.4.x versus v5.5.x

Other Parts Discussed in Thread: RM48L952, HALCOGEN, NOWECC, UNIFLASH

Hello,

Just today I have been flashing an application developed at my development workstation on CCSv5.4.x for the RM48L952 processor using our test bench laptop which runs CCSv5.5.x

For whatever reason, the MCU locks up and crashes if I rebuild the CCSv5.4.x developed build with CCSv5.5.x

I am now trying to download and install CCS5.5.x to my development workstation to try and reproduce the problem.

In the meantime, does anyone have any idea as to why the two 5.x versions would exhibit such a critical incompatibility?

Thanks

Jamie

  • I have now confirmed on my development workstation that v5.5.x causes the MCU to crash with a prefetch abort.

    From what I undertand, the differences between 5.4 to 5.5 may be changes to the ARM compiler and RML48952 is available in the configurations settings of the project.

    Can anyone advise on reasons why the versions are exhibiting incompatibility?

  • Sounds like a compiler difference. But it used to make a difference when

    1) Optimization is enabled or

    2) ECC is enabled.

    Did you enable that?

    What is your cgtools version in your CCS5.5 and CCS5.4?

    Regards,

    Haixiao

  • I have tried with both ECC enabled and disabled through HALcogen on the CCSv5.5 laptop but with no difference.

    On v5.4.x my CG_TOOL_ROOT setting is \ccsv5\tools\compiler\arm_5.0.4

    On v5.5.x my CG_TOOL_ROOT setting is \ccsv5\tools\compiler\arm_5.1.1

    I tried compiling in v5.4.x with arm_5.1.1 and it was successful.

    If I try with v5.5.x and arm_5.0.4 I get the failure.

    So, both versions of the compiler run OK when I use CCS v5.4.x but if I use either in CCSv5.5.x I get the failure.

    I am importing the 5.4.x project to a v5.5.x workspace. Perhaps the two minor versions of v5.x.x are simply not compatible?

    Jamie

  • Strange.

    Can your project run in a simple enviroment? like a HDK?

    If yes and it is not confidental, please upload the project, I can reproduce the problem and look for the root-cause.

    Regards,

    Haixiao

  • Hello,

    I have ran a quick test on the RM48HDK which also seems to exhibit the prefetch abort when I use CCS v5.5

    Our development is in a critical period just now so I will be sticking to v5.4.x for the foreseeable.

    I have attached the project with our application stripped out. It still fails per the above.

    note, our target hardware is a PGE package - hence why the HALcogen files will look like PGE and not ZWT.

    Thanks

    Jamie6557.CCSv5_Project.zip

  • I am sorry for the delay. It takes me two nights to have ccs5.5 installed. Here is my finding:

    1. You enabled Flash ECC.

    2. The code programed into the device does NOT have ECC. This is the reason why it aborted.

    3. After I append ECC to the .out, it runs well.

    Why did it run well in CCS5.4?

    Sounds like CCS5.4 automatically generates ECC and burn that into the Flash. However, we removed this feature in CCS5.5 (I don't know why).

    How to work with CCS5.5? This should be a easy question. But due to the mistakes we made, it becomes complex. Let me explain:

    1. Since the CCS5.5 no longer generates ECC for you, you have to generate by yourself. This is simple: download NOWECC and run: nowECC.exe -F021 16M_ADD -R4 -a UFA-24.out

    You can also stick this into the post-built in CCS

    2. After you append the ECC, you need to burn this image into the device. HOWEVER, sounds to me that CCS5.5 can not load such an image. It can not recognize the ECC portion and treat it as wrong memory region. So did the uniFlash. Since you have HDK, you should have nowFlash installed, right? nowFlash can burn such a image.

    Sorry for that,

    Haixiao

  • Hello Haiziao

    Interesting that CCS5.5 removed the automatic creation of the ECC.

    During development it sounds like there will more steps during debug to get the software on the chip in a runable state. I don't really want to be  switching between the IDE and NOWFLASH between each fix while debugging.

    I suppose I could swithc the Flash ECC off and remove it from the debug config to speed things up. I will try this in due course. For now to ensure we can move forward quickly we are sticking to CCS v5.4

  • Hello Jamie,

    If I remember correctly, the Flash Option to Automatically generate ECC during programming was changed to be disabled by default as of v5.5.  If you go into the Flash tools setting in CCS, you can verify the status of this setting and change it to AutoECC generation if that is your desire..

    Also, please make sure you upgrade through CCS to version 5.5.0.9 of the Hercules emulation package.

    As of v5.1 and newer of the CCS ARM compiler, you can also have ECC generated during link time though new extensions to the command linker file.  This obviates the need call nowECC as a post build process to add ECC to your out file.

  • Hello John,

    I will try those methods this week,

    When you say Halcogen emulation package what exactly do you refer to? Not the HALcogen tool itself which I think is at version 3.06.0?

    Jamie

  • Jamie,

    It is the Hercules, not HALCoGen.  The version for this can be found in CCS by going to Help -> About Code Composer Studio -> Installation Details.

  • Oh yeah...Monday morning brain fade!