nRF9160 GPIO problem on custom board

RE: nRF9160 GPIO problem on custom board

Carl Richard — Fri, 13 Aug 2021 07:25:40 GMT

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

Best regards,
Carl Richard

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Wed, 11 Aug 2021 05:46:44 GMT

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.

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Mon, 09 Aug 2021 09:09:42 GMT

After this morning's integration session, I can report that the GPIO P0.30 & P0.31 problem was really a custom hardware schematic pdf error in which the header was numbered backwards. I guess this was previously resolved when I added correct custom board overlays. Sorry about this.

I also performed some current draw testing.

ADC:

I left the ADC in the overlay file "okay" but did not reference it in my code and the current was about 900ua.

I called adc_channel_setup() and adc_read_async() every 3 minutes and the current was about 1000ua.

I set the ADC in the overlay file "disabled" and the current was also 900ua.

The base line current was when one uart was not stopped so may be the ADC is not being disabled automatically.

Uart0 & Uart1:

At startup I just disabled uart1 as below:

  //---------------------------------------------------------------------------
  // Low power
  //  When putting the system in low power and the peripheral is not needed, 
  // lowest possible power consumption is achieved by stopping, and then disabling the peripheral.
  // The STOPTX and STOPRX tasks may not be always needed (the peripheral might already be stopped), 
  // but if STOPTX and/or STOPRX is sent, software shall wait until the TXSTOPPED and/or RXTO event is received in response,
  // before disabling the peripheral through the ENABLE register.
  //---------------------------------------------------------------------------
  NRF_UARTE1_NS->TASKS_STOPRX=1;
#if defined(CONFIG_UART_INTERRUPT_DRIVEN)
  while(NRF_UARTE1_NS->EVENTS_RXTO == 0);
#endif
  NRF_UARTE1->EVENTS_RXTO = 0;

  NRF_UARTE1_NS->TASKS_STOPTX = 1;
  while(NRF_UARTE1_NS->EVENTS_TXSTOPPED == 0);
  NRF_UARTE1_NS->EVENTS_TXSTOPPED = 0;

  NRF_UARTE1_NS->ENABLE = 0;
  NRF_UARTE1_NS->PSEL.TXD = 0xFFFFFFFF;
  //---------------------------------------------------------------------------
  // Must change TXD to output low in order that BLE chip will not create a current drain
  // Clear BLE Txd P0.25  
  //---------------------------------------------------------------------------
  NRF_P0_NS->OUTCLR = (1 << 25);
  // Clear BLE Rxd P0.24  
  NRF_P0_NS->OUTCLR = (1 << 24);
  //---------------------------------------------------------------------------
  // Must change RXD to output low in order that BLE chip will not create a current drain
  //---------------------------------------------------------------------------
  ami_board_ConfigPin( AMI_BOARD_OUT_BLE_RXD,GPIO_OUTPUT_LOW);

When after using uart0, when sleeping I did nothing, I got the 900ua baseline current.

When after using uart0, when sleep I performed similar to the code above only for uart0, I got a 480ua to 490ua draw.

Again I use a timer that wakes the program up once a second and if nothing is needed to be done goes back to sleep.

I will open a new ticket for the current drawing issue.

If you could continue to see why it seems that not only used DSP files are being linked, I will not open a separate ticket.

Thank you David

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Sun, 08 Aug 2021 11:23:54 GMT

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

devzone.nordicsemi.com/.../axion_5F00_ncs_5F00_08Aug2021a.zip devzone.nordicsemi.com/.../ami_5F00_axion_5F00_08Aug2021a.zip

RE: nRF9160 GPIO problem on custom board

Carl Richard — Thu, 05 Aug 2021 10:29:01 GMT

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

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Thu, 05 Aug 2021 03:56:42 GMT

Could anyone help with this?

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Tue, 03 Aug 2021 08:26:39 GMT

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

RE: nRF9160 GPIO problem on custom board

Sebastiaan Merckx — Mon, 02 Aug 2021 13:52:13 GMT

Pins 30 and 31 are by default used for I2C-2 on NRF9160, which is disabled by default normally (status="okay"). see nrf9160dk_nrf9160_common.dts for example.

wrt where to put the overlay files: by default, you would just start from a project with an existing board, copy that to a local folder, and then you can put the .overlay in a "boards" folder (same level as your "build" and "src" folders).

If your new board is completely different from any existing board, the overlay is (likely) not a good idea anymore and you'll need to dig deeper in how the devicetree is constructed.

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Sun, 01 Aug 2021 12:46:17 GMT

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

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Sun, 01 Aug 2021 12:21:25 GMT

This morning I found that if I define only

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 async and interrupt as below while(NRF_UARTE1_NS->EVENTS_RXTO == 0); hangs.

CONFIG_UART_ASYNC_API=y
CONFIG_UART_NRFX=y
CONFIG_UART_INTERRUPT_DRIVEN=y

How do I get around this?

How can I read incoming bytes without the callaback.

Thanks David

RE: nRF9160 GPIO problem on custom board

Sebastiaan Merckx — Fri, 30 Jul 2021 10:02:38 GMT

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.

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Thu, 29 Jul 2021 11:08:56 GMT

I have been reading every nRF9160 post I could find and tried their uart conf defines.

After setting the following resolves the while(NRF_UARTE1_NS->EVENTS_RXTO == 0) problem.

CONFIG_UART_NRFX=y
CONFIG_UART_INTERRUPT_DRIVEN=y

All of the other questions are still open and I would like to know what other uart defines should I also add.

Also 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

Thank you David

RE: nRF9160 GPIO problem on custom board

DavidKaplan — Thu, 29 Jul 2021 06:50:29 GMT

Shalom!

In the ncs\vx.y.y\zephyr\boards\arm\ directory, I duplicated the nrf9160dk_nrf9160 with our custom board's name and changing its contents to work with our board. I may have evidently missed something or need to add an overlay or conf file somewhere, since it looks to me that I have a conflict between P0.10 for example and some dk defined pin somewhere else.

Is there a SES project build output files which shows the pins used?

Basically, I use uar0,uart1,ADC,I2C for EPROM and temperature chip, SPI for the external flash and lsm6dsl chip.

All seem to work. I have basic working code that we would like to deploy in the field for cellular network availability evaluation.

I need to have the ability to use all of the limited port pins but this is not an immediate show stopper. It has to be a definition somewhere in Zephyr I would think. I need to advance somehow on this issue.

Now the prototype is battery operated and I read the threads about disabling the uart0 & uart1 when sleeping.

I have defined both uart0 and uart1. I tried disabling uart1 by the following code but EVENTS_RXTO never goes high stalling at the while(NRF_UARTE1_NS->EVENTS_RXTO == 0); line.

I can see in the debugger, in the callback a UART_RX_BUF_RELEASED and then an almost immediate UART_RX_BUF_REQUEST.

  //---------------------------------------------------------------------------
  // Low power
  //  When putting the system in low power and the peripheral is not needed, 
  // lowest possible power consumption is achieved by stopping, and then disabling the peripheral.
  // The STOPTX and STOPRX tasks may not be always needed (the peripheral might already be stopped), 
  // but if STOPTX and/or STOPRX is sent, software shall wait until the TXSTOPPED and/or RXTO event is received in response,
  // before disabling the peripheral through the ENABLE register.
  //---------------------------------------------------------------------------
  NRF_UARTE1_NS->TASKS_STOPRX=1;
  while(NRF_UARTE1_NS->EVENTS_RXTO == 0);
  NRF_UARTE1->EVENTS_RXTO = 0;

  NRF_UARTE1_NS->TASKS_STOPTX = 1;
  while(NRF_UARTE1_NS->EVENTS_TXSTOPPED == 0);
  NRF_UARTE1_NS->EVENTS_TXSTOPPED = 0;

  NRF_UARTE1_NS->ENABLE = 0;
  NRF_UARTE1_NS->PSEL.TXD = 0xFFFFFFFF;
  // Clear BLE Txd P0.25  
  NRF_P0_NS->OUTCLR = (1 << 25);

Could it be that I am missing a proj_xx.conf definition?

I tried both with and without uart1 initialized at startup.

I have the bootloader integrated into my code for FOTA. It does not need to be serially updated.

Currently I use uart0 for system debug printk and for output my own debug information which is very useful.

uart0 is also used a direct serial connection to configure the end unit. All of this works.

Do I need to do anything about the other modules (ADC,I2C,SPI) when not used and want to conserve power?

I understand that Zephyr puts the nRF9160 into sleep mode when nothing is needed to be done.

I wait for a semaphore that is given in a 1 second timer handler.

Can I read uart0's rx line by GPIO to see if it is active in order to reactivate uart0 for a direct connection configuration session?

Next week I hope that our hardware guy will be able to see how much current is being drawn in this state.

I am using the latest v1.6.0 setup.

I tried putting NRF_UARTE1->EVENTS_RXTO in the SES watch window but it was unknown so I it does not seem that it will work also for the GPIO registers. Maybe the SES team could add this.

RE: nRF9160 GPIO problem on custom board

Hakon — Tue, 27 Jul 2021 14:56:25 GMT

Hello,

[quote user=""]Isn't the uart initialed by Zepyr only on calling its binding?[/quote]

No, the UART driver is initialized during pre-kernel initialization. device_get_binding("UART_1") just returns the struct for the UART1 binding.

[quote user=""]Can I switch pins that are not in this file?[/quote]

Do you want to change the pins dynamically? That's not possible as far as I know.

[quote user=""]Maybe this is just for the bootloader?[/quote]

Yes, sort of. It is just valid for the Secure Partition Manager.

[quote user=""]Is there a way in the SES IDE to see the GPIO status at a breakpoint or single stepping?[/quote]

Can't you just put the GPIO register on watch? I haven't tried this, but I think it should work.