• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 30 subscribers
  • Views 482 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM263P4: Understanding resets and boot vectors

Eric Liu
Prodigy 35 points
Part Number: AM263P4

Tool/software:

Hi,
I wanted to double check my understanding regarding the boot vector table in TCMA and resets:

  1.  There is no way to reset back into ROM bootloader once it's been eclipsed and control has been passed to SBL/SW. The software controlled resets will cause the R5 to start using the boot vector at address 0. 
    1. What happens if the boot vector is corrupted and a reset is commanded? Rely on PMIC watchdog for an external POR reset?
    2. I know, in theory, we can switch back to the SBL by setting its boot vector table to 0, but is this a recommended practice? 
  2.  If all cores are reset using boot vector at address 0x0000_0000, does that mean they all have to share the same vector table? And within the vectors, we can switch behavior based on their core ID?

Thanks!

  • 0
    TI__Mastermind 26025 points

    Hi Eric Liu,

    Eric Liu said:
    What happens if the boot vector is corrupted and a reset is commanded? Rely on PMIC watchdog for an external POR reset?

    Yes. This is expected and such a failure is a catastrophic failure and requires at least warm reset to restore the system.

    Eric Liu said:
    I know, in theory, we can switch back to the SBL by setting its boot vector table to 0, but is this a recommended practice?

    Not via software. You should rely on warm-reset flow to reset the system.

    Eric Liu said:
    If all cores are reset using boot vector at address 0x0000_0000, does that mean they all have to share the same vector table? And within the vectors, we can switch behavior based on their core ID?


    Each core has its TCM memory which is mapped at 0x0 in their access. Physically the memories are different memories but for TCM fast path they are mapped at 0x0 which allows them faster access. So NO, however the address for 0x0000_0000 is same for boot vector for all the CPUs, they are essentially different memories and different vector tables.

    If it may interest you, this FAQ will help you clarify a lot of your questions regarding the reset architecture of the device - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1342613/faq-mcu-plus-sdk-am263x-what-are-the-difference-types-of-reset-in-the-soc

    I hope this helps.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 35 points

    Thanks Aakash,

    That was very helpful and cleared up a lot, I have one follow up question, is there a recommended way to switch between applications within a core? Example: there is an additional bootloader after the SBL, and that additional bootloader needs to load the main application.

    My assumption is we change the contents of the boot vector to the image we want to jump to and then reset. Wil this work and is this advisable? 

  • 0 in reply to Eric Liu
    TI__Mastermind 26025 points

    Hi ,

    My recommendation would be to always use a simple jump or branch instruction to your Tertiary Bootloader. However it is more complicated as it involves Cache, MPU and Interrupt Controller (VIM) to be reinitialized cleanly.

    So another option is to use G_RST mentioned in the FAQ above. This will allow all the subsystem items to be cleared automatically. This also means you will observe trace module i.e. ETM and the debugger also getting cleared. For AM263Px you will see the RAT and RL2 also getting reset with the same.

    Its your call how to do the same.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 35 points

    In the first method you suggested where we use a jump/branch from the tertiary bootloader, would the exception table at 0x0000_0000 still have to be changed? Does the R5 hardware just look at 0x000_0000 for just the reset handler or for the other exceptions as well? 

    If I'm understanding the SDK correctly, we need to manually register the IRQ/FIQ handlers in the VIM, so those don't explicitly need to be in the table at 0x0000_0000?

    Thanks for helping clear things up,

    Eric

  • 0 in reply to Eric Liu
    TI__Mastermind 26025 points

    Hi ,

    Your exception table (reset handler) needs to point to the initialization code of tertiary bootloader. This requires update. You can reuse the exception handling for FIQ/IRQ code across bootloaders, but it may complicate your design especially for your development flow where you would prefer to use CCS Load flow.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 35 points

    Hey , 

    Sorry, I'm afraid I'm still a little lost. In my hypothetical (all on the same core): SBL loads Tertiary Bootloader, TertiaryBL loads Application. From the documentation, I can gather that from SBL -> TertiaryBL, we need to point the exception table to the initialization code of the Tertiary BL and then command a reset. 

    I'm unclear on what the steps are to go from TertiaryBL -> Application. From your earlier comment, one option is to have a branch/jump command from the TertiaryBL -> Application initialization code, but I want to know if we also need to modify the exception table at 0x000_0000 so the Application's vectors are in it. In other words, from a MCU hardware perspective, does the exception table only contain the start address of the code in that core, or does it also need other entries in the table for execution?

    Thanks again, 
    Eric

  • 0 in reply to Eric Liu
    TI__Mastermind 26025 points

    Hi Eric,

    Reset comes with a price. If you overwrite the vector table (before rest) you open a window where your current software lacks a exception table and can lead to catastrophic failure. However, it makes the software easier as all the core dependencies like MPU, cache, vectors or debug registers are rested and you observe a clean start of program.

    My suggestion would be to reduce the window of failure to as minimum as possible. Just before you reset the CPU or the subsystem overwrite the interrupt table. Don't overwrite anytime throughout your system execution.

    Best Regards,
    Aakash