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.

halcogen bug

Other Parts Discussed in Thread: HALCOGEN

Hello! In Halcogen usage time for generation of a code the following mistake was found. At code addition with comments in area prisoners in
/* USER CODE BEGIN */
 a = 10; // для примера

b = a;
/* USER CODE END */
, comprising the Cyrillic sign "я" (0xFF) code deleting ( b=a; ) in this area causes everything that follows after that sign "я" (0xFF). How to avoid similar behavior of Halcogen?

  • Hello Sergey,

    It seems from your description and example, that HalCoGen is generating the stubbed function with the comments of where to add your application specific code. In doing so, you add a comment in a non-ASCII format which, in turn causes the next line to be skipped at compile time. Is this a correct assessment? If so, can you provide details of which compiler and tools you are using to build your application code?

    One possible reason for this could be the line is not compiled due to code optimization if the variable 'b' is not subsequently used in your application code. Have you tried declaring 'b' as static to prevent it from being optimized away? If you have tried to compile by alternating use of the Cyrillic character and have seen variation in the compile, perhaps this is not the issue, but might be worth looking into.

  • Hello Sergey,

    After some additional testing, the problem was reproduced and there is, in fact, some issue with HalcoGen and the Cyrillic character that is truncating the clock of code for some reason. To work to resolve the issue in a subsequent build of HalCoGen, I have assigned this thread to out HalCoGen software development leader so that he can address the issue.

  • Sergey,

    I did check your problem and there is nothing wrong with the character you are using.

    The problem is the syntax for the USER CODE BEGIN is missing the number.

    /* USER CODE BEGIN (2) */
     a = 10; // для примера b = a;
    /* USER CODE END */

    Also, it is not possible to add more of these section than the one generated by HalcoGen.

    In the SYS_MAIN.c file, you have 5 section name 0 to 4. You have to use them to insert your application code.

    Regards,

    Jean-Marc

  • Jean-Marc Mifsud said:

    I did check your problem and there is nothing wrong with the character you are using.

    The problem is the syntax for the USER CODE BEGIN is missing the number.

    /* USER CODE BEGIN (2) */
     a = 10; // для примера b = a;
    /* USER CODE END */

    Also, it is not possible to add more of these section than the one generated by HalcoGen.

    In the SYS_MAIN.c file, you have 5 section name 0 to 4. You have to use them to insert your application code.

    Jean-Marc,

    the example which I put - conditional, this problem is watched just when adding code in section generated halogen:


    /* USER CODE BEGIN (2) */
     char a, b;
     a = 10;     // для примера
     b = a;      // комментарии
    /* USER CODE END */


    You can repeat it in any project having inserted into any section "USER CODE" any comment containing character "я" (code 0xFF). Thus in case of the next generation of halcogen the code following this character will be remote.

    Excuse for my imperfect English.

    Regards,

    Sergey

  • Sergey,

    I was able to reproduce this problem.

    Also when Halcogen is used to re-generate the code, all your comments are replaced by ?????

    Our software team is looking at this problem and will evaluate a possible fix.
    The work around for now is not to use Cyrillic characters in your comments.

     Regards,

    Jean-Marc

  • Hi Sergey,

    The current version of HalCoGen recognizes only ASCII character set , it is unable to recognize the Cyrillic characters and hence it re-generates the file ignoring the User code.

    There is no plan to add Unicode support to HalCogen till the end of 2012. The work around for now is not to use Cyrillic characters or Unicode format.

    Regards,

    Siddharth