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

TMS320F28069F: Registers do not update

Joost de Bruin
Prodigy 200 points

Part Number: TMS320F28069F

Something really weird happens while trying to set DCBEVT1, which seems like forgetting EALLOW, but is not. This is the code:

        Uint16 st1 =  GetST1();
        Uint16 WriteIsAllowed = IsRegWriteAllowed();
        DEBUG_ASSERT(WriteIsAllowed);
        BridgePwmRegsPtr[Phase]->TZEINT.bit.DCBEVT1 = 0;
        DEBUG_ASSERT(BridgePwmRegsPtr[Phase]->TZEINT.bit.DCBEVT1 == 0);

Sporadically, DCBEVT1 fails to change to 1 for some reason. With the other code, I am checking if the EALLOW bit in ST1 is set, ie. write protection is disabled (which it is consistently). I also check the EALLOW bit in the debugger when it breaks at the DEBUG_ASSERT. I am at a loss, does anyone know what I am doing wrong here or what kind of H/W or compiler bug could be causing this?

  • 0
    Prodigy 200 points

    I am now suspecting it has to do with the CLA accessing the same registers (although different bits). I have made the CPU wait until the CLA finishes and so far the bug did not occur. Wondering if bit field accesses are atomic for TI compiler.

  • 0 in reply to Joost de Bruin
    TI__Guru* 84910 points

    Joost,

    While the read/modify/write is atomic inside the C28x pipeline sans CLA(instructions past the D2 phase complete), I need to check on the arbitration when C28x/CLA co-exist.  I know that the access won't be lost, rather it will stall. 

    However, as you mention if the C28x reads the register contents and before it can write back the CLA modifies that register then this issue could occur.  In that sense there would be no stall since there is a cycle lag inside the C28x pipeline between the read/write and the CLA gets a free cycle to write to the register as well.

    Let me do a bit more digging, and get a solid reference/answer on the above.  I'll reply back later today.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Guru* 84910 points

    I've included a snippet on CPU/CLA arbitration from the F2806x TRM below as well as linked here. In this case it mentions a CLA write that occurs between a R modify W CPU access, the CLA write could be lost.  In your case, I think it depends on how the compiler has translated your register action from the CPU either to a R mod W or otherwise.  More importantly than atomic here, is that the R mod write isn't done in the same cycle.  

    We could look into the dis-assembly to understand what is exactly happening, but from your debug keeping any writes away from the dual accesses would be the result in any case.  

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Prodigy 200 points

    Thanks. Maybe the CLA reads in the empty in-between cycle, then has a empty cycle for its self in wich the CPU writes, which then gets overwritten by CLA. Anyways, a mutex lock is not a luxury here, and this solves the issue. Maybe I will check the disassembly myself one of these days out of curiosity.