• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 126 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.

Original question:

TMS570LC4357: EMS 2.3 Bus Error on Devboard, but not on custom board

TMS570LC4357: Issue with calling systemInit() after jumping to application

Paul Sheppard
Prodigy 130 points

Part Number: TMS570LC4357

Hello, me again!

So I've had application working for a while, but with the addition of the saftey-lib self tesing added to boot, the start-up is much more complex. I've found that when jumping to application I get a data abort within systemInit(), specfically in periphInit().

Is there an issue calling this function twice during execution? Once during boot start-up, then again in the application (of course a different one)?

I have solved this in a different way - In boot, instead of jumping with a:

((void (*)(void))entryPointAddress)(); 

I store the entry point address at a specific memory location then perform a software reset. 

Then in the _c_int00(), case SW_RESET: I check that address and jump straight to the app. It will then perform all the usual _c_int00() stuff.

This means that all the start-up stuff is only performed once. It seems much more reliable, but maybe less intuitive/logical.

  • +1
    TI__Guru* 76996 points

    Hi Paul,

    I never did this, i mean i never called systemInit twice before.

    However, i got some useful tips from our internal AI, please verify this response once:

    Yes, there is an issue with calling systemInit() twice during execution. When you jump directly from the bootloader to the application using a function pointer like ((void (*)(void))entryPointAddress)(), the hardware peripherals are already initialized from the bootloader's systemInit() call. When the application then calls systemInit() → periphInit() again, it attempts to re-initialize peripherals that are already configured, which can cause:

    1. Data abort exceptions - Attempting to write to peripheral registers that are in unexpected states
    2. Peripheral conflicts - Some peripherals may not handle re-initialization gracefully
    3. Safety mechanism conflicts - With safety library self-tests running in the bootloader, the system state becomes more complex

    This is particularly problematic on Hercules safety devices like the TMS570LC4357 where:

    • Safety features (lockstep CPUs, ECC, BIST) are active
    • Peripheral states are more strictly controlled
    • Self-test libraries modify system configuration

    Your Software Reset Solution is Valid

    Your approach of performing a software reset and jumping in _c_int00() is actually a recommended pattern for bootloader-to-application transitions, especially in safety-critical applications. Here's why it's superior:

    Advantages:

    1. Clean system state - The reset ensures all peripherals return to their reset state before application initialization
    2. Proper startup sequence - The application goes through the complete _c_int00() initialization, including:
      • Memory initialization (_memInit_())
      • Stack setup
      • C/C++ runtime initialization
      • Proper systemInit() execution
    3. Safety library compatibility - Self-tests run once in bootloader, then clean transition to application
    4. More reliable - Eliminates peripheral state conflicts and initialization order issues

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 130 points

    Hi Jagadish,

    That's good to confirm. I suspected as much as that's the normal way, in my experience, to transition between boot & application images.

    It's worth highlighting that the bootloader and application examples available here simply does the function call method, so systemInit() will be called twice.