• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 180 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294NCPDT: epi.h, ble_central.c apostrophe: strange 0x92 byte in place of plain 0x37 byte

Piotr Kasprzyk
Prodigy 170 points
Part Number: TM4C1294NCPDT

Good Morning!

In each of files:

tivaware_c_series_2_1_4_178/driverlib/epi.h
TivaWare_C_Series-2.2.0.295/driverlib/epi.h

there are 12 places where strange (non-plain-ASCII) 0x92 apostrophe is used in place of plain-ASCII 0x37 code.

I am using Polish letters using UTF-8 and while decoding "epi.h" files I got error in Python 3:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x92 in position 15481: invalid start byte

This error vanishes when plain apostrophe (ASCII hex code 0x37) is used.

Almost all *.c/*.h files in TivaWare use plain 0x37 apostrophe, only "epi.h" (and "tivaware_c_series_2_1_4_178/examples/boards/dk-tm4c129x/ble_central/ble_central.c") use 0x92 code for apostrophe character.

Best wishes,

Piotr Kasprzyk

  • 0
    TI__Guru**** 168676 points

    Hi Piotr,

      I open tivaware_c_series_2_1_4_178/driverlib/epi.h and remove pretty much everything except just a few lines that contains the 'don't' in the file. I then upload the modified file to an online ASCII converter and it produces 0x27 for the apostrophe. BTW, I think yo meant all other files use 0x27, not 0x37. I don't know why you are getting the error. In any case, you are free to modify epi.h file if that will resolve the issue. Tivaware has been quite stable and there is currently no plan for any update. 

      Here is the original epi.h when I open it in notepad++. I see as in 'don't', not 'don.t'. 

      Here is the modified file I use for uploading to online converter.

    epi.h

      Here is the online website I use. https://www.rapidtables.com/convert/number/ascii-hex-bin-dec-converter.html

      Here is the result I got. 

      

  • 0 in reply to Charles Tsai
    Prodigy 170 points

    I agree, 0x27 / 0x37 mistake is my own - it should be HEX 0x27 or decimal 39.

    But the 0x92 problem is still there:

    I downloaded SW-TM4C-2.1.4.178.exe (File: SW-TM4C-2.1.4.178.exe - 171094 K TivaWare for TM4C Series) from "">www.ti.com/.../2.1.4.178" and inside there is a file C:\ti\TivaWare_C_Series-2.1.4.178\driverlib\epi.h that is 28124 bytes long.

    I have put this original file for checking https://www.ciri.pl/epi.h

    The 0x92 problem is still there and www.rapidtables.com has problems with interpreting it - the value is shown as FFFD (marked with red line on picture) after some strange conversion:

    I have used Linux standard "od" (octal dump, in hex+TXT mode) command to show, where 0x92 bytes are located:

    I can see 12 red-marked "92" bytes.

    And I wrote short Python code to show value of byte with offset 0x3c79 (the offset for the first 0x92 byte) and it shows value: 0x92 (in hex) and 146 (in decimal):

    Under Windows I have used "certutil" command to generate and show 0x92 byte (marked red) on 0x3c79 offset:

    So I think the problematic 0x92 byte really is in this file - I can check it under Linux and Windows.

  • 0 in reply to Piotr Kasprzyk
    TI__Guru**** 168676 points

    Hi,

      I just open your file in Chrome browser and it shows 'don't' properly. I'm not an expert in how the fonts are rendered in different language packs. As I said, you are free to modify the file. Can you try that? Perhaps retype the same lines in your own platform and see how they come out. If it renders properly, you can delete the original lines. 

  • 0 in reply to Charles Tsai
    Prodigy 170 points

    On this screenshot you marked 2 different apostrophe shapes - they are different if you look closely. Both are apostrophes but one is plain ASCII 0x27, and the other is Windows apostrophe with 0x92 code. I got a dot (and not apostrophe) in "don.t" because ASCII+HEX converters automatically replace codes above 0x7F with dots (ASCII has no representation for bytes 128-255). Thank you, I have cleaned my version of "epi.h" and now I can work :) Thank you again!