Other Parts Discussed in Thread: HALCOGEN
Hello,
We are having another N2HET related problem which can be reproduced with TMDSRM48HDK kit (S2 switches all OFF). We have exactly similar issued with our new HW where one pin was changed from GPIO port to HET1 pin 27. NOTE: edge (pin up state) is long enough HET to detect it in real hw, we have redundant feature where other pin is (and has been there already in previous HW) connected to HET 1_14 pin and it gives IRQs without problems and 1_27 doesn't give when old HW gpio-port worked without problems. Initially though this to be circuit board issue in new HW but since DIN shows the pin state correctly the connection is good.
See attached project. If you run it with "#define TEST_PIN26 1" (line 132) - rising edge to pin26 is made - the HET detects edges also in pin 27 (see 'au32HetIrqs' content when while(1) reached). If you run it with "#define TEST_PIN26 0" - rising edge to pin 27 is made - the HET does not detect any edges.
DIN shows that targeted pin has really gone up and others are down... In this demo we just control that pin by ourselves which het monitors but in real life we have real input source connected to that pin and have exactly same problems (controlling itself works as well since input is monitored), HET doesn't signal IRQ when monitored pin 27 goes up and if we control out pin26 (which is output in real life for something completely separate thing) the IRQ will be generated also to pin 27....
HET 1_27 pin is a bit special it has direct ball A9 and muxable ball B2 (well mux is not directing B2 to HET), similarly has HET 1_29 (A3 & C3) and HET 1_31 (J17 & W9) pins. The common for all these was that IRQ is not signalled if A9, A3 or J17 goes up. Didn't test to control 1_28 or 1_30 if these generates irqs to 1_29 & 1_31 like 1_26 generates to 1_27. Also 17, 19, 21, 23 and 25 have similar 2 pin connection possibility but haven't tested those...
Could find anything from TRM nor data sheet that those pins/het ports are "special" and they should be used differently... I understand that some problems may occur if muxable pins are also routed to HET but that should be the case in the demo nor in our real hw, only the fixed pin should go to the HET.
Errata mentions some problems with PCNT when measuring the pulse lengths, since HR is not used at all and only IRQ is wanted those errata findings should not have any effect (and demo application fails similarly also if PCNT's are removed completely from het code & application side)...
We have tried both ECNT and PCNT HET instructions to give IRQs in rising edge but both works similarly, in the demo project both are used simultaneously and all irq's are counted together and also separately per offset to verify that irq count read from array slots via debugger matches total count. I also put "dummy" delay after irq enable and before edge generation to be sure that if code is stopped before edge making the HET have had enough time to run 1 round (this should be useless, but it is there just in case).
Can you find some errors from code? Or is those ... 27, 29,31 het pins somehow special and cannot be used as we would like to use? Why edge in pin26 is catched by het-code in monitoring instruction for pin27 when DIN shows that pin27 is down and 26 is up...
Here is the project which re-produces the situation (again tested with 2 HDKs, 2 different computers & geographic location), all "application" code is in sys_main.c. Application just intializes het, enables IRQ, puts pins 26&27 down, enables HET IRQs (clears possible pending irq from that offset)) for targeted offset lines and then makes rising edge to either pin 26 or 27.
8875.N2HET_irq_problem.zip
