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

[FAQ] How to avoid crashing the DM R5F when writing custom DM R5F firmware

Nick Saulnier
Guru** 101180 points

Parts Discussed in Thread: AM62x, AM62Ax, AM62Dx, AM62Px

The primary role of the Device Management (DM) R5F core is to run the DM task. However, on some devices (not all devices!), TI supports writing custom code to run on the DM R5F, alongside the DM task.

Non-DM code running on the DM R5F should not interfere with the DM task in any way. That means the non-DM task should not crash the DM R5F core, block the DM task from running, corrupt DM memory, etc. If the DM task crashes, device management (DM) and power management (PM) requests fail. This can render the device inoperable until a power cycle resets the DM R5F.

These are best practices for customers who are writing custom code to run on the DM R5F.

Other resources

This information is planned to be added to the MCU+ SDK documentation under Developer Guides > Developing applications on Device Manager/Wake-up R5 core. Once the documentation has been updated, we will update this FAQ with links.

This is a helper FAQ for  RE: [FAQ] DM R5F can crash in certain conditions: AM62x, AM62Ax, AM62Dx, AM62Px, AM67, AM67A  question "We are writing custom DM R5F firmware. Could our design be affected?"

  • +1
    TI__Guru** 101180 points

    non-DM code should not crash the DM R5F core

    Here is one example of how non-DM code could crash the DM R5F core in SDK 11.1 and earlier:

    The function DebugP_assert() is used to freeze the operation of a core and preserve the state when an error is detected. However, that means that DebugP_assert() halts the entire DM R5F core, including the DM task. In most situations, for non-DM tasks, we suggest using different error handling mechanisms other than DebugP_assert().

  • +1
    TI__Guru** 101180 points

    non-DM code should not block the DM task from running

    The DM task should always be the highest priority task running on the DM R5F. That ensures that other tasks cannot block the DM task from running with while() loops, if() conditions, etc.

  • +1
    TI__Guru** 101180 points

    non-DM code should not corrupt the DM memory

    Static analysis tools and other methods can be used to catch potential memory issues.

  • +1
    TI__Guru** 101180 points

    System recovery

    If you are programming the DM R5F, it is suggested to add a way for the system to recover if the DM R5F locks up or otherwise enters a bad state. Remember that if the DM task is non-functional, code that is normally used for recovery may not work (e.g., the Linux shutdown command). The DM R5F watchdog timer is one recovery tool. There is a watchdog example in the MCU+ SDK at examples/drivers/watchdog/watchdog_interrupt