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.

Atomic TAS implementation for TMS570LS3137

Other Parts Discussed in Thread: HALCOGEN

Hi all,

I'm new to embedded work with ARM and TI's toolchain. I'm looking to implement or reuse an implementation of semaphores for the TMS570 with atomicity guarantees. I couldn't find any existing headers, and I'd rather not invest a ton of time in working up a formal model of the processor to verify my hand-written assembly if I don't have to.


Where can I find such a library? Is there one already available for this platform, and if so how could I have found it for myself? If I absolutely have to roll my own what's the best way to validate it?

  • Chris,

    The CPU has special instructions for atomicity.   Look at LDREX, STREX.

    See the section "8.6. Internal exclusive monitor" in the CPU TRM from ARM,

    and the architecture manual for more details on how to use these instructions.

    -Anthony

  • Hi Anthony,

    thanks for your prompt reply! I have actually looked through both of those documents, and found and adapted an implementation of TAS from the Qt core libraries that I /think/ should work. I don't trust my implementation, though, so I was hoping to find either a) a verified standard library for ARMv7-A or ARMv7-R, maybe from an RTOS framework, b) a kit or method or /something/ to verify my implementation. Doing concurrency right is hard, so I'm erring on the side of paranoia.
  • Hi Chris,

    There's also an application note: infocenter.arm.com/.../DHT0008A_arm_synchronization_primitives.pdf

    it includes some concrete examples - one is semaphore. Sorry I thought these were in the architecture manual.

    -Anthony
  • Perfect, precisely what I needed. Thanks!

  • Be advised: To avoid the ABA problem on the ARM local exclusive monitor, the task->task context swap code must execute a "clrex" instruction.  TI's FreeRTOS port does not do this.

  • Hi Jonathan,

    Thanks for this tip.   If you have time, we've got some questions.    I had to lookup the "ABA" problem, since I wasn't familiar.  Relying on a description from Wikipedia.    Seems like the issue is not being able to detect when some code changes a location from A to B then back to A.

    But my understanding of LDREX / STREX is that it's got no dependence upon the actual data value being read/written, from the architecture manual description:

    "• The Load-Exclusive instruction reads a value from memory address x.

    • The corresponding Store-Exclusive instruction succeeds in writing back to memory address x only if

    no other observer, process, or thread has performed a more recent store of address x. The

    Store-Exclusive operation returns a status bit that indicates whether the memory write succeeded."

    Wouldn't this make the exclusive access immune to such issues?   

    Anyway - this is interesting - so thanks again for posting.  If you've got the time would be great to hear more explanation from someone who understands the very tricky details.

  • LL/SC based machines are not susceptible to the ABA problem on the memory read and written to. However, the ARM local exclusive monitor itself is susceptible[1]. That's why you need CLREX in the context switch code.

    [1] The Cortex-R5 TRM specifies that this processor's local exclusive monitor does not perform address tagging, only a one-bit state machine.
  • Thanks Jonathan - You're absolutely right and thank you for the explanation.

    I was confused because we actually built a single address tag per CPU into the L2 RAM on the Cached Hercules products - as well as logic that invalidates one or both tags on a STREX from any CPU - in case we ever release an unlocked / dual core Cortex R5 device. But even then we'd need CLREX for two tasks running on the same CPU given the CPU implementation.

    Sounds like this should be put as a ticket against HalCoGen's FreeRTOS port.

    Thanks and Best Regards,
    Anthony
  • Hi Jonathan,

    I put this spreadsheet together to show possible sequences, one with and one without CLREX.

    Seems to me that without the CLREX, the issue maybe more extensive than the value being changed and then changed back...  it looks like even a value that's changed could go undetected without CLREX during the context switch (simpler case).   Also looks like it wouldn't matter much in the single core case if the exclusive monitor tagged the address or not.

    Thought I'd run this by you before submitting a bug report.  Would probably attach this to the bug report for explanation purposes.  It's an XLS worksheet with two sequences on it, one without CLREX showing a problem, and one with CLREX inserted showing how the correct result is obtained.

    7853.sequences.xlsx

    Thanks and Best Regards,

    Anthony

  • Yes, that's exactly right.  The ABA problem on the exclusive monitor does have broader impact that the "classical" version of this problem which a native CAS machine like x86 would suffer.

    If it makes you feel any better (or worse!), the upstream FreeRTOS ports to ARMv7-A and ARMv7-R suffer from the same problem.