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.

TMS320DM8148: Cortex M3: Using LDREX/STREX instructions on dual Cortex-M3?

Part Number: TMS320DM8148
Other Parts Discussed in Thread: SYSBIOS

Team,

The below E2E post does mention that LDREX/STREX can not be used on dual Cortex-M3/M4 sub-system (IPUs) on multi-core parts like Jacinto 6:
https://e2e.ti.com/support/embedded/tirtos/f/355/t/541932 :

Could you please confirm if it is the case for DM812x/DM814x and DM38x as well?

Thanks in advance,

Anthony

  • Hi,
    Jacinto has two Dual core Cortex M4 IPUs and SYSBIOS runs in SMP mode in each IPU. Whereas DM38x has single Dual Core Cortex M3 subsystem. In IPNC RDK, two SYSBIOS instances are running on each core in Non-SMP mode.
    On which SDK are you trying to use these instructions?
  • Hi Anuj,

    What SDK SW is being used is not a concern for now. The question is really about the MCU instruction set being supported.

    Assuming for example bare metal code: Does the M3 support the LDREX/STREX instructions? Can it create a problem if CPU execute those instructions?

    Thanks in advance,

    Anthony

  • Hi Anthony,

    You should check Cortex-M3 ARM TRM. You can get it from arm.com.

    See also the below wiki:

    processors.wiki.ti.com/.../Cortex_M3

    Regards,
    Pavel
  • Hi Pavel,

    We we're the ones initially asking Anthony about this issue we're having.

    We have a custom OS running on a single Cortex M3 out of the dual so we don't use the second M3.
    We share source code between our A8 and M3 which is compiled with GCC and C++11. For this we use the ARM
    GCC M3 compiler and a Linaro GCC A8 compiler. Both versions are GCC 6.x. For the A8 this works great
    but, for the M3 not so much. The thing is that the standard requires atomic operations since C++11,
    for instance in std::set_new_handler. This will generate a LDREX/STREX pair to atomically set the handler
    (this is by the way just one example, but the std::atomics will also use these instructions which the compiler
    will generate).

    From the M3 reference manual we know these instructions are supported, I'll get back to that in a minute.

    What we see happening is that we get a hard fault when this pair is ran and we can't figure out why this
    happens.

    Back to the manual. It states that for the LDREX/STREX instructions to work there is a local exclusive monitor
    and optional, depending on the flags for the memory region, a global exclusive monitor.

    On this forum we have read that a global monitor is not implemented since TI uses the spinlock/mailbox
    components for syncing between the various cores (DSP, M3's, and A8). But according to the ARM reference
    manual this does not seem the be required since a local exclusive monitor should be present in arm M3/M4 cores.

    To validate this we did a test with the LDREX/STREX pair on a memory location internal to the Cortex M3, so it should
    use the local exclusive monitor, on 0xE0000000. As we believed how it should work, it did at this location since the
    address is only visible to the M3 and no global access is required. We didn’t get a hard fault and no infinite spinning
    so the local monitor is there.

    We do use the L1 cache and programmed the shared cache MMU. We map physical address directly visible to the
    M3 (a one to one relation). We also played a bit with the flags for a page, to no avail.

    The manuals seem to contradict each other a bit on the part and some mention that the region must be marked as
    non sharable. But another manual states that the M3/M4 has simple monitoring hardware and thus does not use
    the flags.

    So our questions:

    1. is there a way to flag the memory regions as internal use e.g. local exclusive (as seen from the M3's perspective).
    2. Why do these instructions generate a hardfault on non internal addresses (as seen from the M3's perspective).
    3. Can we make this work somehow?

    Regards,
    Robert