Date   

Re: Confusion about Zephyr ADC API semantics

Jonas Pfaff
 

Hi Marti,

I understand your confusion as I had the same problem a few months ago.
I implemented the sam_afec driver using a 16bit array containing right
aligned 12bit values (can go up to 16bit depending on the ADC config)
because it seemed to be the most plausible and straightforward solution
in my use case.
I am curious to see your solution and would be happy to help where I
can.

Regards,
Jonas

Hello again,

Since about a week has passed by with no response, I assume that the
ADC infrastructure is currently unmaintained (or the maintainers are
on vacation), and will do my best to fix the core semantics as best I
can. I will also make a best effort to contact authors of existing ADC
drivers if I need help as regards to changes that might impact those.

I hope and expect to submit some PRs around this in the first week of
2018, now that I've spent a few days hacking on an nRF SAADC driver
and feel I understand the issues a bit better.

Please let me know if you'd like to help!

Thanks,
Marti

On Fri, Dec 15, 2017 at 9:00 PM, Marti Bolivar
<marti@opensourcefoundries.com> wrote:
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


Re: how to wait for BLE controller initialization?

Johan Hedberg
 

Hi Vakul,

On Thu, Dec 21, 2017, Vakul Garg wrote:
I am using zephyr with nxp board frdm_k64f. It is connected with
frdm_kw41z running the BLE firmware. The kw41z acts as BLE
controller.

The two boards get powered up together. In this setup, bt_enable()
executes even before frdm_kw41z firmware could complete
initialization.

This leads to bt_hci_cmd_send_sync failing for command
BT_HCI_OP_RESET. The failure happens due to timeout on semaphore
'sync_sem'.

As a workaround, I have to insert a delay of 1 second in bt_enable().

Can someone guide me how to fix such a race condition properly?
To me this sounds like something the HCI driver should handle, since
that's the entity that's expected to deal with HW-specific details. You
could e.g. make the HCI driver for your controller block on its open()
call until the HW is ready to receive HCI commands. If you're using the
existing H:4 driver (i.e. drivers/bluetooth/hci/h4.c) you could also use
UART flow control for this, i.e. the controller would only assert the
CTS line when it's ready to receive commands.

Johan


how to wait for BLE controller initialization?

Vakul Garg <vakul.garg@...>
 

Hi

 

I am using zephyr with nxp board frdm_k64f. It is connected with frdm_kw41z running the BLE firmware.

The kw41z acts as BLE controller.

 

The two boards get powered up together.

In this setup, bt_enable() executes even before frdm_kw41z firmware could complete initialization.

 

This leads to bt_hci_cmd_send_sync failing for command BT_HCI_OP_RESET.

The failure happens due to timeout on semaphore ‘sync_sem’.

 

As a workaround, I have to insert a delay of 1 second in bt_enable().

 

Can someone guide me how to fix such a race condition properly?

 

Regards

 

Vakul

 

 


Re: Confusion about Zephyr ADC API semantics

Marti Bolivar
 

Hello again,

Since about a week has passed by with no response, I assume that the
ADC infrastructure is currently unmaintained (or the maintainers are
on vacation), and will do my best to fix the core semantics as best I
can. I will also make a best effort to contact authors of existing ADC
drivers if I need help as regards to changes that might impact those.

I hope and expect to submit some PRs around this in the first week of
2018, now that I've spent a few days hacking on an nRF SAADC driver
and feel I understand the issues a bit better.

Please let me know if you'd like to help!

Thanks,
Marti

On Fri, Dec 15, 2017 at 9:00 PM, Marti Bolivar
<marti@opensourcefoundries.com> wrote:
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


Re: SD card driver?

Michael Hope
 

Thanks Anas, will do.


On Wed, 20 Dec 2017, 22:04 Nashif, Anas, <anas.nashif@...> wrote:
Michael,
I am not aware of anyone working on this, I would start by adding an issue in GH with this, if someone is interested in that, they will find it logged as something that is being worked on and can join you.

Anas

-----Original Message-----
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Michael Hope
Sent: Wednesday, December 20, 2017 3:56 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] SD card driver?

Hi there.  I'm thinking of writing a SPI mode SDHC card driver that implements the disk layer and works with ELMFAT.

Is anyone else working on the same?  If so, would you like to join efforts?

-- Michael
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: SD card driver?

Nashif, Anas
 

Michael,
I am not aware of anyone working on this, I would start by adding an issue in GH with this, if someone is interested in that, they will find it logged as something that is being worked on and can join you.

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Michael Hope
Sent: Wednesday, December 20, 2017 3:56 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] SD card driver?

Hi there. I'm thinking of writing a SPI mode SDHC card driver that implements the disk layer and works with ELMFAT.

Is anyone else working on the same? If so, would you like to join efforts?

-- Michael
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


SD card driver?

Michael Hope
 

Hi there. I'm thinking of writing a SPI mode SDHC card driver that
implements the disk layer and works with ELMFAT.

Is anyone else working on the same? If so, would you like to join efforts?

-- Michael


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

Leandro Pereira
 

Andrew, Zhou Xin,

`ret` is checked against `-EAGAIN` in the `if` statement below. The calling function has to handle this error case; it's actually part of the documented interface. However, I agree that it should retry allocating until it reaches the timeout (or forever, if `timeout` is `K_FOREVER`), and it's not doing it in this case. In fact, the comment in pool_alloc() mentioning `-EAGAIN` seems to agree with your patch, but the current implementation doesn't.

So, yes, please send a pull request. GitHub is currently the best channel for this kind of discussion, as not only it's easier to track patches, the CI system will test them against a battery of tests to ensure things are not broken.

Thanks,
Leandro

On 12/20/2017 09:34 AM, Boie, Andrew P wrote:
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@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] *On Behalf Of *zhou.xin8@sanechips.com.cn
*Sent:* Wednesday, December 20, 2017 12:26 AM
*To:* zephyr-devel@lists.zephyrproject.org
*Cc:* liu.yanan1@sanechips.com.cn; leng.tong@zte.com.cn
*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@sanechips.com.cn
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: NRF5 UART problem

Primini
 

Sorry guys, my mistake. Interrupt driven works like a charm.

Thanks a lot, have a nice week.

Tiago.

On Wed, Dec 20, 2017 at 3:48 PM, Tiago Primini <primini@...> wrote:
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@nordicsemi.no> 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@...hyrproject.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@...ct.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@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Tiago Primini
Sent: Wednesday, December 20, 2017 12:10 AM
To: zephyr-devel@...ct.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: 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

 


4141 - 4160 of 8032