This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Ultrasonic sensor code not working when building for thingy91_nrf9160ns

Hello,

I am experiencing a weird issue with a code which I wrote for my ultrasonic distance measurement sensor for Thingy91. The code works fine and gives measurement values when I build for thingy91_nrf9160 but it doesn't work when I build for thingy91_nrf9160ns and distance measurement always comes out to be 0.

I am linking the datasheet of the sensor as it explains the operating principle of the sensor: https://www.makerguides.com/wp-content/uploads/2019/02/JSN-SR04T-Datasheet.pdf . I am using it in Mode 1.

I can see the sensor LED blinking which means that sensor is being triggered correctly so I think the problem arises when we try to calculate the time for which the sensor response remains high. This is done using GPIOTE events, Timer and Interrupt.

I am attaching the code so can anyone, please, take a look and see what aspects of it might not be working when I build for thingy91_nrf9160ns.

Thank you.

2438.ultrasonic_sensor.rar

Parents
  • Are you using NCS v1.4.0?

    In order to use GPIOTE in a nonsecure application, you have to use GPIOTE1, and not GPIOTE0. Check out nRF9160 GPIOTE Register in the infocenter Thus, NRF_GPIOTE should get mapped to NRF_GPIOTE1. Could you test one thing?

    Could you modify these lines in the following manner: 

    #if defined(NRF_TRUSTZONE_NONSECURE)
    # error ------------------>NRF_GPIOTE1 is used<------------------
    #define NRF_GPIOTE       NRF_GPIOTE1
    #else
    # error ------------------>NRF_GPIOTE0 is used<------------------
    #define NRF_GPIOTE       NRF_GPIOTE0
    #endif

    Then rebuild and see what message is printed. I you're using SES, you could also open ncs\v1.4.0\modules\hal\nordic\nrfx\drivers\src\nrfx_gpiote.c and click on the definition of NRF_GPIOTE.

    Could you also check if NRF_GPIOTE1 is correctly configure to the nonsecure domain by SPM? that is done by checking the log that shows up before the main application. The line "24 NRF_GPIOTE1        Non-Secure OK"  should get printed:

    *** Booting Zephyr OS build v2.4.0-ncs1 ***
    Flash regions Domain Permissions

    .

    .

    24 NRF_GPIOTE1 Non-Secure OK

    .

    .

    SPM: prepare to jump to Non-Secure image.
    *** Booting Zephyr OS build v2.4.0-ncs1 *

    Best regards,

    Simon

  • Thank you for your response.

    Yes, I am on NCS v1.4.0. 

    Following your instructions, I modified the lines here and got following response when building:

    Also, I can see "24 NRF_GPIOTE1        Non-Secure OK" 

    So, what should I change to make that sample work using GPIOTE1? Thank you.

    Regards,

    Haris Ahmed

  • I tested the sample zephyr/samples/boards/nrf/nrfx/ (which uses GPIOTE) with the thingy91_nrf9160ns and it worked perfectly. The LED on the Thingy:91 toggled when the button was pressed.

    Try to get that sample to work and use it as a reference on how to do it in your own sample.

    Best regards,

    Simon

  • Hi again,

    1. The sample works for me on Thingy 91 in thingy91_nrf9160ns and I am able to use it for my code which I posted above.

    2. In terms of GPIOTE configuration, the only difference I can see between my code and this sample was in the GPIOTE interrupts setup. In the sample you posted, I can see the following lines for interrupt setup:

    /* Connect GPIOTE_0 IRQ to nrfx_gpiote_irq_handler */
    	IRQ_CONNECT(DT_IRQN(DT_NODELABEL(gpiote)),
    		    DT_IRQ(DT_NODELABEL(gpiote), priority),
    		    nrfx_isr, nrfx_gpiote_irq_handler, 0);

    In my code, I am doing as shown below. I am not using DPPI so I am enabling the interrupt as well.

    IRQ_DIRECT_CONNECT(GPIOTE0_IRQn, 0, nrfx_gpiote_irq_handler, 0);
    irq_enable(GPIOTE0_IRQn);

    By trying the approach from the sample you posted for setting up interrupt, I got my sample to work.

    But, when the same thing I try to integrate in "Cloud_Client" sample (which is the point to run in thingy91_nrf9160ns as I want to send sensor values to the cloud), I get the following error:

    Building ‘zephyr/isr_tables.c’ from solution ‘build’ in configuration ‘Common’
      Combining ‘zephyr/isr_tables.c’
        multiple registrations at table_index 49 for irq 49 (0x31)
    Build failed

    I disable Zephyr GPIO as well but still there are conflicts with interrupts. Can you please check my 7522.cloud_client.rar project  configuration and code and check where might be conflicts?

    Thank you.

    Regards, 

    Haris Ahmed

Reply
  • Hi again,

    1. The sample works for me on Thingy 91 in thingy91_nrf9160ns and I am able to use it for my code which I posted above.

    2. In terms of GPIOTE configuration, the only difference I can see between my code and this sample was in the GPIOTE interrupts setup. In the sample you posted, I can see the following lines for interrupt setup:

    /* Connect GPIOTE_0 IRQ to nrfx_gpiote_irq_handler */
    	IRQ_CONNECT(DT_IRQN(DT_NODELABEL(gpiote)),
    		    DT_IRQ(DT_NODELABEL(gpiote), priority),
    		    nrfx_isr, nrfx_gpiote_irq_handler, 0);

    In my code, I am doing as shown below. I am not using DPPI so I am enabling the interrupt as well.

    IRQ_DIRECT_CONNECT(GPIOTE0_IRQn, 0, nrfx_gpiote_irq_handler, 0);
    irq_enable(GPIOTE0_IRQn);

    By trying the approach from the sample you posted for setting up interrupt, I got my sample to work.

    But, when the same thing I try to integrate in "Cloud_Client" sample (which is the point to run in thingy91_nrf9160ns as I want to send sensor values to the cloud), I get the following error:

    Building ‘zephyr/isr_tables.c’ from solution ‘build’ in configuration ‘Common’
      Combining ‘zephyr/isr_tables.c’
        multiple registrations at table_index 49 for irq 49 (0x31)
    Build failed

    I disable Zephyr GPIO as well but still there are conflicts with interrupts. Can you please check my 7522.cloud_client.rar project  configuration and code and check where might be conflicts?

    Thank you.

    Regards, 

    Haris Ahmed

Children
  • I looked into this and got the same error as you when running the cloud_client sample, however I was not able to figure out what caused the error.  It seems like IRQ_CONNECT(<GPIOTE1 line number>,.....) is called twice somehow.

    Could you try to strip down the cloud_client gradually, by removing one config, one line of code at the time until it looks like the sample zephyr/samples/boards/nrf/nrfx/. Rebuild it every time you remove a part and check if it works. In this way you will be able to locate exactly what's causing the error.

    You could do it in the opposite way as well. Start with zephyr/samples/boards/nrf/nrfx/ and add one config/dts-field/line of c-code, until it looks like the cloud_client.

    Best regards,

    Simon

  • Hi Simon,

    Thank you for your suggestions. I actually found the solution to the problem by making following changes in the code. I replaced:

    IRQ_CONNECT(DT_IRQN(DT_NODELABEL(gpiote)),
    				DT_IRQ(DT_NODELABEL(gpiote), priority),
    				nrfx_isr, nrfx_gpiote_irq_handler, 0);

    with:

    IRQ_DIRECT_CONNECT(GPIOTE1_IRQn, 0, nrfx_gpiote_irq_handler, 0);

    and everything worked. GPIOTE1 is working in thingy91_nrf9160ns now.

    Regards,

    Haris Ahmed

Related