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.

TM4C123GH6PM: Bit-banding - atomic or read-modify-write?

Part Number: TM4C123GH6PM

I am confused about whether bit-banding is atomic or not. There seems to be some contradictory information on the forums, with some posts saying it is atomic, others saying it is not.

For example this thread indicates bit-banding is atomic:

e2e.ti.com/.../1307944

But this thread indicates that bit-banding performs a read-modify-write:

e2e.ti.com/.../161532

I need to implement a "bit array." Normally that is very simple, but in this case, the bit array can be read and written from main code and interrupts, so is subject to corruption: if code that writes a bit is interrupted after the read but before the write by other code that writes a different bit in the same word, the change to that different bit will be lost when the earlier code resumes.

According to posts elsewhere on e2e, bit-banding is supposedly atomic, in which case bit-banding could be used to solve that corruption issue. But according to posts in this thread, bit-banding performs a read-modify-write, which indicates that it may be corruptible -- unless the entire read-modify-write operation is uninterruptible or there is some other CPU mechanism by which the operation is cancelled and restarted if interrupted (in the same way that a time-consuming DIV operation can be cancelled and restarted in some CPU platforms, to reduce interrupt latency).

So, it is very important that I understand whether bit-banding is atomic or not. If multiple threads or interrupt handlers access different bits in the same word by means of bit-banding, can such corruption occur?

Of course, I am interested in other suggestions to solve this issue.

Thanks

  • twelve12pm said:

    I am confused about whether bit-banding is atomic or not. There seems to be some contradictory information on the forums, with some posts saying it is atomic, others saying it is not.

    For example this thread indicates bit-banding is atomic:

    e2e.ti.com/.../1307944

    But this thread indicates that bit-banding performs a read-modify-write:

    e2e.ti.com/.../161532

    That is not a contradiction. Bit banding is of necessity a RMW instruction (short of implementing bit addressable memory which would explode the size of the die and mean bit banding could not be used with external memory or peripherals). That does not mean it cannot be atomic. Many processors have atomic RMW instructions (the 8096 family had many such).

    twelve12pm said:
    Normally that is very simple, but in this case, the bit array can be read and written from main code and interrupts, so is subject to corruption: if code that writes a bit is interrupted after the read but before the write by other code that writes a different bit in the same word, the change to that different bit will be lost when the earlier code resumes.

    Even w/o bit banding being atomic that's not a difficult issue to solve. What do you do if you need atomic access to an array of integers (ie several values must be changed at once)?

    Robert

  • The About bit-banding section of the ARM® Cortex®‑M4 Processor Technical Reference Manual says the a write to to a bit-band region is an atomic read-modify-write operation.

    I assume that the ARM documentation is the authoritative source of information. 

  • Robert Adsett said:
    twelve12pm
    Normally that is very simple, but in this case, the bit array can be read and written from main code and interrupts, so is subject to corruption: if code that writes a bit is interrupted after the read but before the write by other code that writes a different bit in the same word, the change to that different bit will be lost when the earlier code resumes.

    These options:

    1. Use atomic operations.
    2. Lockless algorithms. Hardest to implement, easiest to mess up, but best performing.
    3. Platform-specific synchronization primitives.
    4. Software synchronization primitives.
    5. The big hammer approach: Pause all interrupts.

    I'd prefer to use atomic operations, hence this question. Thank you for explaining that the read-modify-write does not contradict the atomicity of the bit band operation.

    If all else fails I can pause interrupts, but I need to avoid that wherever possible.

    As for platform-specific synchronization primitives, TM4C has the Load-Exclusive / Store-Exclusive -- I've been looking through TivaWare for a compiler-portable implementation (macros, functions, etc). Next up is to check compiler documentation for intrinsics, but we have to support GCC as well as the TI compiler.