• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 596 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.

CCS/TM4C129CNCPDT: Compiler wrong read the code, and jumps through lines.

Anton Baltser
Prodigy 40 points
Part Number: TM4C129CNCPDT
Other Parts Discussed in Thread: TM4C129ENCPDT, TM4C1294NCPDT, EK-TM4C1294XL

Tool/software: Code Composer Studio


Hello, There is own  firmware was written for evaluation board EK-TMC129EXl Rev A, where mounted CPU TM4C129ENCPT13. I used own .cmd file, I change, instead of custom (tm4c129encpdt). This evaluation board works well. While I use this firmware and launch this on other own board , where mounts CPU TM4C129CNCPDT, I have any problems.  I changed CPU number in CCS settings, and compiler works wrong, and reads code's lines incorrect, jumps through the block's code.
What are these problems? Could you help me to say which part of settings i have to check?

  • 0
    TI__Guru*** 128295 points
    Hello Anton,

    How are you coming the assumption the compiler reads code lines incorrect?

    Regarding jumping over code, depending on compiler optimization levels, that sort of behavior can be seen, especially when it comes to being able to set breakpoint. If there are compiler optimizations applied not all lines of code can have a breakpoint issued on them.
  • 0
    Guru 54118 points
    Hi Anton,

    Please try to explain in order of most priority the any problems with your own custom PCB. It would seem for TM4C129CNCPDT you should really select TM4C1294NCPDT in your CCS project. The CCS project must be modified for GPIO ports etc. your custom PCB uses or the entire project would cause m-any problems.
  • 0 in reply to Genatco
    Prodigy 40 points
    I use own board with TM4C129CNCPDT CPU, every time , when I debug my board I select this CPU number. Other man, change firmware boot_demo1 for evaluation board, and I want to use this firmware on my own board. 1) first issue compiler doesn't enter to right block of cycle. Also, this code manage cpu that to get a command by uart0, and them to cause bootloader mode, but in "realtime watch " CPU show other values, not same that I sent.
  • 0 in reply to Anton Baltser
    TI__Guru*** 128295 points
    Hello Anton,

    Let's simplify the issue a bit.

    Boot loaders can be complicated, and if there are doubts about properly compiling and executing code, that isn't the place to start.

    First, do you have any features you can easily test on your custom board without the boot loader? Such as, blinking an LED, sending data to a UART terminal over UART, etc.?

    If so, please test that functionality so you can get confidence the issue is not that the compiler is incompatible with your board.

    From there, we can address what you have done with the boot loader and find out if there are any errors with implementation.
  • 0 in reply to Ralph Jacobi
    Prodigy 40 points
    Hello, I've checked compiler, is it ok. Compiler goes step by step through right lines. But I have other issue. I use UART0, and send hex command. Program receive command, make cause When I use evaluation board(with cpu TM4C129ENCPDT), it works right, and program runs some process, then sends answer hex message. When I'm using own device (cpu TM4C129CNCPDT), program doesn't send hex message, it sends some symbols, wrong message. What can break this process?
  • 0 in reply to Anton Baltser
    Guru 117850 points

    Admittedly - English proves a (most) difficult language to understand & master.

    That said - there IS a 'vast difference'  between the (earlier) reported,

    • "Compiler wrong read the code, and jumps through lines!"

    and the most recent:

    • "I've checked compiler, isit (it is) ok.   Compiler goes step by step through right lines."

    Might your helpers (rightly) ask - which statement proves (now) correct?      And ... is this (latest) report, "program doesn't send hex message" - likely to (drastically change) as well?

    So sudden - and so great a change in your reporting (compiler FAILS - then WORKS!) - minus (any) explanation - raises much doubt w/in your helpers.

    To your (latest) question, "What can break this process?"  have you confirmed:

    • that the baud rate is properly matched - between your MCU - and the (unidentified) remote device?
    • unwanted symbols may indicate that the ms(bit) has been set - ASCII usually employs the (lower) 7 bits, only.     (note that unequal baud rates - may also cause this)
    • along w/baud rate - have ALL other 'serial protocol elements' been checked (and confirmed) for match?    (i.e. data-bits, parity, stop-bits, and hardware 'handshakes' (i.e. flow control))

    Your systematic test/verify - and reporting - speeds & eases your, 'Path to Success.'

  • 0 in reply to Anton Baltser
    Guru 54118 points
    How does UART0 connect to a computer serial console or do use only CCS console? What hardware to lead if computer, attach schematic that part! Make sure MOSC oscillates proper frequency or PIOSC how we know what you did to hardware. We need more info to help you but Ralph suggestion good, modify test code to match custom PCB, unless exact same layout as EK-TM4C1294XL.
  • 0 in reply to Genatco
    Prodigy 40 points
    The UART0 connect to Bluetooth transmitter, I use serial console. I will check bauds rate.
  • 0 in reply to Anton Baltser
    Guru 117850 points

    Do note - my suggestion to check the baud rate also directed the "checking of vital (other) protocol settings" - which (also) must be matched!

    To best illustrate:

    Again - you must insure that 'ALL of those 5 settings' - listed above - are  'matched'  between your MCU and remote device.

    Flow Control is  'unlikely'  to create (unwanted) symbols - yet may 'stall and (even) prevent' - your serial data transfer.   (flow control may assume hardware (CTS/RTS) or software (Xon/Xoff) - for simplicity (at this stage of your development) best to specify, 'NONE/OFF.')

    You MUST follow KISS - to achieve the best & quickest success.    Any use of a bootloader adds immense complexity  (and debug time/effort) to your task! 

    Myself - others - feel strongly that (any) bootloading attempt should be postponed.   (until after you have CONFIRMED - that your program runs correctly - in its ENTIRETY!)

    JTAG IS your friend (SURE/SOLID - and EASED!)     Bootloader most always proves a DELAYING & CONFOUNDING factor - and it must be asked ...  to what point or means?   (why is the bootloader deemed important?)