• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 571 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/RM48L952: HET Timer data synchronization

Mux
Intellectual 620 points
Part Number: RM48L952

Tool/software: Code Composer Studio

Hello,

I have a question regarding the PCNT instruction which can be used to measure the counts between rising edges (RISE2RISE, etc). For me it is clear how to interpret the data or how to catch it vial the application from the host side, but is there any mechanism in order to have valid data only at the end of the measured period which can be accessed by the host cpu because the host cpu could easily read the data field of the PCNT instruction at any time while the counting is still ongoing. In other words, the read data by the host cpu is invalid then.

SInce an event of a rising edge to another rising edge can be seen as one complete period, my solution is to add an additional branch instruction (BR) after the PCNT instruction which will conditionally jump to the next location when a "RISE" event occurred. After that I have to abuse the MOV32 instruction in order to load from the remote data field (which is in this case the PCNT instruction to get a valid value after one period) to a register and then to move that data content to another dummy remote instruction with another MOV32 instruction which will hold the valid data. 

I would like to know whether another approach exist or you could provide some further feedback. I am a little bit scared about the loop resolution as well as the time slots as the MOV32 instructions can eat up to 2 cycles and we are talking right now just about one PCNT instruction. I could also imagine that I am interested to have valid data from a PCNT rising edge to falling edge.

  • 0
    TI__Guru**** 193006 points
    Hello Mux,

    PCNT captures the counter value into the period/pulse data field on the selected edge (2nd rise). The data field will be updated at next capture edge.

    The N2HET provides a feature allowing to automatically clear the data field immediately after the data field is read by the external host CPU (or DMA). This feature is implemented via the control bit (C26). If PCNT is configured for automatic read clear, then when the host CPU reads the PCNT data field it will be cleared automatically. If the data field were not cleared, it would be impossible for the host CPU to determine whether the data field holds data from the previous capture event, or if it happens to be data from a new capture event with the same value.

    You can use MOV32 to copy the data field of PCNT to MOV32 data field at rising edge (BR). I don't see the advantage to do so.
  • 0 in reply to QJ Wang
    Intellectual 620 points
    Hello QJ,
    thanks for the reply. I was wondering regarding the functionality of the control field as for the simulator IDE, I was not able to trigger anything. But now I see its real functionality. I have one question regarding the PCNT instruction as I don't understand the period field when you read a signal on the simulator which is not defined via external stimulator. When I debug I see the period value counting upwards and downwards. What's the purpose for this as I only see the data field to be valid right now when I put a trigger on it
  • 0 in reply to Mux
    TI__Guru**** 193006 points
    Hello,

    PCNT detects the edges of the input signal at loop start and measures its period. The Period count is increased each N2HET loop.

    The Data field is the last captured counter value (period count).
  • 0 in reply to QJ Wang
    Intellectual 620 points
    Hello thanks for the feedback,
    sry for the late answer. I have a open question regarding the het program. Is it possible to copy several portions of het program instructions at different time points. For example at the beginning i will copy a het program providing only the pwm functionalities. Later during execution of the runtime new instructions are copied into the hetprogram and added to the already running program which will extent the hetprogram taking the available time slots into account. Right now the examples show that the whole program is copied with the memcpy into the het ram once and is executing in the background. When does the changes take place when the host cpu is reconfiguring the program field in order to specify a different adress. do i need to expect consistency issues when performing such reprogramming patterns while the het program is running and probably fetching the next instruction adress.
  • 0 in reply to QJ Wang
    Intellectual 620 points

    See question above as I am facing sometimes the problem that different paths based on the conditional jump adress are performed and I am actually able to see data on the Het RAM where it should not be the case because the specific path should not be executed. I have performed several tests with the HET IDE, but I have the impression when directly manipulating the address on the RM48 target in order to modify the program flow of the het program, then I can see some leakage / inconsistencies regarding data read on the pin. For example there could be a conditional jump just to measure the period or to count the falling edges. It is not needed to perform both actions at the same time. So there will be a input in the main.c in order to change the conditional jump adress (e.g. Control field). When doing so, there is a small amount of time where I can see activities on both het program paths although only one should be activated on the target when looking into the Het RAM data adressess

  • 0 in reply to Mux
    TI__Guru**** 193006 points
    Hello Mux,

    Some instructions (MOV32, MOV64, ADM32, ...) can modify the data fields of other instructions. This feature enables the N2HET program to implement double buffering on capture and compare functions. For example, an ECMP compare instruction can be followed by a MOV32 instruction that is conditionally executed when the ECMP instruction matches. The host CPU can update the next compare value by writing asynchronously to the data field of the MOV32 instruction instead of writing directly to the data field of the ECMP instruction. The copy from the buffer (MOV32 data field) to the compare register (ECMP data field) will occur when the MOV32 instruction is actually executed which occurs after the ECMP instruction matches its current compare value. This is the same behavior as one would expect from a double buffered
    hardware compare register.