Hello, I am looking for a wifi driver which I could use to the interface to be used for a wifi driver to hook up to zephyr. I see a few in the zephyr/drivers/wifi/ folder, but they seem to AT command

Jaemin Choi <jaeminy.choi@...> writes: Glad that part is resolved, sorry you're still (maybe) having problems. Is this still a problem for you? It looks like you are using the zephyr SDK as

Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Thursday, 31 October 2019 8:00am to 9:00am (UTC-07:00) America/Los

Reminder: Zephyr Project: APIs When: Tuesday, 1 October 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to

Hi all, This week we will look at: - CAN: Unification of the TX error behavior - https://github.com/zephyrproject-rtos/zephyr/issues/19502 - GPIO: Update on progress -

Hi Maureen / list, I just thought I would follow up on-list in case anyone else has a similar issue. So I simply enabled CONFIG_STACK_CANARIES=y because ARMv7-M supports gcc's stack canaries, and

Hi Maureen, That's interesting, because now that I think about it, I did have to disable the MPU to even get to main(). Good catch! Do you know if Zephyr has a way to instrument stack

Hi Christopher, It’s possible that a stack overflowed. Kinetis platforms have a “system MPU” instead of the Arm MPU, and memory access violations trigger a bus fault. Maureen

Hi list, I'm experimenting with Zephyr on the kinetis platform and I am encountering a bus fault while running the "samples/net/sockets/dumb_http_server" example. The bus fault only seems to happen

Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Thursday, 26 September 2019 8:00am to 9:00am (UTC-07:00) America/Los

Thanks Marc, I have verified that and it is fine. As mentioned in the previous mails, I am suspecting on the changes that I have made in the file "zephyr/subsys/net/l2/ethernet/ethernet.c". Although,

Hi Giri, can you create an issue in github for this. Trying to resolve your issue in mailing list is not very effective. https://github.com/zephyrproject-rtos/zephyr/issues/new/choose Cheers, Jukka

But, without those changes, if I am trying to ping the board on which Zephyr is running, it is not responding to ping requests and wireshark capture in this scenario can be found in the attached file.

It should but might not be enough because ufw is just a user interface. Use "ip[6]tables -L" to verify the actual state.

The changes that you do there basically turn off ARP, the end result is that the IPv4 connectivity cannot work properly after this. Cheers, Jukka

Hi Jukka, "net iface" is returning a valid mac address. But for my Ethernet to work, I have tweaked Zephyr code. I have posted about it in another topic of this mailing list. Please follow this link

Hi Giri, yes, that is definitely a problem. The destination MAC address should be a valid unicast address. Does you ethernet board have a proper MAC address set to it? You can see the MAC address

Hello, I am currently writing a paper comparing different RTOSs. I want to compare the kernel architecture types of the different RTOSs but Zephyrs kernel confuses me a little bit. I get from

Reminder: Zephyr Project: APIs When: Tuesday, 24 September 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles Where:https://zoom.us/j/177647878 An RSVP is requested. Click here to

Hi Jukka, I have verified the MAC address. Zephyr is sending the [SYN/ACK] packet with destination MAC address as "ff:ff:ff:ff:ff:ff", which is a broadcast address. Does this causing my ubuntu to not