TM4C1294 TivaWare Bootloader Question

Hi Marco,

Are you using the ROM based bootloader? If so your code could start at 0H since you do not need any bootloader code in your code. I have been using the internal ROM based bootloader for both serial and USB and has worked perfectly. I am using the TM4C1294 device.

Alan

Hi Alan,
thanks for your reply.
I don't use the internal bootloader, because it doesn't work with ethernet communication port (and i need it).
I'm using the bootloader included in TivaWare software tool.

Best regard,
Marco

Hi Marco,
Did you also change the applications base address to 0x0000.4000 in (my_application_ccs.cmd) file?

Hi BP101,

yes, I do.

Thanks,

Marco

Hi Marco --- (at 0x0000 address) and also the timers application (star at 0x4000).

Those are incorrect address - the prepended zeros matter.

Might you use the proper address 0x00004000 then maybe happiness and smiles?

When CCS5 make sure the application Builds to complete success.

Suggest don't rely on last compile message only, sometimes terminal reports the APP builds ok when not at all OK so scroll up review the secession log for any errors.

Boot Loader

Hi BP101,
thanks for your reply.
Yes, addresses are in correct form of 8 digits.

I use CCS6 and I've checked the log. There are only some warnings:
- 14 that reports: #1173-D unknown attribute 'packed' (but this refers to an attribute 'packed' that doesn't seem to be supported in this compiler).
- 1 with message: #10247-D creating output section ".cinit" without a SECTIONS specification boot_eth C/C++ Problem
- and others 5 messages that have the same warning number, but refers to different sections: #10278-D LOAD placement specified for section ".text:decompress:none:rtsv7M4_T_le_v4SPD16_eabi.lib<copy_decompress_none.obj>". This section contains decompression routines required for linker generated copy tables and C/C++ auto-initialization. Must ensure that this section is copied to run address before the C/C++ boot code is executed or is placed with single allocation specifier (ex. "> MEMORY").

I try do load (with emulator) the timers application with the bootloader previously loaded. I see the bootloader vector table and bootloader code at 0x0000 address and the timers vector table and related code at 0x4000.
With Step-by-Step emulation I can see the correct bootloader execution and the correct timers application call. But, while background procedure of the timers application works, interrupt don't work. I try also to set the VTABLE register to correct vector address (0x00004000) at the first instruction of the main function but the interrupts still don't work. At the Irq vector addresses the are the correct function calling address.

I've tried to do other 2 tests:
1- When I compile and load (obviously without the bootloader code) the timers application with the code section to 0x00000000 the irqs works properly.
2- When I compiler and load (also without the bootloader code) the timers application with the code section to 0x00004000 or other address multiple of 1024 bytes, the irqs don't work (with or without setting the VTABLE register).

There are others register to be set to obtain the correct IRQs functioning?

Many thanks in advance for any reply.

Best regards,
Marco

Hi BP101,
eureka, I think to have found the solution.
In timer_ccs.cmd configuration file, the .vtable section was located in RAM_BASE. After I try to locate it in APP_BASE section, all works properly.

Could this solution be correct?

Best regards,
Marco

---------------------------------------------
This is the orignial CCS6 code

/* The starting address of the application. Normally the interrupt vectors */
/* must be located at the beginning of the application. */
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000

/* System memory map */
MEMORY
{
/* Application stored in and executes from internal flash */
FLASH (RX) : origin = APP_BASE, length = 0x000fc000
/* Application uses internal RAM for data */
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* Section allocation in memory */

SECTIONS
{
.intvecs: > APP_BASE
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH

.vtable : > RAM_BASE
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}


-------------------------------------
And this is the modified one

/* The starting address of the application. Normally the interrupt vectors */
/* must be located at the beginning of the application. */
#define APP_BASE 0x00004000
#define RAM_BASE 0x20000000

/* System memory map */
MEMORY
{
/* Application stored in and executes from internal flash */
FLASH (RX) : origin = APP_BASE, length = 0x000fc000
/* Application uses internal RAM for data */
SRAM (RWX) : origin = 0x20000000, length = 0x00040000
}

/* Section allocation in memory */

SECTIONS
{
.intvecs: > APP_BASE
.vtable: > APP_BASE /* VTABLE in APP_BASE section, instead of RAM_BASE */
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH

.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}

Hi Marco,

I can't easily notice any difference between the original APP_BASE address and the one you show as being changed.

BTW: Checking the APP_BASE was first mentioned a few posts up.

Think your Boot Loader may has same issue we had for some 8 months. Put it aside then one day found section at top of (bl_Ethernet.c ) was setting clock for TM4C123 MPU. That incorrect clock code was halting the MPU.

Comment that Tiva clock code out and UREKA the boot loafer the works. 

Ok see what U're inferring here:

.vtable: > APP_BASE /* VTABLE in APP_BASE section, instead of RAM_BASE */

Boot Loader reads the vector table from SRAM not Flash, Think this is same issue we had recently, the (bl_flash.c) fails to erase on a page boundary if set less than the app_base address. All settings must be on 16KB boundary in (bl_config.h)

Hi BP101,
vtable segment refers to timers test application, not to bootloader.
I checked file bl_emac.c (this file has replaced bl_ethernet.c) and I saw that clock settings were correct.
Also the page boundary in bl_config.h were ok.
At this point I think the bootloader system works fine.

I would like to thank you for your precious help.

Best regards,
Marco

Ok but we never modify these two entries: (.vtable) is a separate entry under sections and should not exist under (.intvecs). The code view changes entry colors for the other entries under each Separate entry section. Sorry that was (bl_emac.c) shown below not (bl_ethernet.c).

SECTIONS
{
    .intvecs:   > APP_BASE
    .text   :   > FLASH
    .const  :   > FLASH
    .cinit  :   > FLASH
    .pinit  :   > FLASH
    .init_array : > FLASH

    .vtable :   > RAM_BASE
    .data   :   > SRAM
    .bss    :   > SRAM
    .sysmem :   > SRAM
    .stack  :   > SRAM
}

>> The (bl_emac.c) discovery we made causes Rev. 3 silicon in TM4C1294X MPU to Halt. 
>> Halts MPU when BL loads the application or the application invokes the BL, one of the two.
//
// Define ROM_SysCtlClockFreqSet() for snowflake RA0. Even though this function
// is deprecated in RA0 ROM, the function operates correctly when 
// SYSCTL_MOSCCTL register is configured correctly prior to calling this
// function.
//
//#if defined(TARGET_IS_TM4C129_RA0)
//#define ROM_SysCtlClockFreqSet                                                \
        ((uint32_t (*)(uint32_t ui32Config,                                   \
                       uint32_t ui32SysClock))ROM_SYSCTLTABLE[48])
//#endif

Ok, without the ROM_SysCtlClockFreqSet line and with .vtable in RAM_BASE, the bootloader and the application still work.

Thanks a lot

Hi BP101,
yes, you answered to the question and the problem was solved.

thanks a lot for your support,
Marco