SPI Communication with axiom

[jogender2974]

Dear TouchNetix Team,

I am able to read the data in polling mode from axiom using SPI communication, but overflow bit is set. So I want to read data in interrupt mode.

For interrupt mode, I configured the interrupt pin as input with internal pull up but I am not getting the active low interrupt signal from axiom. Kindly help to get the data through interrupt.

1. What are the hardware dependency for IRQ pin?
2. What will be the communication packets required to send using SPI for getting the reports through interrupt from axiom?

Thanks in advance. Jogender Kumar

[marksat]

Assigned to @Jimmy-Cameron as he is the expert when it comes to the bridge firmware.

From the aXiom's perspective, all that is required from the IRQ pin is an external pullup. Our documentation suggests a value of 1kOhm to 10kOhm is required. What is the value of the internal pull up resistor?

Could you also use a logic analyser or oscilloscope on the IRQ signal to confirm the level please? Could you also confirm the SPI clock speed you are using?

When the IRQ pin is asserted, you need to issue a u34 read as this is where all the reports are generated. It sounds like you are already doing this if you are seeing that the overflow bit is being set. To get the bridge to automatically read reports, the bridge is put into proxy mode, when in proxy mode, I believe this code is run to create the u34 read to get the report contents from the aXiom device.

Best Regards, Mark

[jogender2974]

@marksat

1. IRQ pin external pullup with 3.3K register.
2. SPI speed is 3.5 MHz.
3. IRQ signal level 3.3V.
4. low level trigging used for sense interrupt.

Please suggest how to read touch report on interrupt. if possible share the sample code for the same.

[marksat]

@jogender2974 your setup sounds like it is OK. The part that sounds like it is not working is that the IRQ is not generating interrupts in your system.

Can you confirm the value on the nIRQ signal? If it is low and your system is not performing a u34 read, then that would indicate that the interrupt is not configured correctly. Not all systems support level triggered interrupts on all pins, could you consult with your datasheet to confirm?

You could try to configure the system to use edge triggered interrupts. However, there is the possibility that when your system starts up and configures the interrupt, that it would have already missed the edge. What you would do in this case is is perform a dummy u34 read after configuring the edge triggered interrupt:

void init(void)
{
    status = init_axiom_falling_edge_triggered_interrupt();
    if (status == SUCCESS)
    {
        // Perform dummy u34 read to clear the fifo. This will cause
        // the IRQ signal to deassert (rising edge) and when the next
        // report is ready, IRQ will be asserted (falling edge)
        (void) axiom_read_u34();
    }
}

On our axutils GitHub repo, you can see how we configure interrupts and how the reports are read in the axrpt.py script. The script will only work with interrupts on a RPi. See the main_loop_interrupts function on interrupt configuration. We also perform a dummy read as per my suggestion above.

[jogender2974]

@marksat

Thanks for the prompt reply. We got the solution where we are able to get the each report. Actually we tried 3 ways to read report and we are using method 3. Kindly help us to correct if we need it.

1. Polling method: report missing or overflow issue.
2. Interrupt method: found interrupt continuously in low level when used level triggering or only u01 reports available in edge triggered interrupts while u41 was also enabled.
3. Init the axiom IRQ pin as a GPIO and then polling of IRQ signal. It is working for us. While polling of GPIO, sometimes we are missing the IRQ signal because of some other processes.

As of now we have two queries:

1. Do we need to change this way to read the IRQ report?

Best regards Jogender Kumar

[Jimmy-Cameron]

Hi @jogender2974 I'll jump in here,

The method you have gone with is the one we would have suggested to use so I see no problems there. In fact that is the exact method that the AXPB009 uses; each time the main loop is executed it will check the state of the IRQ signal and read a report if it is asserted.

The AXPB009 has relatively few tasks to complete for every iteration of the main loop. If your application regularly performs some time intensive processing, it is very likely that for any given usage a new report will be created before the previous one has been read. This will lead to the report becoming stale and the overflow flag being set. This scenario is much more likely to happen in a single threaded application, if your device is using an RTOS I would expect the frequency of this issue to be reduced.

I think the approach you have chosen is acceptable. If you are unable to read the reports from aXiom at a sufficient rate, you could disable some reports that you do not require. This would save you wasting time reading a report just to disregard it straight away.

[jogender2974]

@Jimmy-Cameron

Thanks for your valuable response.

I have one more query if we sense the interrupt in low level triggering( "as suggested in document ") the nIRQ signal continuously asserted low for longer durations.

We captured in logic analyzer and found that pin was continuously low for more than 1s or even sometimes 35s also observed and was getting only u01 reports while u41 also enable.

Best Regards Jogender Kumar

[marksat]

@jogender2974 feel free to share your logic captures with us as we will have a look. If the nIRQ signal is constantly low, it would indicate that there are more reports to be read.

What interval period do you have configured for your u01 reports? We typically configure u01 reports for 1 per second, but this can be configured to go slower or as fast as once per 100ms.