• State Resolved
  • Locked Locked
  • Replies 45 replies
  • Subscribers 35 subscribers
  • Views 6042 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiling/flashing large array with TM4C129X

tinyspud
Intellectual 360 points
Other Parts Discussed in Thread: RM48L952, LMFLASHPROGRAMMER, SEGGER, TEST2

Hello

I'm trying to flash a huge array (280kB) to my TM4C129X (it's a font file) and I do array operations on it to parse the file and get its goodies and I've noticed that the array isn't loading properly into the chip's flash at least as far as the JTAG and program on board see it.  I've verified that this exact code works on my RM48L952 (big difference in processor, I know) but when I read the flash out from the TM4C it ends up misaligned.  The data at offset address 0x4454 in is 16B ahead of where it should be and by the time you get to the final address, offset 0x0003 95CF, the data stopped 0x190 before it should have.

I'm wondering if there's some difference in how the TM4C compiles large data arrays?  I converted both outputs to binary and compared them; the TM4C binary output at the end of the file is not what it should be and is in fact compressed 0x190 bytes  shorter than what it should be whereas the RM48's compiler made the array the exact bit for bit duplicate of what it should be.

Anyone have any ideas?

For reference:

RM48L952: Compiled with TI v5.1.14 on CCS 5.5

TM4C129: Compiled with TI v15.12.2.LTC on CCS 6.1.3

I realize that seems like a huge difference between the two compilers and environments, but the RM48 is kept on CCS5 for legacy reasons; compiling with the TI v5.2.5 leads to the same issue for the TM4C.  The source files are identical.

Chris

  • 0
    TI__Guru**** 244400 points
    Hello Chris,

    I have off late seen the TI compiler v15.12.2.LTC being mentioned, but never seen it in CCS environment. I have used compiler version 5.2.7 and have no problem loading a 380KB binary into flash.

    RM48 is a different class of processor (big endian) while TM4C is little endian. Did you check for endianess of the data. Also if you flash using LMFlashProgrammer does it work fine? Also not clear here is which board are you using?

    Regards
    Amit
  • 0
    Guru 10570 points
    First, probably just poor wording but, the TM4C doesn't compile anything. That's the task of your compiler. The output of the compiler will be specific to the ARM Cortex, but not particularly to the TM4C.

    To the actual question, we are missing some important details, how is the array declared? How is it initialized?

    Robert
  • 0 in reply to Amit Ashara
    Intellectual 360 points
    Hi Amit

    I don't know why but the 15.12.2.LTS (sorry for the typo)

    I believe the RM48 is little endian; at least that's what the setting is on my machine but that's besides the point; the software actually interprets the binary data inside of the array and it's big endian but I've already accomidated that in the code (it's set up as uint8_t and reads them as such)

    I compared the binary data as output using the:
    "${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd470.exe" "${CG_TOOL_ROOT}/bin/hex470.exe" "${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"

    which I assume is just a bit for bit accurate represenatation of what gets flashed onto the unit's flash and in there the data is also short of what it should be.

    I'm using the TM4C129X Development board (with the LCD and ethernet and USB and all that other goodness)
  • 0 in reply to Robert Adsett72
    Intellectual 360 points
    Hi Robert

    It's declared in the stupidest way I know how:

    const uint8_t SourceSansPro_Regular_const[OTF_SOURCESANSPRO_REGULAR_LEN] = { data data data }


    And in the header file:
    #define OTF_SOURCESANSPRO_REGULAR_LEN 234960
    extern const uint8_t SourceSansPro_Regular_const[OTF_SOURCESANSPRO_REGULAR_LEN];

    Chris
  • 0 in reply to tinyspud
    Intellectual 360 points
    Sorry, if you're wondering, yes, it is literally a 2MB source file with each byte defined as 0x00, etc. etc. etc.
    I've got comments all over the thing to make it easier for me to read and for my annotation of the actual parsing of the file but I'm assuming that isn't actually causing anything unless it's some weird quirk of the compiler.
  • 0 in reply to tinyspud
    Guru 10570 points
    Well, you could have run into a compiler issue but it's unlikely.

    That declaration shouldn't give you endian problems. So how do you know the array is ending early? Have you tried a smaller array?

    There are ways a nonconst declaration could give you an issue but that appears not to be your issue.

    Robert
  • 0 in reply to tinyspud
    TI__Guru**** 244400 points
    Hello Chris,

    1. Take a binary example for DK-TM4C129X and flash it to the board using LMFlashProgrammer. => Check if it works
    2. Then take the project corresponding for the example from TivaWare, recompile it in your CCS environment and then load it. => Check if it works

    Then use the #2 to embed your code to it and flash it to the board. This will help baseline the IDE and environment.

    Regards
    Amit
  • 0
    Guru 10570 points
    Misaligned? There's no alignment restrictions on uint8_t.

    Robert
  • 0 in reply to Robert Adsett72
    Intellectual 360 points
    Yeah that's what I'd figured. I don't know, it's weird that it just comes up short on the actual insides of the data array though.
  • 0 in reply to Amit Ashara
    Intellectual 360 points
    Hi Amit

    I just built/flashed the FreeRTOS demo - that worked fine, saw all the little bug things crawling around the screen.

    For my program, it is crashing at what I'm assuming is in the same point.

    From what I can infer, it looks like the connection is fine it's just that array's getting truncated or parts of it go missing and the end result is that the array is the right size just that its contents are somewhat shorter than they should be.
  • 0 in reply to tinyspud
    TI__Guru**** 244400 points
    Hello Chris,

    Is there a size limitation in the CCS version you are using? Dump the binary using LMFlashProgrammer and perform a binary compare of the original bin generated in the project and the dumped binary from the device.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 360 points
    Hi Amit

    I don't think I'm using a code space limited version of CCS or anything like that; I did a "upload flash contents to a .bin file" with LM Flash Programmer and compared it against the bin that should've been flashed to it and the only difference is at the end where the original .bin file ends the one with the chip read has all the 0xFF to the end of the memory space.

    After all of these tests I'm pretty convinced that my hardware's fine (espeically since I tried using my Segger JTAG and had the exact same error in the memory) - I'm thinking it's something with the compiler freaking out with the gigantic array (it is 234960 bytes long) and somehow missing a value every 600B or so (crude math, it's missing 400 bytes but the array is properly initialized to length 234960)
  • 0 in reply to tinyspud
    TI__Guru**** 244400 points
    Hello Chris

    Then your code has been flashed correctly. You may want to check with Segger if the compiler is suspected.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 360 points

    Hi Amit


    That was with the built in debugger

    Chris

  • 0 in reply to tinyspud
    Guru 27665 points
    So it appears to program correctly, I'll repeat the earlier questions

    So how do you know the array is ending early? Have you tried a smaller array?

    One additional test you can make. In your program dump the array bytes (via SWO or serial port) and compare to what they should be. Segger has a SWO terminal that would work to capture the output.

    Robert
  • 0 in reply to tinyspud
    TI__Guru**** 244400 points
    Hello Chris,

    You mentioned the "compiler" 2 posts up.

    Regards
    Amit
  • 0 in reply to Robert Adsett
    Intellectual 360 points

    Hi Robert

    I know it's not correct because when I go to an offset with data from the address, the contents at the offset aren't what they're supposed to be, the data I want that's supposed to be at the offset is earlier in the array. The data structure is indexed and I know it works when loaded into the flash properly.....

  • 0 in reply to Amit Ashara
    Intellectual 360 points
    Hi Amit

    By the compiler, I mean the Tiva compiler in CCS6.1.3
  • 0 in reply to tinyspud
    TI__Guru**** 244400 points
    Hello Chris

    Oops. OK, let us take the original project that you used to baseline the board and copy over the code files. Does it still not work?

    Regards
    Amit
  • 0 in reply to tinyspud
    Guru 27665 points

    tinyspud said:
    I know it's not correct because when I go to an offset with data from the address

    What address?

    How do you determine the address?

    How far into the array do you get before there is a mismatch?

    Robert

  • 0 in reply to Robert Adsett
    Intellectual 360 points

    Hi Robert

    First offset I look at (other than +1, +2, etc.) is +0x4454 in and it's already missing 0x10 bytes (16) from where it should be, that's to say, the data that I expect to be at offset 0x4454 is at 0x4444 even though in my copy of the array it's properly at offset 0x4454.

  • 0 in reply to tinyspud
    Intellectual 360 points
    So after extracting the binary files and going to the array location in the flash and comparing the outputs, it looks like the discrepencies start at offset 0x15B0; it skips 16 B, resumes, skips 16B at 0x96AF, resumes, skips more - I don't really want to do a byte by byte comparison, this is rather painful since I'm manually looking for the differences (it's not like I'm using a diff tool) but yeah, it looks like it skips what I can tell is randomly skipping 16B at a time, which is rather weird.
  • 0 in reply to tinyspud
    Guru 10570 points
    You need to approach this more rigorously, you're jumping all over the place and giving us incomplete descriptions of what you are doing. This does none of us any favours, especially yourself.

    I still recommend just dumping the array out the swo or a serial port. Skip all your regular processing and just check the array accuracy. Make it simple, use a regular pattern of values, say a simple increment with wraparound. Nothing you've presented so far makes me think there is a compiler issue.

    Robert
  • 0 in reply to Robert Adsett72
    Intellectual 360 points
    Hi Robert

    Sorry if I wasn't articulating it properly; the array accuracy has always been the thing that's been off and its inaccuracy is what's been messing with my program. I'm in the process of trying to just load the array directly with how I instantiate it as per Amit's suggestion and the main point of my previous response is that it just seems to be skipping bytes sporadically and not in any obvious pattern so far as I could tell (say if it was skipping a byte every 255 bytes or something like that).

    As far as reading the array out over the serial port is concerned, I'm not sure if that's going to tell me anything that my debugger isn't telling me since I'm just using the memory location reader to view that data, or do you still think that may be suspect? I'm entirely at a loss for what may be causing this issue though I agree it doesn't sound like it's not compiling the code improperly and I'm under the impression that my debugger works since I was able to load the FreeRTOS example to the chip via binary file output from my IDE. That being said, it seems like the array is being corrupted as it's being pieced together with everything else since the object's size is defined correctly in the .map file but its contents are not what they should be in both the binary dump (completed compiler output; .bin file) and when read from the JTAG.

    I don't know how to parse the .obj file that's output from the compiler but I suspect that the transition from the array as defined .c to the compiled parts that get linked together and create my .out and .bin files the array's contents are getting corrupted. Is there a way to do a consistency check on the raw contents of the array in the .obj file? The array is defined in its own file and it's the only thing in that file so I would assume (knowing nothing about the inner workings of the compiler) that I can read the array's raw contents and compare that to the array's value as it should be. I can't think of what would be causing this to happen since I have never seen this issue before and it worked before with another compiler and the reason why I haven't just used the old compiler is that there's something with assembly in the example FreeRTOS that isn't supported on the old compiler (in CCS 5.5).
  • 0 in reply to tinyspud
    Guru 27665 points

    tinyspud said:
    As far as reading the array out over the serial port is concerned, I'm not sure if that's going to tell me anything that my debugger isn't telling me since I'm just using the memory location reader to view that data, or do you still think that may be suspect?

    I think that is entirely suspect. It's entirely possible that you are chasing a ghost at this point.

    tinyspud said:

    I don't know how to parse the .obj file that's output from the compiler but I suspect that the transition from the array as defined .c to the compiled parts that get linked together and create my .out and .bin files the array's contents are getting corrupted. Is there a way to do a consistency check on the raw contents of the array in the .obj file?

    You're jumping way too far ahead. You haven't shown you have a real corruption issue as of yet.

    You appear to have focussed in on the first anomaly you've seen rather than systematically determining what's happening.

    Ignore your program, set it to one side and build things up towards where you are having the problem, as cb1 might put it KISS rules.

    Use a simple program of a few lines (enough to dump the array on command) and your array. Make the array a simple incrementing pattern so it's easy to see mismatches either graphically or preferably via a diff. Arrays of this size are easy to generate programmatically and that eases your task as well.

    Once you discover a problem you can use various techniques to start subdividing the problem. For example

    • If the simple pattern works try substituting your problematic array
    • If the simple pattern fails, try bisecting the array until there is not failure

    Robert

    Another essential tool for your use is a static analyzer like PC-Lint

  • 0
    Intellectual 360 points

    Just confirmed on my PC at home (exact same project, should've been the exact same compiler and using duplicate versions of CCS etc.) - code's fine, compiler's just really weird with files that large (guessing text files or something) which isn't really that surprising and I"m not 100% what the solution should be other than breaking it into a bunch of files and having the linker align them.  I duplicated the file and had it written twice into the flash in the .const section and it was included fine in one copy and in a byte for byte duplicate file the compiler made its binary different in the duplicate array. (Different object names obviously)

    Not really a solution but I think that's going to have to be the workaround for the time being....  Also, TI v15.12.3.LTS didn't help this problem; just received that update on Wednesday or so but it's still got this problem.

  • 0 in reply to tinyspud
    Guru 10570 points
    I strongly suspect you do not have a compiler issue

    Robert
  • 0 in reply to tinyspud
    Guru 92251 points

    tinyspud said:
    compiler's just really weird with files that large (guessing text files or something) which isn't really that surprising and I"m not 100% what the solution should be other than breaking it into a bunch of files and having the linker align them.

    Can you try running the armdis dis-assembler program in the TI ARM compiler on the .out file, using the --all option to dis-assemble all sections. That should give a hex view of the array in the executable and allow you to see if the problem is in the .out file or not.

  • 0 in reply to Chester Gillon
    Intellectual 360 points

    Hi Chester

    Thanks - did the comparison so it turns out that I was able to get it to compile correctly (verified by the binary via .out file) with the comments in the file stripped out.  Turns out the array's contents were getting confused probably by literally the thousands of comments the file so when it was parsing it to compile it and fill the array it was skipping lines (which explains why the pieces missing were 16B at a time) since my file was organized with each line with the comments describing the address location in them (like each line beginning with /* 0x00000010 */ then 16 bytes defined in hex then every 16th column pointing out 0, 1, 2, ..., F).  Modified my program that I ran the binary files through to create the arrays to not include the comments and looks like everything's working.

    Thanks everyone, learned some interesting new tools for the toolbelt.

  • 0 in reply to tinyspud
    Guru 92251 points

    tinyspud said:
    Turns out the array's contents were getting confused probably by literally the thousands of comments the file so when it was parsing it to compile it and fill the array it was skipping lines (which explains why the pieces missing were 16B at a time) since my file was organized with each line with the comments describing the address location in them (like each line beginning with /* 0x00000010 */ then 16 bytes defined in hex then every 16th column pointing out 0, 1, 2, ..., F).

    Are you able to post a version of the complete project with the array definition containing the comments and the resulting .out file?

    Given that you appear to have found a problem in the compiler parsing of large files, if I can repeat the problem then will report the problem in the TI C/C++ compiler forum.

  • 0 in reply to Chester Gillon
    Intellectual 360 points

    No problem; attached.  I think it's attached here...Let me know if this isn't working.  I'm using CCS 6.1.3.00033; think everything on here's up to date.flash_array_test_TM4C129X.zip

  • 0 in reply to tinyspud
    Guru 92251 points

    tinyspud said:
    I think it's attached here

    I see that there are two array definitions, OTF_SourceSansPro_Regular.c contains comments in the array and the OTF_arraytest.c contains no comments in the array.

    I used armdis to dis-assemble the OTF_SourceSansPro_Regular.obj and OTF_arraytest.obj object files and used BeyondCompare to compare the dis-assembled contents. As these object files only contain one large array the offset shown in the disassembly is the offset into the array. The first difference is at offset 0x15b0 in the arrays:

    I used Notepad++ to look in the OTF_SourceSansPro_Regular.c to view the array contents at offset 0x15b0:

    Note that the C syntax color highlighting in Notepad++ is showing the contents of line 437, which is supposed to be array data from offsets 0x15B0 to 0x15BF, as a comment since the hex values are shown in green. The previous line 437 ends with a '\' which is a line continuation character in C which means the contents of line 437 is considered as a continuation of the // comment at the end of line 436.

    Therefore, I believe the problem is how the auto-generated array file with comments is generated. If you change the generation to write a space at the end of each line, i.e. after the ASCII dump, then I think any trailing '\' in the character dump will no longer cause the next line to be parsed as a comment and thus avoid the issue where some of the array contents gets "commented out".

  • 0 in reply to Chester Gillon
    Intellectual 360 points
    Thanks - that's really bizzare because I used notepad++ to make all of those annotations so guess I never saw them though the original version that I'm working with doesn't have the leading whitespace (2 \t) that I included in the project (think it was out of habbit; I do Ctrl + I Ctrl + S by instinct) but yeah, I see it on my version too. I've already modified my program that generates the binaries to add \ to the not printable list of characters.
  • 0 in reply to Chester Gillon
    Guru 117855 points
    @Chester,

    Great job - much appreciated (3 valuable references w/in your post) - much thanks.
  • 0 in reply to tinyspud
    Guru 10570 points
    I was suspecting something like that.

    Two follow on notes

    Many compilers will warn when this occurs. I don't know if ccs is of high enough quality. Make sure you understand why your warnings occur
    Second, static analyzers such as PC-Lint definitely complain about this condition with clear messages. PC-Lint would have paid for itself just finding this for you

    Robert
  • 0 in reply to Robert Adsett72
    Guru 92251 points

    Robert Adsett72 said:
    Many compilers will warn when this occurs. I don't know if ccs is of high enough quality.

    Compiling the problematic OTF_SourceSansPro_Regular.c source fiile using TI ARM compiler v15.12.3.LTS I could only get a warning when MISRA-C:2004 checks were enabled:

    'Invoking: ARM Compiler'
"C:/ti_ccs6_1_3/ccsv6/tools/compiler/arm_15.12.3.LTS/bin/armcl" -mv7M4 --code_state=16 --float_support=FPv4SPD16 -me --include_path="C:/ti_ccs6_1_3/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:/Users/Mr_Halfword/workspace_v6_1_3/flash_array_test_TM4C129X" --check_misra="required,-1.1,-2.2,5,-6.1,-6.2,-6.4,-6.5,7,8,9,-10.1,-10.2,-10.3,-10.4,-10.5,-10.6,-16.9,-19.4" -g --gcc --define=ccs="ccs" --define=PART_TM4C129XNCZAD --issue_remarks --diag_wrap=on --diag_warning=225 --display_error_number --verbose_diagnostics --abi=eabi --preproc_with_compile --preproc_dependency="OTF_SourceSansPro_Regular.d"  "../OTF_SourceSansPro_Regular.c"
remark #24038-D: The '--abi' option is deprecated.  The only setting is eabi
   (elf).
"../OTF_SourceSansPro_Regular.c", line 15254: warning #1391-D: (MISRA-C:2004
          9.2/R) Braces shall be used to indicate and match the structure in
          the non-zero initialisation of arrays and structures
  		};
  		^

'Finished building: ../OTF_SourceSansPro_Regular.c'

    The MISRA-C:2004 9.2 warning detects that the SourceSansPro_Regular_const[] array has only been partially initialized (see https://sonarqube.com/coding_rules#rule_key=c%3AS835 for an explanation of this MISRA-C rule).

    Whereas the OTF_arraytest.c source file which doesn't have the comments doesn't trigger the MISRA-C:2004 9.2 as the array is fully initialized.

    Note that the warning is against the end of the array initialization at line 15254, and there is no warning against the first section which got "commented out" at line 437 due to the trailing '\' line continuation character.

    Also, I started by enabling all the "required" MISRA-C warnings, but got flooded with thousands of warnings and so disabled warnings to find the one of interest. This highlights that unless you write code to be MISRA-C compliant from the start, you can be flooded with warnings if you later enable the MISRA-C checks to try and find a problem.

    I am curious to know what PC-LINT would report.

  • 0 in reply to Chester Gillon
    Guru 92251 points

    Chester Gillon said:
    Note that the warning is against the end of the array initialization at line 15254, and there is no warning against the first section which got "commented out" at line 437 due to the trailing '\' line continuation character.

    The GNU v4.9.3 ARM compiler using -Wall reports clearer warnings against the actual lines where the unintended multi-line comments are:

    'Building file: ../OTF_SourceSansPro_Regular.c'
'Invoking: GNU Compiler'
"C:/ti_ccs6_1_3/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc.exe" -c -mcpu=cortex-m4 -march=armv7e-m -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DPART_TM4C129XNCZAD -I"C:/ti_ccs6_1_3/ccsv6/tools/compiler/gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/include" -ffunction-sections -fdata-sections -g -gdwarf-3 -gstrict-dwarf -Wall -MD -std=c99 -c -MMD -MP -MF"OTF_SourceSansPro_Regular.d" -MT"OTF_SourceSansPro_Regular.o" -o"OTF_SourceSansPro_Regular.o"  "../OTF_SourceSansPro_Regular.c"
../OTF_SourceSansPro_Regular.c:436:51: warning: multi-line comment [-Wcomment]
                           0x02, 0x1E, 0x02, 0x5C, // ÖT.......à.þ...\
                                                   ^
../OTF_SourceSansPro_Regular.c:2601:114: warning: multi-line comment [-Wcomment]
   /* 000096B0 */ 0x59, 0xDB, 0x13, 0xF4, 0xE5, 0x16, 0xF7, 0x4B, 0x06, 0xF7, 0x10, 0xE3, 0xBB, 0xF2, 0xD2, 0x5C, // YÛ.ôå.÷K.÷.ã»òÒ\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:3133:114: warning: multi-line comment [-Wcomment]
   /* 0000B6A0 */ 0x7B, 0x00, 0x12, 0x98, 0x00, 0x12, 0xB4, 0x00, 0x12, 0xD3, 0x00, 0x13, 0x2E, 0x00, 0x13, 0x5C, // {.....´..Ó.....\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:3895:114: warning: multi-line comment [-Wcomment]
   /* 0000E500 */ 0xD9, 0x65, 0x1D, 0x13, 0xFA, 0xD6, 0xF9, 0x65, 0x15, 0x51, 0x0A, 0x13, 0xD9, 0x4F, 0x65, 0x5C, // Ùe..úÖùe.Q..ÙOe\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:4892:114: warning: multi-line comment [-Wcomment]
   /* 00012220 */ 0xF7, 0x78, 0x1D, 0x13, 0xAB, 0x44, 0x4D, 0x6D, 0xAE, 0xAC, 0x86, 0x1F, 0x13, 0xAB, 0xA4, 0x5C, // ÷x..«DMm®¬...«¤\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:4939:114: warning: multi-line comment [-Wcomment]
   /* 00012500 */ 0x29, 0x0A, 0xF2, 0xCE, 0x24, 0xD8, 0x07, 0x8B, 0x1D, 0xF7, 0xBC, 0xF7, 0x29, 0x15, 0xFD, 0x5C, // ).òÎ$Ø...÷¼÷).ý\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:5237:114: warning: multi-line comment [-Wcomment]
   /* 00013740 */ 0x13, 0xBC, 0xFB, 0x38, 0x3E, 0x21, 0xFB, 0x09, 0x1E, 0x0E, 0xF7, 0xDC, 0xF7, 0x05, 0x0A, 0x5C, // .¼û8>!û...÷Ü÷..\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:5353:114: warning: multi-line comment [-Wcomment]
   /* 00013E60 */ 0xB1, 0x05, 0x73, 0x0A, 0xF7, 0x4A, 0x0A, 0x13, 0x77, 0x80, 0xF7, 0x02, 0xFC, 0x61, 0x15, 0x5C, // ±.s.÷J..w.÷.üa.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:5708:114: warning: multi-line comment [-Wcomment]
   /* 00015420 */ 0xDA, 0x15, 0x13, 0xF9, 0x80, 0x30, 0x1D, 0x32, 0xFD, 0x0E, 0x59, 0x0A, 0x13, 0xFA, 0x80, 0x5C, // Ú..ù.0.2ý.Y..ú.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:5996:114: warning: multi-line comment [-Wcomment]
   /* 000165C0 */ 0x8D, 0x44, 0xD2, 0x5A, 0x76, 0xF8, 0xF0, 0xD4, 0x12, 0xBF, 0xE1, 0xF7, 0x35, 0xD8, 0x13, 0x5C, // .DÒZvøðÔ.¿á÷5Ø.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:6492:114: warning: multi-line comment [-Wcomment]
   /* 00018420 */ 0x1D, 0xF9, 0x92, 0xF8, 0x33, 0x1D, 0xFB, 0x2C, 0x15, 0xF7, 0x46, 0xF9, 0xF0, 0xFB, 0x46, 0x5C, // .ù.ø3.û,.÷FùðûF\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:7263:114: warning: multi-line comment [-Wcomment]
   /* 0001B360 */ 0xD1, 0x06, 0x13, 0x7A, 0x94, 0xF7, 0x37, 0x05, 0xE7, 0x98, 0xCF, 0xC3, 0xE3, 0x1A, 0xCF, 0x5C, // Ñ..z.÷7.ç.ÏÃã.Ï\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:7400:114: warning: multi-line comment [-Wcomment]
   /* 0001BBC0 */ 0x72, 0x1D, 0x0E, 0xFB, 0x36, 0xF8, 0x90, 0xF7, 0xDB, 0x1D, 0xF7, 0xEE, 0x4E, 0x0A, 0xF7, 0x5C, // r..û6ø.÷Û.÷îN.÷\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:7577:114: warning: multi-line comment [-Wcomment]
   /* 0001C6A0 */ 0x7A, 0x7A, 0x8E, 0x75, 0x1B, 0x46, 0x6C, 0x5A, 0x48, 0x1F, 0x61, 0x07, 0x5E, 0x89, 0x05, 0x5C, // zz.u.FlZH.a.^..\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:8184:114: warning: multi-line comment [-Wcomment]
   /* 0001EBD0 */ 0xBA, 0x01, 0x72, 0xBD, 0x03, 0xEB, 0xFB, 0x45, 0x15, 0xBA, 0x44, 0xD3, 0x59, 0x43, 0x44, 0x5C, // º.r½.ëûE.ºDÓYCD\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:8545:114: warning: multi-line comment [-Wcomment]
   /* 00020010 */ 0x1D, 0x0B, 0xC5, 0x99, 0xC0, 0xA7, 0xD2, 0x1A, 0xC5, 0x58, 0xAA, 0x34, 0x8D, 0x1E, 0x82, 0x5C, // ..Å.À§Ò.ÅXª4...\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:8632:114: warning: multi-line comment [-Wcomment]
   /* 00020560 */ 0x93, 0x95, 0x8C, 0x91, 0x1B, 0xA8, 0xA2, 0x81, 0x42, 0xAD, 0x1F, 0xD0, 0xFB, 0x2F, 0xFB, 0x5C, // .....¨¢.B­.Ðû/û\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:9684:114: warning: multi-line comment [-Wcomment]
   /* 00024450 */ 0x30, 0x32, 0x0B, 0x4C, 0x73, 0x73, 0x30, 0x32, 0x0B, 0x54, 0x73, 0x73, 0x30, 0x32, 0x0B, 0x5C, // 02.Lss02.Tss02.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:9991:114: warning: multi-line comment [-Wcomment]
   /* 00025720 */ 0x07, 0x8D, 0x00, 0x19, 0x00, 0x34, 0x00, 0x3C, 0x00, 0x44, 0x00, 0x4C, 0x00, 0x54, 0x00, 0x5C, // .....4.<.D.L.T.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:10093:114: warning: multi-line comment [-Wcomment]
   /* 00025D60 */ 0x17, 0x68, 0x00, 0x01, 0x00, 0x00, 0x00, 0x31, 0x00, 0x03, 0x00, 0x00, 0x00, 0x01, 0x17, 0x5C, // .h.....1.......\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:10196:114: warning: multi-line comment [-Wcomment]
   /* 000263B0 */ 0x05, 0x55, 0x05, 0x56, 0x05, 0x57, 0x05, 0x58, 0x05, 0x5B, 0x05, 0x5E, 0x05, 0x5D, 0x05, 0x5C, // .U.V.W.X.[.^.].\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:10356:114: warning: multi-line comment [-Wcomment]
   /* 00026D80 */ 0x01, 0x30, 0x01, 0x36, 0x01, 0x3C, 0x01, 0x42, 0x01, 0x48, 0x01, 0x4E, 0x01, 0x54, 0x01, 0x5C, // .0.6.<.B.H.N.T.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:10684:114: warning: multi-line comment [-Wcomment]
   /* 00027F60 */ 0x01, 0x0E, 0x01, 0x98, 0x01, 0x26, 0x01, 0x9E, 0x01, 0x9E, 0x01, 0x5C, 0x01, 0xA4, 0x01, 0x5C, // .....&.....\.¤.\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:14986:114: warning: multi-line comment [-Wcomment]
   /* 00038560 */ 0xE9, 0xB2, 0xDF, 0xB2, 0xE9, 0xDD, 0x20, 0xC6, 0x71, 0x0F, 0xCD, 0x95, 0x74, 0xDC, 0xB6, 0x5C, // é²ß²éÝ Æq.Í.tܶ\
                                                                                                                  ^
../OTF_SourceSansPro_Regular.c:15042:114: warning: multi-line comment [-Wcomment]
   /* 000388D0 */ 0x37, 0x83, 0x0A, 0x30, 0xBA, 0xB5, 0x44, 0x98, 0xFD, 0xEF, 0xBD, 0xAA, 0x80, 0x35, 0xB1, 0x5C, // 7..0ºµD.ýｪ.5±\
                                                                                                                  ^
'Finished building: ../OTF_SourceSansPro_Regular.c'

  • 0 in reply to Chester Gillon
    Guru 10570 points
    I'll try to put something together

    Robert
  • 0 in reply to Chester Gillon
    Guru 11940 points

    Note that the C syntax color highlighting in Notepad++ is showing the contents of line 437, which is supposed to be array data from offsets 0x15B0 to 0x15BF, as a comment since the hex values are shown in green. The previous line 437 ends with a '\' which is a line continuation character in C which means the contents of line 437 is considered as a continuation of the // co

    While this might be an indicator, it is not really a proof. Those internal parsers are not the same as the compiler - every one more than superficially familiar with Eclipse knows this phenomenon. While the parser complains about errors, a build runs successful.

    Running a build (compile) with the "-E" flag and checking the output could help - albeit that might become tedious ...

    BTW, this forum software is having issues with such long lines as in this thread.

    Either the start or the end of the line(s) is shifted out of the visible range, but no horizontal scroll bar anywhere ...

  • 0 in reply to f. m.
    Guru 11940 points

    A follow-up, regarding "escaped newlines". Here an excerpt from a recent GCC manual, regarding GCC-specific extensions:

    6.21 Slightly Looser Rules for Escaped Newlines

    The preprocessor treatment of escaped newlines is more relaxed than that specified by
    the C90 standard, which requires the newline to immediately follow a backslash. GCC’s
    implementation allows whitespace in the form of spaces, horizontal and vertical tabs, and
    form feeds between the backslash and the subsequent newline. The preprocessor issues a
    warning, but treats it as a valid escaped newline and combines the two lines to form a single
    logical line. This works within comments and tokens, as well as between tokens. Comments
    are not treated as whitespace for the purposes of this relaxation, since they have not yet
    been replaced with spaces.

  • 0 in reply to Chester Gillon
    Guru 27665 points

    A simple example using Gimpel's public demonstration facility

    int test[9] = {
   12, 31, 43, // test comment with continuation \
   3, 4, 5, //
   7, 8, 9 };

int test2[9] = {
   12, 31, 43, // test comment with continuation \ 
   3, 4, 5, //
   7, 8, 9 };

    Note testt2 has a space after the continuation character (per f.m.'s notes)

    Output from the demo (The demo echos the source for clarity , the real version does not). Note this is done with the demo's defaults which are looser than I usually use.

    FlexeLint for C/C++ (Unix) Vers. 9.00L, Copyright Gimpel Software 1985-2014
    --- Module: diy.c (C)
         1  int test[9] = {
                                                             _
         2     12, 31, 43, // test comment with continuation \
    diy.c  2  Warning 427:  // comment terminates in \
         3     3, 4, 5, //
                       _
         4     7, 8, 9 };
    diy.c  4  Info 785:  Too few initializers for aggregate 'test' of type 'int [9]'
         5  
         6  int test2[9] = {
                                                             _
         7     12, 31, 43, // test comment with continuation \ 
    diy.c  7  Warning 434:  White space ignored between back-slash and new-line
    diy.c  7  Warning 427:  // comment terminates in \
         8     3, 4, 5, //
                                                             _
         9     7, 8, 9 };

    diy.c  9  Info 783:  Line does not end with new-line
    diy.c  9  Info 785:  Too few initializers for aggregate 'test2' of type 'int [9]'

    /// Start of Pass 2 ///

    --- Module: diy.c (C)
         1  int test[9] = {
         2     12, 31, 43, // test comment with continuation \
         3     3, 4, 5, //
         4     7, 8, 9 };
         5  
         6  int test2[9] = {
         7     12, 31, 43, // test comment with continuation \ 
         8     3, 4, 5, //
         9     7, 8, 9 };

    --- Global Wrap-up

    Info 714:  Symbol 'test' (line 1, file diy.c) not referenced
    Info 714:  Symbol 'test2' (line 6, file diy.c) not referenced

    The commentary on warning 437 (hyperlinked in the demo) is

     // comment terminates in \ -- A one-line comment terminates in
          the back-slash escape sequence.  This means that the next line
          will be absorbed in the comment (by a standards-conforming
          compiler -- not all compilers do the absorption, so beware).  It
          is much safer to end the line with something other than a
          back-slash.  Simply tacking on a period will do.  If you really
          intend the next line to be a comment, the line should be started
          with its own double slash (//).

    Demo can be found at gimpel-online.com/.../genPage.py

  • 0 in reply to Chester Gillon
    Guru 27665 points

    Chester Gillon said:
    The MISRA-C:2004 9.2 warning detects that the SourceSansPro_Regular_const[] array has only been partially initialized (see https://sonarqube.com/coding_rules#rule_key=c%3AS835 for an explanation of this MISRA-C rule).

    That should be sufficient to set off alarm bells but it appears you need to put in some effort to get that message. A non fully initialized const array would, I think, always be an error (or almost always). Even non-const arrays are usually non initialized or fully initialized IME.

    Robert

  • 0 in reply to f. m.
    Guru 92251 points

    f. m. said:
    While this might be an indicator, it is not really a proof. Those internal parsers are not the same as the compiler - every one more than superficially familiar with Eclipse knows this phenomenon. While the parser complains about errors, a build runs successful.

    Agree that wasn't checking the same parser as the compiler. In this case used the disassembly to find the array offset at which data was first "missing" and when viewed the source file in an editor the C syntax highlighting showed the problem. At that point I stopped looking, since had found an explanation without having to check the parser output from the compiler.

    Issues about the parse complaining about errors but the build bring successful are usually caused by difference in pre-defined macros or if parser is set to C++ and and compiler set to C mode (or vice-versa).

  • 0 in reply to Robert Adsett
    Guru 92251 points

    Robert Adsett said:
    Output from the demo (The demo echos the source for clarity , the real version does not). Note this is done with the demo's defaults which are looser than I usually use.

    Thanks for the demo, it shows FlexeLint produces more informative warnings than the TI or GNU compilers.

    To get a quick idea of the type of warnings that FlexeLint can produce, I pasted some of the winning entries from The International Obfuscated C Code Contest into the FlexeLint online demo.

  • 0 in reply to Chester Gillon
    Guru 10570 points
    That could be amusing.

    Over the years I've found that PC-Lint is far more informative and a better check than any C compiler I've ever used. If the compiler complains and Lint doesn't the compiler is almost invariably wrong. Just about the only exception is for some chip specific extensions which I avoid whenever possible since I have found them to be trouble prone.

    I turn up the screws rather tighter than the demonstration defaults. If you want a (possibly disturbing)insight into your code turn on strong typing. Just don't try it on a large project for the first time.

    Robert

    A note for anyone wondering FlexeLint and PC-Lint are the same distinguished only by the platform they run on and the price