• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 490 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.

TM4C123BH6ZRB: BOOTLOADER

Mohsin Mahmud
Intellectual 610 points
Part Number: TM4C123BH6ZRB

Hi ,

I NEED some help regarding UART based boot loader . I have able to update my application from Uart boot loader. Problem is that I want to modify the UART bootlader . Want to use interrupts including timer and UART serial interrupts in boot loader. Can you help me on that? Currently when I try to use timer and UART interrupt in boot loader and put interrupts function in start up file, my boot loader doesn’t work.

Also is it possible to debug the boot loader as breakpoints doesn’t work either .

Regards,

Moh

  • 0
    Mastermind 8695 points

    The bootloader copies all code to SRAM and the processor runs from SRAM there so that the processor is free to erase and write to any flash location.

    Normally, you are breaking on hardware breakpoints when running from flash, but when running from SRAM, the debugger modifies the SRAM opcode. If you look at the breakpoints window, you will notice it says SWBP instead of HWBP. The op code swap is not visible from the disassembly, but you may be able to see it in the memory browser.

    The problem you are experiencing is due to the copy procedure also being copied; the opcodes copied into SRAM re-copy to SRAM. Your software breakpoint debugger trick gets overwritten. I calculated that you can single step through the copy loop ~870 times before you get the ability to set a breakpoint immediately after the copy loop. After breaking past the copy loop, you are free to set breakpoints anywhere. This worked for me. I don't remember the exact number. Try 900 to be safe.

    Or you can just let the program run for a while, pause, then set breakpoints.

  • 0 in reply to Peter Borenstein
    Guru 117855 points

    *** LIKE *** Nicely written.

    May I register "concern" at poster's (unjustified) desire to, "Force interrupts - both timer & uart - upon the bootloader."    Should this addition - sufficiently deviate from the vendor's "normal/customary" code design plan & implementation - problems (may) lurk.   (even be "expected" to lurk.)

    Neither firm nor I employ vendor's bootloader - should interrupts be "integral" to the vendor's bootloader design - this caution may be disregarded.

    In general - the practice of modifying, "Known Good Code" (in such a dynamic, multi-memory transfer environment) - w/out proper justification - invites issues & should be implemented (only) if and when - truly justified.     (no such use-case has been presented!)    And then - only with extreme care - and substantial "Test/Verification."

  • 0 in reply to cb1_mobile
    Intellectual 610 points

    Hi, I have no intensions to modiffy good working code. Problem is that I want to add more functionality in boot loader. How I can achieve that withoout modifications. Thanks

  • 0 in reply to Mohsin Mahmud
    Guru 117855 points

    I believe our posts have "crossed."     As I wrote - should the bootloader require, "Special care/handling" to accommodate your "added" interrupts - some caution is warranted.

    Our firm does not employ vendor's bootloader - I am providing "Precautionary Advice" (just in case) as we've noted (similar) issues among (other vendors') ARM MCUs - operated as you propose... The "dynamic nature" of the bootloader (may) be compromised by the arrival of "unplanned/unexpected such interrupts" - that is my concern!