• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 581 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.

TMS320F28335: Custom bootloader design sanity check

Kenneth Lyons2
Prodigy 30 points
Part Number: TMS320F28335


I'm planning a design for a custom secondary bootloader for the 28335 and I would appreciate a sanity check. Here are my requirements:

  1. Only UART is available in production
  2. Application must be stored in flash
  3. Several other blocks of arbitrary data must be stored in flash, each block individually erasable/programmable (separate sectors)
  4. Bootloader must have a "passthrough" mode that passes data from UART out to a different peripheral

The concept is as follows:

  • Under normal circumstances, boot ROM jumps to flash and runs the main application
  • When the boot ROM is configured for SCI boot mode via GPIO pins:
    • For application, host uses a program like SDFlash with RS232 serial patch to program via boot ROM
    • For data, host sends an entry point address which I've specified via linker script to be the address of the secondary bootloader "boot_main", then re-establishes UART to erase/program flash via flash API, pass through data, etc.

I'd like for the firmware and the secondary bootloader to be in the same CCS project as the application. The alternative would be to maintain a separate bootloader project and load it into RAM via boot ROM, but I'd like to avoid having two separate projects if possible. My main question then is, will sending what is essentially a "jump to secondary bootloader" command to the boot ROM work? That is, if I place my "boot_main" function at a specific address via the linker, then send that address as the entry point to the boot ROM, are there other considerations I should know about? I know that typically the boot ROM jumps to code_start which then calls _c_int00 for C initialization (and it calls main), so is there a way to achieve what I've described?

  • 0
    TI__Mastermind 30255 points

    Hello

    Yes, the entry address set via the CCS project/linker is what it will jump to. Are you describing sending just the entry address and dummy data to use SCI boot to jump to a different address? I haven't tried it, but I think that could work.

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Prodigy 30 points

    Correct. Actually I was sort of assuming that sending the entry point address then 0x0000 (i.e. block size zero signifying end of data stream) would work to make the boot ROM jump to the given address. My main question is what exactly do I need to place at that address in order to get a completely separate program (written in C) running? I suppose I'm wondering if it's feasible to add a "boot_code_start" assembler function to DSP2833x_CodeStartBranch.asm, place it at the address I plan to have the boot ROM jump to, then have that do setup and call my C "boot_main" function. In other words, is it possible/feasible to implement what `LB _c_int00` does for a secondary main function?

    edit: Looking through section 7.10 of the TMS320C28x compiler user's guide (SPRU514S), this may present more challenges than simply maintaining a separate bootloader CCS project that I can load into RAM for each operation I listed in my original post. It'll be a little bit of a maintenance headache, but it saves me some flash space. I'm still wondering if there's a relatively straightforward approach to achieve a "secondary main" function in one CCS project though.

  • 0 in reply to Kenneth Lyons2
    TI__Mastermind 30255 points

    As you mentioned, if you want to have "two" instances of c_int00, it will be more work than having separate project. 

    Maybe you can jump to a different address (in the case where you pass the address through the bootloader), where it sets a register bit or something to indicate you want to run the secondary function, then it runs the c_int00 for single main and then within the main() (of your primary project), it checks that register bit where it then knows you want to run the second app and then does long branch to that main() function (in this case c_int00 already ran so you don't have to call it again).

    Best regards

    Chris

  • 0 in reply to Christopher Chiarella
    Prodigy 30 points

    Ah, that's an interesting idea. I guess in that case I'd just have to look over the RTS source to identify one of the auxiliary registers that's not used in c_int00.

    An advantage of separate projects I hadn't thought of is simpler debugging. I'm thinking at this point I'll move forward that way at least for now, keeping the possibility of merging them in my back pocket.

    I appreciate your help. Marking this as resolved.