• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1367 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.

Custom bootloader

Cameron
Prodigy 80 points


I'm running a modified version of the boot_serial demo to do a firmware update on a TM4C123 microcontroller. I am able to
load the bootloader at 0x00 and the application at 0x2800 by updating over JTAG. Then I disable
interrupts in the application and jump to the bootloader. From there, I'm able
to successfully ping the bootloader, receive acknowledgement, then send a COMMAND_DOWNLOAD, which returns success,
then send the new application via the SEND_DATA command, verifying that all packets are being acknowledged.
However, after sending the COMMAND_RESET command, the old application has been erased, and the
new version is either not working/not present/not being jumped to.  Attaching the debugger to the bootloader, which is still present,
shows that is is caught in a while loop in UARTReceive. Here's my configuration.

In the application:
#define APP_BASE 0x2800
#define APP_LENGTH 0x0003d800
#define RAM_BASE 0x20000000

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

In the bootloader:
MEMORY
{
FLASH (RX) : origin = 0x00000000, length = 0x00010000
SRAM (RWX) : origin = 0x20000000, length = 0x00010000
}

And bl_config.h has the following defined:
#define APP_START_ADDRESS 0x2800
#define VTABLE_START_ADDRESS 0x20000000
#define FLASH_PAGE_SIZE 0x00000400
#define STACK_SIZE 48
#define BUFFER_SIZE 30

  • 0
    TI__Guru**** 244400 points
    Hello Cameron,

    Did you check the location 0x2800 and 0x2804 for the contents? Is it all 1's or does it have a SP and PC like value which should correspond to the first two locations of your bin file?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points
    Viewing the values at 0x2800 shows the following:

    00002800: 464C457F undefinedSUB16MIR4, R12, PC
    00002804: 00010101 ANDEQ R0, R1, R1, LSL #2
    00002808: 00000000 ANDEQ R0, R0, R0
  • 0 in reply to Cameron
    TI__Guru**** 244400 points
    Hello Cameron,

    That does not seem correct. The first location 0x2800 must have a value like 0x2000yyyy (basically a SRAM location). Did you check it in the bin file?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 2315 points

    One possible issue is that you have defined VTABLE_START_ADDRESS to be located in RAM. It should be the same value as your APP_START_ADDRESS, unless you are intentionally meaning to relocate the VTABLE to RAM. What might be happening is that when you load your code via the debugger the VTABLE gets successfully put in RAM, but when you boot via the bootloader it is expecting the VTABLE to be at the APP_START_ADDRESS location.


    --Dave

  • 0 in reply to Amit Ashara
    Prodigy 80 points

    After running the update, I attached the debugger and viewed the location in the disassembly window in CCS.

  • 0 in reply to Dave Hohl
    Prodigy 80 points
    I tried setting VTABLE_START_ADDRESS to the same value as APP_START_ADDRESS, but am still having the same issue.
  • 0 in reply to Cameron
    Expert 2315 points

    One thing you might try is to first load your app using the debugger, and save the code memory space to a file. Then use the bootloader to load your app and do the same. Compare the two files to make sure your app got loaded properly. If the files are different, your app did not load properly.


    Also, you can compare just the first two entries of the intvec table after loading via debugger and loading via bootloader. As Amit said, the first entry should be a valid RAM address and the second entry should be the address of your reset ISR, which you should be able to determine from the .map file.


    Regards,

    Dave

  • 0 in reply to Dave Hohl
    Prodigy 80 points

    Thanks Dave, it looks like the first entry is invalid when loaded via the bootloader, but is valid when loaded via the debugger.  

  • 0 in reply to Cameron
    TI__Guru**** 244400 points
    Hello Cameron,

    Can you send the binary image for comparison?

    Regards
    Amit
  • 0 in reply to Cameron
    Expert 2315 points

    Hi, Cameron,

    Assuming you have a binary file editor, you could take a look at the file to see whether the first entry matches the code that gets downloaded via the debugger. If it doesn't, then the problem is that the file is either not getting generated properly, or is somehow getting corrupted after the fact.


    If it does match, then it would seem the bootloader is not loading it properly. You could single step through the loading process to see whether the first entry is getting copied properly. If it is, then it must be getting corrupted later on in the process.


    Regards,

    Dave

  • 0 in reply to Dave Hohl
    Prodigy 80 points
    I've been doing some testing and believe that the file is getting corrupted.
  • 0 in reply to Cameron
    TI__Guru**** 244400 points
    Hello Cameron

    Where is the file corrupted: On the disk, or during download?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points
    I believe the corruption is occuring before download, so it is out of the scope of the bootloader.
  • 0 in reply to Cameron
    TI__Guru**** 244400 points
    Hello Cameron,

    OK, so the uC is out of the picture. Try to regenerate the bin file and check the same by loading it directly to the uC.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 2315 points

    One thing that might be going on here is that the binary file is not in the same format as expected by the bootloader. I am just working from an admittedly vague memory here, but as I recall some of the bootloaders (e.g., the USB BL that uses DFU) require that the binary file have some additional information prefixed to the actual executable code. Others (e.g., the USB stick updater) take just a straight binary file with no header info prefixed.

    Might it be that the project that is to be downloaded is configured to add the prefix info, and the BL does not expect it? Or vice versa?

    Regards,

    Dave

  • 0 in reply to Dave Hohl
    TI__Guru**** 244400 points
    Hello Dave,

    The UART, I2C and SSI boot loaders do not need to prefix anything to the file. The prefix on the packets take care of the information flow.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 2315 points
    OK, So Cameron might want to check to make sure that the project's output file format is set to plain binary and not some other format.

    Regards,

    Dave
  • 0 in reply to Dave Hohl
    Guru 56033 points

    Hi Cameron

    And bl_config.h has the following defined:
    #define APP_START_ADDRESS 0x2800
    #define VTABLE_START_ADDRESS 0x20000000

    That 0x2800 infers the BL binary is 10,240 bytes in length is that your intent?

    Have past discovered (bl_flash.c) is very particular the ASA, VSA and FPS have a similar SA and at least with tm4c1294 exist on a 16k boundary. Amit in past posts drills that point many times this forum.

    Otherwise an incorrect FPS overwrites the ASA and corrupts parts of the binary object when compared before/after. 

     

  • 0 in reply to Genatco
    Prodigy 80 points
    The base problem was that I was loading the project initially with the debugger, so it was utilizing the .out file generated by CCS, which was in eabi (ELF) format. I didn't realize that this is not the image needed by the bootloader. The .out file is what I was sending to the bootloader, and was not what it needed. I needed the .bin file to send to the bootloader. I created one for the project by adding a post build step in Properties->C/C++ Build->Settings->Build Steps, I added the command "${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd" "${CG_TOOL_ROOT}/bin/armhex" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin". This generated the .bin file needed, and when loaded it worked correctly.
  • 0 in reply to Cameron
    TI__Guru**** 244400 points
    Hello Cameron

    Thanks for posting back the resolution. This in fact is a good information for us as well to modify a new application to accept both bin and out file instead of just the bin file

    Regards
    Amit