Date   

Re: NRF5 UART problem

Primini
 

I do not know why but interrupt driven is not working for me, neither hardware flow control, because of this I implemented simple poll in/out. I do not know if the reason is because I have to change the default tx/rx pin configuration because of my wisol shield (the shield does not have CTS/RTS pins). See the boards below:



Inline image 1

Inline image 2

Regards, Tiago.

On Wed, Dec 20, 2017 at 8:37 AM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

Hi Tiaga

 

I think you can take good enough Interrupt driven serial adapter form mcuboot repository here:

https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/serial_adapter.c

https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/include/serial_adapter/serial_adapter.h

 

Regards,

Andrzej

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Chettimada, Vinayak Kariappa
Sent: Wednesday, December 20, 2017 6:46 AM
To: Tiago Primini <primini@...>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] NRF5 UART problem

 

Hi Tiago,

 

I see you do not use h/w flow control or interrupt driven Rx. There is only 6 bytes FIFO in UART peripheral hence, if your implementation does not poll in fast, you will loose bytes.

Optimise your implementation or interrupt driven rx or h/w flowcontrol (last one being the safest option).

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Tiago Primini
Sent: Wednesday, December 20, 2017 12:10 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] NRF5 UART problem

 

Hi everyone!

 

I am developing a firmware responsible to communicate with a sfm10R2 Wisol modem through a serial interface. The wisol shield is coupled in my nRF52832 nordic board. I am trying to get SigfoxID and PAC number from the modem using AT$I=id command, but there is something strange in some responses from modem: sometimes the response did not come with \r\n, for example, AT$I=10 and AT$I=11, which are the commands to get SigfoxID and PAC number respectively:

AT$I=10\r\n or AT$I=10\0\n

Response = A B C D E F F F F F F F ... (the first 6 digits are correct)

AT$I=11\r\n or AT$I=11\0\n

Response = 1 2 3 4 5 6 6 6 6 6 6 6 6 ... (again, the first 6 digits are correct)

Every time a response has more than 6 digits I could read just only the first 6. I could check this using all ids from AT$I=id and sending an invalid command (in this case the response is: E R R O R : : : : : : : : : : : : : ... (repeated ":" and there is no \r\n or \n or \n))

But executing some tests commands (short responses) I can get the correct response, for example:

AT\r\n or AT\0\n

Response = O K \r \n (it seems ok to me) 
AT$SL=AABBCCDDEEFFAABBCCDDEEFF\r\n or AT$SL=AABBCCDDEEFFAABBCCDDEEFF\0\n

Response = O K \r \n (it seems ok to me)

 

I am working on the serial configuration according to vendor requirements:

baud rate: 9600
data bits: 8
stop bits: 1
parity: none
flow control: false


I am not using interrupt driven and I am just writing and reading from UART_0 using simple commands: uart_poll_out and uart_poll_in, following there is the code I am using to test this application:


#include <zephyr.h>
#include <logging/sys_log.h>
#include <uart.h>

#define BUF_MAXSIZE 20

static void run_command(const char *command) {
  struct device *uart_dev = device_get_binding(CONFIG_UART_NRF5_NAME);

  int i;
  unsigned char sent_char;
  for (i = 0; i < strlen(command); i++) {
    sent_char = uart_poll_out(uart_dev, command[i]);

    if (sent_char != command[i]) {
      printk("expect send %c, actual sent %c\n", command[i], sent_char);
    } else {
      printk("sent char = %c\n", sent_char);
    }
  }
  sent_char = uart_poll_out(uart_dev, '\0');
  printk("sent char = %c\n", sent_char);
  sent_char = uart_poll_out(uart_dev, '\n');
  printk("sent char = %c\n", sent_char);

  unsigned char recv_char;

  int counter = 0;
  int counterMax = 10;
  while (uart_poll_in(uart_dev, &recv_char) == -1 && counter <= counterMax) {
    counter++;
    k_sleep(1000);
    printk("waiting for new message[%02d/%02d]...\n", counter, counterMax);
  }

  printk("%c ", recv_char);

  counter = 0;
  int x = 0;
  while (counter < BUF_MAXSIZE && x == 0) {
    int x = uart_poll_in(uart_dev, &recv_char);
    printk("%c ", recv_char);
    counter++;
  }
}

void main(void)
{
  run_command("AT$I=10");
  run_command("AT$I=11");

  while (true) {
    k_sleep(1000);
  }

}

 

my prj.conf:


CONFIG_UART_NRF5=y
CONFIG_UART_NRF5_GPIO_RX_PIN=11
CONFIG_UART_NRF5_GPIO_TX_PIN=12
CONFIG_UART_INTERRUPT_DRIVEN=n
CONFIG_UART_NRF5_FLOW_CONTROL=n

CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

 

Regards,

 

T. Primini



Re: Request review for re-alloc patch @k_mem_pool_alloc()

Boie, Andrew P
 

Can you please send this as a pull request in github?

An explanation of what the race is in the commit message will helpful to reviewers.

http://docs.zephyrproject.org/contribute/contribute_guidelines.html

 

Andrew

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of zhou.xin8@...
Sent: Wednesday, December 20, 2017 12:26 AM
To: zephyr-devel@...
Cc: liu.yanan1@...; leng.tong@...
Subject: [Zephyr-devel] Request review for re-alloc patch @k_mem_pool_alloc()

 

Hi

 

k_mem_pool_alloc()

When race condition failure (-EAGAIN), need to try re-alloc.

We have verified this patch on Zephyr OS v1.9.0.

 

Index: kernel/mempool.c

===================================================================

--- kernel/mempool.c    (revision 70)

+++ kernel/mempool.c    (working copy)

@@ -300,6 +300,11 @@

        while (1) {

                ret = pool_alloc(p, block, size);

 

+               /* [Sanechips] When race condition causes failure, re_alloc. */

+               if (ret == -EAGAIN) {

+                       continue;

+               }

+

                if (ret == 0 || timeout == K_NO_WAIT ||

                    ret == -EAGAIN || (ret && ret != -ENOMEM)) {

                        return ret;

 

 

 

周欣 Zhou Xin

 

安全操作系统与驱动
解决方案一部/解决方案部/深圳市中兴微电子技术有限公司

 

南京市雨花台区紫荆花路68号中兴通讯南京研发中心4C

4C/F, ZTE R&D Center(NanJing), No.68 ZiJinghua Road, 

YuHuatai District, Nanjing, P.R.China, 210012

T: 025-52870384

M: +86 13770868539

E: zhou.xin8@...

 


Re: [Zephyr-users] Problem in working with Ozone and nRF52840

Carles Cufi
 

Hi Ashish,

 

The “variable is out of scope” is pretty common and I get it all the time too. It usually happens with local variables only, and it’s mostly due to the compiler optimizations. So the 2 options you have is to either reduce the optimization level (say from –O3 to –O0) or, for a quick fix, store the variable you’re interested in in a temporary global.

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of ashish.shukla@...
Sent: 20 December 2017 06:22
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Problem in working with Ozone and nRF52840

 

Hello everyone !!!

I'm just starting to work with Ozone for hardware debugging of nRF52840 uC.

When I enter a variable named cnt which is declared in main function, it says the variable is out of scope. I can't figure out what this means here, and how to resolve this.

Also, is there any way look at status of PINs of uC e.g. I want to look at changing status of pins as a graph.

I'm attaching snapshot of Ozone window. 

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 


Re: NRF5 UART problem

Puzdrowski, Andrzej
 

Hi Tiaga

 

I think you can take good enough Interrupt driven serial adapter form mcuboot repository here:

https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/serial_adapter.c

https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/include/serial_adapter/serial_adapter.h

 

Regards,

Andrzej

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Chettimada, Vinayak Kariappa
Sent: Wednesday, December 20, 2017 6:46 AM
To: Tiago Primini <primini@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] NRF5 UART problem

 

Hi Tiago,

 

I see you do not use h/w flow control or interrupt driven Rx. There is only 6 bytes FIFO in UART peripheral hence, if your implementation does not poll in fast, you will loose bytes.

Optimise your implementation or interrupt driven rx or h/w flowcontrol (last one being the safest option).

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tiago Primini
Sent: Wednesday, December 20, 2017 12:10 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF5 UART problem

 

Hi everyone!

 

I am developing a firmware responsible to communicate with a sfm10R2 Wisol modem through a serial interface. The wisol shield is coupled in my nRF52832 nordic board. I am trying to get SigfoxID and PAC number from the modem using AT$I=id command, but there is something strange in some responses from modem: sometimes the response did not come with \r\n, for example, AT$I=10 and AT$I=11, which are the commands to get SigfoxID and PAC number respectively:

AT$I=10\r\n or AT$I=10\0\n

Response = A B C D E F F F F F F F ... (the first 6 digits are correct)

AT$I=11\r\n or AT$I=11\0\n

Response = 1 2 3 4 5 6 6 6 6 6 6 6 6 ... (again, the first 6 digits are correct)

Every time a response has more than 6 digits I could read just only the first 6. I could check this using all ids from AT$I=id and sending an invalid command (in this case the response is: E R R O R : : : : : : : : : : : : : ... (repeated ":" and there is no \r\n or \n or \n))

But executing some tests commands (short responses) I can get the correct response, for example:

AT\r\n or AT\0\n

Response = O K \r \n (it seems ok to me) 
AT$SL=AABBCCDDEEFFAABBCCDDEEFF\r\n or AT$SL=AABBCCDDEEFFAABBCCDDEEFF\0\n

Response = O K \r \n (it seems ok to me)

 

I am working on the serial configuration according to vendor requirements:

baud rate: 9600
data bits: 8
stop bits: 1
parity: none
flow control: false


I am not using interrupt driven and I am just writing and reading from UART_0 using simple commands: uart_poll_out and uart_poll_in, following there is the code I am using to test this application:


#include <zephyr.h>
#include <logging/sys_log.h>
#include <uart.h>

#define BUF_MAXSIZE 20

static void run_command(const char *command) {
  struct device *uart_dev = device_get_binding(CONFIG_UART_NRF5_NAME);

  int i;
  unsigned char sent_char;
  for (i = 0; i < strlen(command); i++) {
    sent_char = uart_poll_out(uart_dev, command[i]);

    if (sent_char != command[i]) {
      printk("expect send %c, actual sent %c\n", command[i], sent_char);
    } else {
      printk("sent char = %c\n", sent_char);
    }
  }
  sent_char = uart_poll_out(uart_dev, '\0');
  printk("sent char = %c\n", sent_char);
  sent_char = uart_poll_out(uart_dev, '\n');
  printk("sent char = %c\n", sent_char);

  unsigned char recv_char;

  int counter = 0;
  int counterMax = 10;
  while (uart_poll_in(uart_dev, &recv_char) == -1 && counter <= counterMax) {
    counter++;
    k_sleep(1000);
    printk("waiting for new message[%02d/%02d]...\n", counter, counterMax);
  }

  printk("%c ", recv_char);

  counter = 0;
  int x = 0;
  while (counter < BUF_MAXSIZE && x == 0) {
    int x = uart_poll_in(uart_dev, &recv_char);
    printk("%c ", recv_char);
    counter++;
  }
}

void main(void)
{
  run_command("AT$I=10");
  run_command("AT$I=11");

  while (true) {
    k_sleep(1000);
  }

}

 

my prj.conf:


CONFIG_UART_NRF5=y
CONFIG_UART_NRF5_GPIO_RX_PIN=11
CONFIG_UART_NRF5_GPIO_TX_PIN=12
CONFIG_UART_INTERRUPT_DRIVEN=n
CONFIG_UART_NRF5_FLOW_CONTROL=n

CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

 

Regards,

 

T. Primini


Request review for re-alloc patch @k_mem_pool_alloc()

Xin Zhou
 

Hi


k_mem_pool_alloc()

When race condition failure (-EAGAIN), need to try re-alloc.

We have verified this patch on Zephyr OS v1.9.0.


Index: kernel/mempool.c

===================================================================

--- kernel/mempool.c    (revision 70)

+++ kernel/mempool.c    (working copy)

@@ -300,6 +300,11 @@

        while (1) {

                ret = pool_alloc(p, block, size);


+               /* [Sanechips] When race condition causes failure, re_alloc. */

+               if (ret == -EAGAIN) {

+                       continue;

+               }

+

                if (ret == 0 || timeout == K_NO_WAIT ||

                    ret == -EAGAIN || (ret && ret != -ENOMEM)) {

                        return ret;




周欣 Zhou Xin


安全操作系统与驱动
解决方案一部/解决方案部/深圳市中兴微电子技术有限公司


南京市雨花台区紫荆花路68号中兴通讯南京研发中心4C

4C/F, ZTE R&D Center(NanJing), No.68 ZiJinghua Road, 

YuHuatai District, Nanjing, P.R.China, 210012

T: 025-52870384

M: +86 13770868539

E: zhou.xin8@...


Re: NRF5 UART problem

Chettimada, Vinayak Kariappa
 

Hi Tiago,

 

I see you do not use h/w flow control or interrupt driven Rx. There is only 6 bytes FIFO in UART peripheral hence, if your implementation does not poll in fast, you will loose bytes.

Optimise your implementation or interrupt driven rx or h/w flowcontrol (last one being the safest option).

 

Regards,

Vinayak

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Tiago Primini
Sent: Wednesday, December 20, 2017 12:10 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] NRF5 UART problem

 

Hi everyone!

 

I am developing a firmware responsible to communicate with a sfm10R2 Wisol modem through a serial interface. The wisol shield is coupled in my nRF52832 nordic board. I am trying to get SigfoxID and PAC number from the modem using AT$I=id command, but there is something strange in some responses from modem: sometimes the response did not come with \r\n, for example, AT$I=10 and AT$I=11, which are the commands to get SigfoxID and PAC number respectively:

AT$I=10\r\n or AT$I=10\0\n

Response = A B C D E F F F F F F F ... (the first 6 digits are correct)

AT$I=11\r\n or AT$I=11\0\n

Response = 1 2 3 4 5 6 6 6 6 6 6 6 6 ... (again, the first 6 digits are correct)

Every time a response has more than 6 digits I could read just only the first 6. I could check this using all ids from AT$I=id and sending an invalid command (in this case the response is: E R R O R : : : : : : : : : : : : : ... (repeated ":" and there is no \r\n or \n or \n))

But executing some tests commands (short responses) I can get the correct response, for example:

AT\r\n or AT\0\n

Response = O K \r \n (it seems ok to me) 
AT$SL=AABBCCDDEEFFAABBCCDDEEFF\r\n or AT$SL=AABBCCDDEEFFAABBCCDDEEFF\0\n

Response = O K \r \n (it seems ok to me)

 

I am working on the serial configuration according to vendor requirements:

baud rate: 9600
data bits: 8
stop bits: 1
parity: none
flow control: false


I am not using interrupt driven and I am just writing and reading from UART_0 using simple commands: uart_poll_out and uart_poll_in, following there is the code I am using to test this application:


#include <zephyr.h>
#include <logging/sys_log.h>
#include <uart.h>

#define BUF_MAXSIZE 20

static void run_command(const char *command) {
  struct device *uart_dev = device_get_binding(CONFIG_UART_NRF5_NAME);

  int i;
  unsigned char sent_char;
  for (i = 0; i < strlen(command); i++) {
    sent_char = uart_poll_out(uart_dev, command[i]);

    if (sent_char != command[i]) {
      printk("expect send %c, actual sent %c\n", command[i], sent_char);
    } else {
      printk("sent char = %c\n", sent_char);
    }
  }
  sent_char = uart_poll_out(uart_dev, '\0');
  printk("sent char = %c\n", sent_char);
  sent_char = uart_poll_out(uart_dev, '\n');
  printk("sent char = %c\n", sent_char);

  unsigned char recv_char;

  int counter = 0;
  int counterMax = 10;
  while (uart_poll_in(uart_dev, &recv_char) == -1 && counter <= counterMax) {
    counter++;
    k_sleep(1000);
    printk("waiting for new message[%02d/%02d]...\n", counter, counterMax);
  }

  printk("%c ", recv_char);

  counter = 0;
  int x = 0;
  while (counter < BUF_MAXSIZE && x == 0) {
    int x = uart_poll_in(uart_dev, &recv_char);
    printk("%c ", recv_char);
    counter++;
  }
}

void main(void)
{
  run_command("AT$I=10");
  run_command("AT$I=11");

  while (true) {
    k_sleep(1000);
  }

}

 

my prj.conf:


CONFIG_UART_NRF5=y
CONFIG_UART_NRF5_GPIO_RX_PIN=11
CONFIG_UART_NRF5_GPIO_TX_PIN=12
CONFIG_UART_INTERRUPT_DRIVEN=n
CONFIG_UART_NRF5_FLOW_CONTROL=n

CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

 

Regards,

 

T. Primini


Problem in working with Ozone and nRF52840

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello everyone !!!

I'm just starting to work with Ozone for hardware debugging of nRF52840 uC.

When I enter a variable named cnt which is declared in main function, it says the variable is out of scope. I can't figure out what this means here, and how to resolve this.

Also, is there any way look at status of PINs of uC e.g. I want to look at changing status of pins as a graph.

I'm attaching snapshot of Ozone window. 

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


答复: Re: Workqueue bug in v1.9.0 and v1.10.0, Requestreview for this patch.

leng.tong@...
 

hi

the function call relationship is      k_delayed_work_submit_to_queue     ->   k_delayed_work_cancel;


in k_delayed_work_submit_to_queue     

 (work->work_q == work_q)      k_work is resubmiited, calls  k_delayed_work_cancel  to  Cancel the submiited  work 


in  k_delayed_work_cancel(work);

        k_work_pending(&work->work)       calls k_queue_remove   to remove k_work form work_q


back to k_delayed_work_submit_to_queue       

work->work_q = work_q;

        k_work_submit_to_queue or _add_timeout


the   pending state of k_work  in k_delayed_work  doesn't   reset neither in k_delayed_work_cancel nor  k_delayed_work_submit_to_queue。so the  k_work_submit_to_queue will fail 


in zehpy 1.8,k_delayed_work_cancel  the earlier pending work  blocks resubmission 。  in zehpy 1.92, the pending work is removed  and the later one carries out。 so we meet this issue after updated  to 1.92

k_delayed_work_cancel  1.8

if (k_work_pending(&work->work)) {

irq_unlock(key);

return -EINPROGRESS;

}





原始邮件
发件人: <luiz.dentz@...>;
收件人:周欣0045002337;
抄送人: <zephyr-devel@...>;刘力凯0045001809;刘亚南0045000760;冷通0045003325;
日 期 :2017年12月19日 19:56
主 题 :Re: [Zephyr-devel] Workqueue bug in v1.9.0 and v1.10.0, Requestreview for this patch.
Hi,

k_delayed_work_cancel no longer uses the flags because it removes the
work from the queue, so either we have a bug in k_queue_remove which
would return success without removing the entry or you are ignoring
the -EINVAL return.


On Tue, Dec 19, 2017 at 1:42 AM,  <zhou.xin8@...> wrote:
> Hi
>
>
> In v1.9.0 and v1.10.0, when remove from the queue if already submitted,
> k_delayed_work_cancel() did not clear bit of work.flags.
>
> This will cause the queue already submitted can not be handled by queue
> manager.
>
>
> Certainly, we have tested and verified on our local side. Request review for
> our patch as below:
>
>
> zephyr-zephyr-v1.9.0\kernel\work_q.c
>
> zephyr-zephyr-v1.10.0\kernel\work_q.c
> Patch of Sanechips
>
> ===================================================================
>
> --- zephyr-zephyr-v1.9.0/kernel/work_q.c        (revision 65)
>
> +++ zephyr-zephyr-v1.9.0/kernel/work_q.c        (working copy)
>
> @@ -123,11 +123,17 @@
>
>         }
>
>
>         if (k_work_pending(&work->work)) {
>
> +
>
> +               /*zxic modify*/
>
> +               atomic_clear_bit(work->work.flags,K_WORK_STATE_PENDING);
>
> +
>
> +
>
>                 /* Remove from the queue if already submitted */
>
>                 if (!k_queue_remove(&work->work_q->queue, &work->work)) {
>
>                         irq_unlock(key);
>
>                         return -EINVAL;
>
>                 }
>
> +
>
>         } else {
>
>                 _abort_timeout(&work->timeout);
>
>         }
>
>
>
>
>
>
> 周欣 Zhou Xin
>
>
> 安全操作系统与驱动
> 解决方案一部/解决方案部/深圳市中兴微电子技术有限公司
>
>
> 南京市雨花台区紫荆花路68号中兴通讯南京研发中心4C
>
> 4C/F, ZTE R&D Center(NanJing), No.68 ZiJinghua Road,
>
> YuHuatai District, Nanjing, P.R.China, 210012
>
> T: 025-52870384
>
> M: +86 13770868539
>
> E: zhou.xin8@...
>
>
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>



-- 
Luiz Augusto von Dentz



NRF5 UART problem

Primini
 

Hi everyone!

I am developing a firmware responsible to communicate with a sfm10R2 Wisol modem through a serial interface. The wisol shield is coupled in my nRF52832 nordic board. I am trying to get SigfoxID and PAC number from the modem using AT$I=id command, but there is something strange in some responses from modem: sometimes the response did not come with \r\n, for example, AT$I=10 and AT$I=11, which are the commands to get SigfoxID and PAC number respectively:

AT$I=10\r\n or AT$I=10\0\n

Response = A B C D E F F F F F F F ... (the first 6 digits are correct)

AT$I=11\r\n or AT$I=11\0\n

Response = 1 2 3 4 5 6 6 6 6 6 6 6 6 ... (again, the first 6 digits are correct)

Every time a response has more than 6 digits I could read just only the first 6. I could check this using all ids from AT$I=id and sending an invalid command (in this case the response is: E R R O R : : : : : : : : : : : : : ... (repeated ":" and there is no \r\n or \n or \n))

But executing some tests commands (short responses) I can get the correct response, for example:

AT\r\n or AT\0\n

Response = O K \r \n (it seems ok to me) 
AT$SL=AABBCCDDEEFFAABBCCDDEEFF\r\n or AT$SL=AABBCCDDEEFFAABBCCDDEEFF\0\n

Response = O K \r \n (it seems ok to me)

I am working on the serial configuration according to vendor requirements:
baud rate: 9600
data bits: 8
stop bits: 1
parity: none
flow control: false

I am not using interrupt driven and I am just writing and reading from UART_0 using simple commands: uart_poll_out and uart_poll_in, following there is the code I am using to test this application:

#include <zephyr.h>
#include <logging/sys_log.h>
#include <uart.h>

#define BUF_MAXSIZE 20

static void run_command(const char *command) {
  struct device *uart_dev = device_get_binding(CONFIG_UART_NRF5_NAME);

  int i;
  unsigned char sent_char;
  for (i = 0; i < strlen(command); i++) {
    sent_char = uart_poll_out(uart_dev, command[i]);

    if (sent_char != command[i]) {
      printk("expect send %c, actual sent %c\n", command[i], sent_char);
    } else {
      printk("sent char = %c\n", sent_char);
    }
  }
  sent_char = uart_poll_out(uart_dev, '\0');
  printk("sent char = %c\n", sent_char);
  sent_char = uart_poll_out(uart_dev, '\n');
  printk("sent char = %c\n", sent_char);

  unsigned char recv_char;

  int counter = 0;
  int counterMax = 10;
  while (uart_poll_in(uart_dev, &recv_char) == -1 && counter <= counterMax) {
    counter++;
    k_sleep(1000);
    printk("waiting for new message[%02d/%02d]...\n", counter, counterMax);
  }

  printk("%c ", recv_char);

  counter = 0;
  int x = 0;
  while (counter < BUF_MAXSIZE && x == 0) {
    int x = uart_poll_in(uart_dev, &recv_char);
    printk("%c ", recv_char);
    counter++;
  }
}

void main(void)
{
  run_command("AT$I=10");
  run_command("AT$I=11");

  while (true) {
    k_sleep(1000);
  }
}

my prj.conf:

CONFIG_UART_NRF5=y
CONFIG_UART_NRF5_GPIO_RX_PIN=11
CONFIG_UART_NRF5_GPIO_TX_PIN=12
CONFIG_UART_INTERRUPT_DRIVEN=n
CONFIG_UART_NRF5_FLOW_CONTROL=n

CONFIG_HAS_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

Regards,

T. Primini


Re: Workqueue bug in v1.9.0 and v1.10.0, Request review for this patch.

Luiz Augusto von Dentz
 

Hi,

k_delayed_work_cancel no longer uses the flags because it removes the
work from the queue, so either we have a bug in k_queue_remove which
would return success without removing the entry or you are ignoring
the -EINVAL return.

On Tue, Dec 19, 2017 at 1:42 AM, <zhou.xin8@sanechips.com.cn> wrote:
Hi


In v1.9.0 and v1.10.0, when remove from the queue if already submitted,
k_delayed_work_cancel() did not clear bit of work.flags.

This will cause the queue already submitted can not be handled by queue
manager.


Certainly, we have tested and verified on our local side. Request review for
our patch as below:


zephyr-zephyr-v1.9.0\kernel\work_q.c

zephyr-zephyr-v1.10.0\kernel\work_q.c
Patch of Sanechips

===================================================================

--- zephyr-zephyr-v1.9.0/kernel/work_q.c (revision 65)

+++ zephyr-zephyr-v1.9.0/kernel/work_q.c (working copy)

@@ -123,11 +123,17 @@

}


if (k_work_pending(&work->work)) {

+

+ /*zxic modify*/

+ atomic_clear_bit(work->work.flags,K_WORK_STATE_PENDING);

+

+

/* Remove from the queue if already submitted */

if (!k_queue_remove(&work->work_q->queue, &work->work)) {

irq_unlock(key);

return -EINVAL;

}

+

} else {

_abort_timeout(&work->timeout);

}






周欣 Zhou Xin


安全操作系统与驱动
解决方案一部/解决方案部/深圳市中兴微电子技术有限公司


南京市雨花台区紫荆花路68号中兴通讯南京研发中心4C

4C/F, ZTE R&D Center(NanJing), No.68 ZiJinghua Road,

YuHuatai District, Nanjing, P.R.China, 210012

T: 025-52870384

M: +86 13770868539

E: zhou.xin8@sanechips.com.cn


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
--
Luiz Augusto von Dentz


Re: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello all,

I got Ozone working for nrf52840 PDK. Thanks a lot. 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Tue, Dec 19, 2017 at 2:16 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi there,

 

Once the PR below is merged, you will be able to use GDB by simply typing “make debug” if you prefer it to Ozone:

 

https://github.com/zephyrproject-rtos/zephyr/pull/5435

 

Regards,

 

Carles

 

From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of ashish.shukla@...
Sent: 18 December 2017 13:20
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 



Workqueue bug in v1.9.0 and v1.10.0, Request review for this patch.

Xin Zhou
 

Hi


In v1.9.0 and v1.10.0, when remove from the queue if already submitted, k_delayed_work_cancel() did not clear bit of work.flags.

This will cause the queue already submitted can not be handled by queue manager.


Certainly, we have tested and verified on our local side. Request review for our patch as below:


zephyr-zephyr-v1.9.0\kernel\work_q.c

zephyr-zephyr-v1.10.0\kernel\work_q.c                                                                                                                                   Patch of Sanechips

===================================================================

--- zephyr-zephyr-v1.9.0/kernel/work_q.c        (revision 65)

+++ zephyr-zephyr-v1.9.0/kernel/work_q.c        (working copy)

@@ -123,11 +123,17 @@

        }


        if (k_work_pending(&work->work)) {

+

+               /*zxic modify*/

+               atomic_clear_bit(work->work.flags,K_WORK_STATE_PENDING);

+

+

                /* Remove from the queue if already submitted */

                if (!k_queue_remove(&work->work_q->queue, &work->work)) {

                        irq_unlock(key);

                        return -EINVAL;

                }

+

        } else {

                _abort_timeout(&work->timeout);

        }






周欣 Zhou Xin


安全操作系统与驱动
解决方案一部/解决方案部/深圳市中兴微电子技术有限公司


南京市雨花台区紫荆花路68号中兴通讯南京研发中心4C

4C/F, ZTE R&D Center(NanJing), No.68 ZiJinghua Road, 

YuHuatai District, Nanjing, P.R.China, 210012

T: 025-52870384

M: +86 13770868539

E: zhou.xin8@...


Re: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

Carles Cufi
 

Hi there,

 

Once the PR below is merged, you will be able to use GDB by simply typing “make debug” if you prefer it to Ozone:

 

https://github.com/zephyrproject-rtos/zephyr/pull/5435

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of ashish.shukla@...
Sent: 18 December 2017 13:20
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 


Re: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

Carles Cufi
 

Hi there,

 

You can use both GDB and Ozone using the built-in Segger chip.

 

Take a look at this page:

 

http://docs.zephyrproject.org/tools/nordic_segger.html#nordic-segger

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of ashish.shukla@...
Sent: 18 December 2017 13:20
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Making use of Hardware debugger available with nrf52840 preview development kit

 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 


Making use of Hardware debugger available with nrf52840 preview development kit

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi !

I've got nrf52840 pdk and I'm working with blue tooth mesh developed by zephyr community.

I want to make use of hardware debugger available with development kit, i.e. I should be able see values of registers, values in memory address, halt processing at any specific line of code and examine those values.

I read documentation but didn't find anything related to what I'm looking for.

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: #ZephyrBluetoothMesh ..... What Next ?? ....need info beyond #zephyrbluetoothmesh #gettingstartedguide

Johan Hedberg
 

Hi Vikrant,

On Sat, Dec 16, 2017, Vikrant More wrote:
https://www.youtube.com/watch?v=301ynC2IdbY

Mr. Martin Woolley has released video which shows time required to discover
& provision #BluetoothMesh DEVICE.

In this case, he has used "firmware + board + APP" only from Silicon labs.
Is this a reason behind his board get quickly discovered by the APP
(approx.4 to 5 Seconds) ?
It's impossible to say for sure without some more information. It's
possible that different advertising parameters are used. If you have
PB-ADV enabled that will also take time away from PB-GATT advertising.
Note that after initialization Zephyr will advertise for one minute
using more agressive parameters (faster discovery & connection creation)
and after that move to more relaxed parameters to save power.

While testing, I noticed that Silicon Labs #BluetoothMESHApp takes more
time to discover nrf52840-PDK as DEVICE. Sometimes I have to reboot the
nrf52 board or restart APP.
Are you saying that Zephyr is somehow stuck in this case? I haven't seen
that happen. If you reproduce it, it would be good if you could do some
more thorrough analysis of what's going on (e.g. has everything come to
a halt, or are the threads still running but the controller just stopped
advertising, or something like that).

Could you please tell me how to explore all available features within
#ZephyrBluetoothMesh ?

After

1) controlling on board LEDs using Silicon Labs APP &
2) publishing data by pressing Button on nrf52-PDK board to control
LEDs on other boards

I don't know what to do next ?
That largely depends what you want to do, i.e. what kind of device &
application you want to build. If you haven't done so already, I
recommend browsing through the Mesh Model Specification to see what kind
of standard models exist. If none fit the use case you have in mind you
could also consider creating a custom vendor model.

https://www.youtube.com/watch?v=TwVwIjTX6SI in this video you are
utilizing concept of heartbeat. Could you please tell me more about it
? When & why to use it ?
I can't say much beyond what you can find in the Mesh Profile
Specification. The relevant sections would be 3.6.5.10, 4.2.17 and
4.2.18. The feature is useful e.g. for discovering the topology of a
network as well as for getting notifications when the enabled features
of a node changes.

Johan


#ZephyrBluetoothMesh ..... What Next ?? ....need info beyond #zephyrbluetoothmesh #gettingstartedguide

Vikrant More <vikrant8051@...>
 

Mr. Martin Woolley has released video which shows time required to discover & provision #BluetoothMesh DEVICE.

In this case, he has used "firmware + board + APP" only from Silicon labs. Is this a reason behind his board get quickly discovered by the APP (approx.4 to 5 Seconds) ?

In my case,
Board = nrf52840-PDK
Firmware = Zephyr-OS
APP = Silicon Labs Mesh APP.

While testing, I noticed that Silicon Labs #BluetoothMESHApp takes more time to discover nrf52840-PDK as DEVICE. Sometimes I have to reboot the nrf52 board or restart APP.

-----------------------------------------------------------------------------------------------------------------------------------------

Could you please tell me how to explore all available features within #ZephyrBluetoothMesh ?

After 

1) controlling on board LEDs using Silicon Labs APP &
2) publishing data by pressing Button on nrf52-PDK board to control LEDs on other boards

I don't know what to do next ?

Need your help so that I can utilize maximum available features within #ZephyrBluetoothMesh?

Meshctl & Silicon Labs App has limited Models support & hence can't do anything beyond that.
--------------------------------------------------------------------------------------------------------------------------------------------

https://www.youtube.com/watch?v=TwVwIjTX6SI in this video you are utilizing concept of heartbeat. Could you please tell me more about it ? When & why to use it ?

------------------------------------------------------------------------------------------------------------------------------------------






Re: I2C driver for nrf52840 not being compiled

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi,

Thanks, it compiles and run successfully.


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Fri, Dec 15, 2017 at 1:53 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

Hi.

 

For nRF52840 I2C driver is zephyr. All its option are in general i2c Kconfig file.

I attached configuration I had used to compile example you mentioned.

 

BR

 

Andrzej

 

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of ashish.shukla@...
Sent: Friday, December 15, 2017 5:56 AM
To: zephyr-users@lists.zephyrproject.org; zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] I2C driver for nrf52840 not being compiled

 

Hello everyone !

I'm trying to interface an I2C device with nrf52840 controller.

When I look into ../zephyr/drivers/i2c directory, there is no Kconfig file corresponding to i2c_nrf5.c 

Again in Kconfig, this driver isn't included, consequently I'm not being able to compile ../zephyr/samples/drivers/i2c_fujitsu_fram  demo for nrf52840.

what needs to be done to fix this issue?  

 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 



Confusion about Zephyr ADC API semantics

Marti Bolivar
 

Hi,

I've been reading through the ADC API, its users, and its test cases,
and I'm confused about the semantics of struct adc_seq_entry, in
particular the field named "buffer". The API docs are vague and the
users contradict each other; something seems wrong to me.

(I volunteer to try to improve the documentation if we can clear
things up; I'm working on an ADC driver and would like to make sure
I'm doing the right thing.)

The main header says "buffer" is a byte array:

https://github.com/zephyrproject-rtos/zephyr/blob/master/include/adc.h#L39

But it doesn't say anything about the contents. That's strange,
especially since common ADC IPs can do 12+ bit conversions. (I at
least expected a u16*, and something written about the left- or
right-alignment of sample data, e.g. how a 12 bit sample is stored in
a 16 bit word.)

That same header only has this to say about the returned values from
an adc_read() call:

* The sample data can be retrieved from the memory buffers in
* the sequence table structure.

So I looked at the API users to find out more, but the results were
even more confusing.

This "simple" test wants to interpret the results as though the buffer
field points at an array of u32 (note the _print_sample_in_hex
implementation and the "delta" printk in adc_test):

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L36

It also says buffer should be void*, which isn't true:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_simple/src/main.c#L78

This "api" test thinks buffer is u16*:

https://github.com/zephyrproject-rtos/zephyr/blob/master/tests/drivers/adc/adc_api/src/test_adc.c#L53

The ADC-based grove temperature driver treats Zephyr samples as if
they were 12 bit right aligned values in a u16 array, and has a
comment saying that's the common convention:

https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/grove/temperature_sensor.c#L46

Can anyone clarify what the correct interpretation of this field is?

Thanks,
Marti


adding support for stm32f072b_disco board: shippable returns unstable

Daniel Wagenknecht
 

Hi!

I opened a PR to add support for stm32f072b_disco board here pr5405. Local Sanity Check only ran 5 Tests and returned OK.

Shippable returns unstable with linking errors in some tests (e.g. tests/net/ieee802154/l2/test, tests/net/lib/mqtt_subscriber/test), because of small SRAM. I expected
ram: 16
at 
stm32f072b_disco.yaml to prevent the tests beeing run for this target.

 

How should this be solved?

Daniel Wagenknecht

 

4301 - 4320 of 8183