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

[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 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

[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