MSPM0G3507: Hall Input Mode with XOR

I'm not familiar with Hall Mode, but I encountered something similar implementing Period/Duty capture.

GPIO is its own Programmed Function (PF=1), so if you set a different PF the state of the pad is no longer reflected in the GPIO registers. I set my capture input channel for Both Edges, but then observed that my ISR couldn't tell which edge had triggered.

The solution was to tie channels 0 and 1 together (same input pin -- IFCTL:ISEL=2 as I recall) then configure one of the channels for Rising and the other Falling. Then I could distinguish based on which channel triggered.

I don't know much about sysconfig, but I suppose there's a way to request this.

Hi Bruce,

I think this is a good solution for ONE digital input signal to measure the time between two edges and get the correct input value. However, in the Hall Input Mode three digital inputs are combined with an XOR to one signal. In order to determine the state of all three signals reading of the GPIO input seems to be necessary in the ISR ... but as you described this isn't possible if the Programmed Function is different from GPIO (PF not 1). Because this is a special mode for three digital hall inputs, I assume there should be a solution. By the way, which low level driver mode did you use to trigger for both edges. All modes I found were either for rising or falling edges only (e.g. DL_TIMER_CAPTURE_EDGE_DETECTION_MODE).

Thanks a lot, Daniel

1) I see what you mean: It appears they left "_BOTH"=3 out of enum DL_TIMER_CAPTURE_EDGE_DETECTION_MODE. (Maybe they thought it wasn't useful given the PF thing?) I didn't use driverlib, I just stuffed the register directly.

2) It looks like the analogous usage for XOR mode would be to set the ISEL for both channels to XOR (IFCTL[0].ISEL = IFCTL[1].ISEL = 4). This would allow you to see both edges based on which channel triggers. The relevant function seems to be DL_Timer_setCaptureCompareInput(<Timer>, 0, DL_TIMER_CC_IN_SEL_CCP_XOR  , [0 then 1]).

3) I don't see any provision for looking at the 3x pins individually, since it seems that the timer combines them before you can see them [Fig 25-21]. In the extreme, I suppose you can re-write the IOMUX with PF=1, look, then set the PF back. (It looks cumbersome, but it's only two register writes -- set then restore -- for each pin.)

But I defer to you on how all this stuff is/should actually be used.

2) Knowing the 3x hall input state is crucial for me. You described a method to get the input state without reading the GPIO pins. I think it's difficult to extract the state of the 3x hall inputs out of the XOR input.

3) I implemented your proposed solution and switched to the GPIO module (PF=1) and back again in the ISR. It basically worked, but when I switched back there where already undesired capture events set. Therefore I'm not sure if this is the way to go. I'm a little bit suspicious regarding this solution. Can you explain what happens when peripheral modules are switched with the IOMUX. Is there a reset of some registers?

4) Another question came up when I tried to continously measure the time between two input edges of the XOR. Is it correct that capturing a value (CCOND) and reloding the timer (LCOND) isn't possible at the same edge (in hardware) and a manual reload of the timer value is needed in the ISR. In the example timx_timer_mode_capture_duty_and_period it's written: Manual reload is needed to workaround timer capture limitation.

5) I had a look at the motor_control_bldc_sensored_trap_hall example. As far as I understand the time measurement is done with only one input signal and the XOR is not used. Is there a sample code available to show the usage of the Hall 3-input XOR as described at the figure 25-21 in the ref. manual?

2) I was trying to describe how the designers (apparently) imagined using this mode. I didn't find any way (via the timer) to read the state of the pin(s) -- in particular, I don't see even an inference method for the IDX pin -- so I suppose the designers didn't anticipate a need for it. [I don't know one way or the other.]

3) It may be that disconnecting/reconnecting the pin to the timer causes the timer to see a glitch on its internal signal. [There's also a race, but I suppose you've accounted for that.] So maybe that method doesn't work for this case. (But see (6) below.) [Edit: I know you weren't wondering, but I was: I inserted an IOMUX swap in/out into one of my capture programs, and sure enough every so often I see a glitch (false capture). Thanks for noticing this.]

4) The TRM treats XOR mode as a special case of capture, and points off to the period/duty use cases. Those work by using a ZCOND to re-load the counter, so the result is a 0-based time delta (which is convenient). Unfortunately, that feature doesn't work [Ref Erratum TIMER_ERR_01]. The workaround is to subtract successive capture values (the way we always did it). I personally don't recommend doing an explicit re-load the way the Example does it, since I'm pretty sure there's some intrinsic latency/inaccuracy.

5) I skimmed around the other day, and didn't find an XOR example. The trap_hall example appears to synthesize the input using GPIO interrupts/polling. 

6) Another angle might be reading the (digital) pin(s) using Analog -- either the ADC or the Comparators. [Ref TRM Sec 8.1.1 ]That would give you two different paths to the pin(s).