nRF9160 GPIO problem on custom board

[DavidKaplan]

Shalom!

We have a nRF9160 custom board on which I cannot switch some of the IO lines.

For example we have two leds, P0.9 an P.10 but only P0.9 works. The hardware guy reports the P0.10 output does not change when I toggle the output while debugging. I tried moving the led to P0.30 & P0.31 also without success. Also I need to change a uart1's rx and tx lines in some scenarios when it is not used. In this case I do not call uart_dev = device_get_binding("UART_1"), but want to just clear both lines. I am evidently doing something wrong or missing something. The gpio APIs all report no errors and in the debugger I see that the pin numbers are correct.

Isn't the uart initialed by Zepyr only on calling its binding? I need to change IO on the fly to save power of course. I am new to Zephyr. I have all of the pins I plan to manipulate defined in the board's dts file in the zephyr\boards directory. Can I switch pins that are not in this file? Do I need to add something to my ns overlay? I do not know why P0.9 works but P0.10 does not if it is a security error.

I have a project\child_image\spm\prj.conf file which have a CONFIG_GPIO define. I tried changing it but it does not help. Maybe this is just for the bootloader?

Is there a way in the SES IDE to see the GPIO status at a breakpoint or single stepping? Most IDEs have this option. I am using v1.6.0.

nrf9160axion_nrf9160_common.dtsnrf9160axion_nrf9160ns.overlay

Thanks David

[Sebastiaan Merckx]

Hi,

Are you using the same device tree for your application as for the SPM? I had issues where the SPM was still using UART1's pins 0,1,1e,1f, even though UART1 was overlayed with 'disabled' in the application device tree. I did not apply the same change to the SPM device tree.

[DavidKaplan]

I have an integration tomorrow if nothing goes wrong that I will check it again hopefully.

This morning on our hardware guy's virgin board (Microsoft Meeting), we could now switch P0.10 but still not P0.30 & P0.31.

I am using v1.6.0 and have board conf and overlay files in  C:\ncs\v1.6.0\nrf\samples\spm\boards.

Where should I put the overlay and conf?

Thanks David

 

[DavidKaplan]

Here is a list of my open problems that I need help on. When I previously tried to open a post for each subject the forum did not handle it well, only the last post.

I am using the latest v1.6.1 IDE.

1) IO pins P0.30 P.31 I still cannot switch.
  I Duplicated the nrf9160dk_nrf9160 under a new name and changed things to our custom hardware.

  I select this new board from the SES make menu.
  P0.30 & P0.31 do not appear anywhere in the folder but it seems like a conflict somewhere.

  Perhaps they appear in the bootloader?

  In the C:\ncs\v1.6.1\bootloader\mcuboot\boot\zephyr\boards directory I put a board.overlay file and a board.conf file. Maybe I do not need them or have the definitions wrong.

  The board.overlay file has only uart0's definition.
       &uart0 {
        status = "okay";
        tx-pin = <1>;
        rx-pin = <0>;
        rts-pin = <0xFFFFFFFF>;
        cts-pin = <0xFFFFFFFF>;

        spm_uart: nrf-spm-uart {
            compatible = "nordic,nrf-spm-uart";
            status = "okay";
            label = "SPM_UART";
        };
    };

  The board board.conf file:
  # Disable Zephyr console
    CONFIG_CONSOLE=n
    CONFIG_CONSOLE_HANDLER=n
    CONFIG_UART_CONSOLE=n
    # Multithreading
    CONFIG_MULTITHREADING=y
    # MCUBoot settings
    #CONFIG_BOOT_MAX_IMG_SECTORS=256
    # MCUboot serial recovery
    CONFIG_MCUBOOT_SERIAL=n
    #CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_0"
    #CONFIG_BOOT_SERIAL_DETECT_PIN=12
    #CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=0
    #CONFIG_BOOT_SERIAL_DETECT_DELAY=450
    #CONFIG_MCUBOOT_INDICATION_LED=y
    # Size of mcuboot partition
        CONFIG_SIZE_OPTIMIZATIONS=y

2) UART callback cannot be set when using the usart interrupt define so I can shut down the uart.
        CONFIG_UART_ASYNC_API=y
        CONFIG_UART_NRFX=y
        CONFIG_UART_INTERRUPT_DRIVEN=y

        uart_callback_set() returns -ENOTSUP. so I cannot use the callback to read incoming bytes using the callback.

        If I define both only async and not interrupt the while(NRF_UARTE1_NS->EVENTS_RXTO == 0); hangs.
        How do I get around this?
        How can I read incoming bytes without the callback? Is there an example?
        I use uart0 for debug and direct serial configuration and uart1 to the nRF52 chip on our board.

3) Shutdown modules when sleeping to conserve current draw.
 I have on I2C#2 an EEPROM and a temperature chip.
 I have on SPI#3 an external flash and a LSM6DSL sensor chip.
 I use uart0 & uart1.
 I use the ADC.
 A timer set at 1sec wakes the board up from sleep after inital startup and TCP server connection.
 I shutdown the modem calling lte_lc_deinit() since the management will use a global roaming SIM and does not want to use cellular network dependent stuff.
 Every so many minutes the board acquires sensor samples and then goes back to sleep.
 At configured times these samples will be uploaded to the server (TCP connection, upload, disconnection).
 
 I tried using the pm_device_state_set() to turn off the high level drivers (EEPROM,Temp,LSM6DSL) but dev->pm_control == NULL.

 I then tried using the pm_device_state_set() to switch on and off the SPI and I2C buses.

 I understand that there is a way to switch off the ADC so that the high speed clock will be turned off.
 I could not figure out how to disable the ADC. I currently use the adc_read_async() function which is non blocking,
 but I guess I could use a worker thread with the blocking function. Is there an updated example how to shutdown the ADC?

 The board's current is 590ua now.

4) DSP files added and not used
 We need the CMSIS libraries and it seems to work but adds a ton of functions that are not even called.
 Is there a way that the linker will remove them or should I just select all of the files I need in a new directory (bad I know).
  CONFIG_CMSIS_DSP=y
  CONFIG_CMSIS_DSP_SUPPORT=y
  CONFIG_CMSIS_DSP_FASTMATH=y
  CONFIG_CMSIS_DSP_COMPLEXMATH=y
  CONFIG_CMSIS_DSP_STATISTICS=y
  CONFIG_CMSIS_DSP_TRANSFORM=y

[DavidKaplan]

Could anyone help with this?

[Carl Richard]

Hi, David!

Apologies for the delayed answer. I just took over this case from Håkon, as he went on vacation. I will try to address all your questions, but I still suggest that you try to open separate tickets for separate problems. This will make it possible for more of our engineers to help you. If you have any issues opening tickets, please share the details about this to me and we'll sort it out.

1. Could you share an archive with the new board files so that I could have a look? As mentioned by Sebastian P0.30 and P0.31 are used by I2C_2 by default on the DK. The bootloader should not use these pins for anything. And you should not need to have any extra overlay or configuration files under the mcuboot directory. If you want to apply alternative configurations/overlays to application child images (like MCUBoot and SPM), please follow the instructions in the Multi-Image build user guide. A short summary:

In you application directory you can add a folder called "child_image", under this folder you can add files like spm.conf or mcuboot.conf to overlay the configurations of these child images. In addition you can add sub-folders like "child_image/spm" or "child_image/mcuboot", where you can add .overlay files and .conf files that replaces the current child image configuration.

2. Are you sure CONFIG_UART_ASYNC_API is set correctly. ENOTSUP should not be returned if it's enabled. Could you share the "build/zephyr/.config" file so that I can verify the configuration. You can have look at this sample, which is a version of the Low Power UART sample modified to use the normal UART. It should demonstrate both interrupt based and callback based operation.

3. I believe the UART may be your main cause of high current consumption. It's known to use about 600µA. I suggest looking into the Low Power UART (mentioned above) to reduce current consumption. It also helps shutting down the UART when not in use (you're already doing that, maybe?). I must get back to you on shutting down the ADC.  Edit: got back from a colleague that when using the ADC driver it should handle power management automatically. Can you verify that the power consumption is higher when the ADC is on?

4. I need to ask about this internally, but I guess unused functions won't be included.

Best regards,
Carl Richard

[DavidKaplan]

Sorry I cannot find a way how to reply to Carl's post below (no reply button appears).

I hope to have another integration session tomorrow morning with our hardware engineer.

1) Nothing I could do lets me toggle P0.30 & P0.31 so I will attached the zephyr tree with my files that I have have added or adjusted. I will also ask the hardware engineer to verify that there is no pbc hardware mess up.

2) I will open a new support ticket on my uart problems after the integration session.

I need to achieve the lowest possible current draw when sleeping when operating on batteries.

We need uart0 to output debug information and be a direct serial connection for configuring the board after startup. We need uart1 to communicate in both directions when the nRF52 BLE chip is used.

I have read most of the uart posts. uart_irq_callback_set() is a static function in the uart.h header.

I can call this function instead of the uart_callback_set(0 in asynch mode. 

Many of the posts are older and the defines used are not valid. I saw that direct NRF_UARTE0_NS was needed to switch the uart on and off to save power. I need to know if this works only with uart interrupt and not asynch mode and what defines I need for both uart0 and uart1.

3) The ADC is defined in my overlay so I understand from the previous post that it may be initialized before I call adc_channel_setup() or adc_read_async(). I hope to test without any ADC calls and with them.

4) After adding the DSP sources, my app_update.bin increased to 445,148 bytes.

thank you very much David

axion_ncs_08Aug2021a.zipami_axion_08Aug2021a.zip

[DavidKaplan]

After Monday's Microsoft Meeting integration session, I can report that the GPIO P0.30 & P0.31 problem was resolved. The custom hardware and schematic pdf had a header was numbered backwards (square pad not pin#1). I guess this was previously resolved when I added correct custom board overlays since our hardware guy had checked this. Sorry about this but thanks for your help.

[Carl Richard]

Good to hear! Never easy. I hope you get good help on your other issues as well!

Best regards,
Carl Richard