• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 331 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.

CCS/TM4C1294NCPDT: Is it possible to debug two projects on the microcontroller at once?

Gavin Minion
Prodigy 50 points
Part Number: TM4C1294NCPDT

Tool/software: Code Composer Studio

I am working on a bootloader for the TM4C1294 which will reside at address 0x00000000 and occupy the first 16K of flash memory. The application will then sit at 0x00040000 and access the remainder.

On startup, the bootloader checks for an application in the application memory and will execute the application if it exists, otherwise, it will load the application from an external flash part reprogramming the memory above 0x00040000. To update the application, the bootloader is invoked by the application and forces the reprogramming from the flash part.

Is it possible to setup the debug suite (Code Composer studio) so that both the bootloader and the application are loaded into flash by the debugger so that the memory layout appears as it would during a normal power on cycle?

Also - and directly related - if the application is run on its own, the lack of software below 0x00040000 appears to cause the ROM bootloader to be invoked. Is there a way to prevent this happening? It would not be an issue if I could get the bootloader installed there.

Thanks.

  • 0
    TI__Guru*** 135355 points

    Hello Gavin,

    There are some tricky elements at play to try and do this, but this post by Bob walks through the various settings you can leverage in CCS to handle that the boot loader runs out of the SRAM and also the challenges with getting both the boot loader and application loaded in a way that allows for debug: https://e2e.ti.com/support/microcontrollers/other/f/908/p/684426/2521822#2521822

    See if that gets you towards what you need from a debug standpoint and let me know if you get hung up with any of those points due to having the external flash element involved as well.

    Regarding the ROM bootloader, the conditions for the ROM bootloader would not be met if the Flash bootloader is properly programmed.

    The details of this can be read under Register 68: Boot Configuration (BOOTCFG) of the device datasheet, page 674. I am copying the most relevant sections below:

    At reset, the user has the opportunity to direct the core to execute the ROM bootloader or the application in Flash memory by using the GPIO signal configured in BOOTCFG register. At reset, the following sequence is performed:

    1.The BOOTCFG register is read. If the EN bit is clear, the ROM Boot Loader is executed.
    2.In the ROM Boot Loader, the status of the specified GPIO pin is compared with the specified polarity. If the status matches the specified polarity, the ROM is mapped to address 0x0000.0000 and execution continues out of the ROM Boot Loader.
    3.If the EN bit is set or the status doesn't match the specified polarity, the data at address 0x0000.0004 is read, and if the data at this address is 0xFFFF.FFFF, the ROM is mapped to address 0x0000.0000 and execution continues out of the ROM Boot Loader.
    4.If there is data at address 0x0000.0004 that is not 0xFFFF.FFFF, the stack pointer is loaded from Flash memory at address 0x0000.0000 and the program counter is loaded from address 0x0000.0004. The user application begins executing.

  • 0 in reply to Ralph Jacobi
    Prodigy 50 points

    Hi, thanks for the response, yes, I will give this a try.

    Regarding the bootloader, I understand and am implementing a bootloader to fill the memory. I was simply wondering if the ROM bootloader check you describe can be overridden such that execution does not pass to the ROM bootloader when on the debugger under any circumstances. I did notice that, when debugging code which starts at 0x00040000, the debugger appears to locate at the correct start address, implying it is aware not to start at 0x00000000.

  • 0 in reply to Gavin Minion
    TI__Guru*** 135355 points

    Hello Gavin,

    In debug mode in CCS, it would bypass the ROM boot loader and would not connect to it, so you should be fine on that front. The ROM Boot loader allows for boot loading over interfaces like UART, USB, and Ethernet. It is not used for JTAG programming which is what you would use for CCS debug.