1. users@lists.zephyrproject.org
   Date   
Porting GRBL to Zephyr

Lukasz Iwaszkiewicz
 

Hi all

I was wondering how to port some of the existing CNC suites to
Zephyr and I need your opinion on this. My idea was to take only (or
at least) g-code and stepper motor implementation from a project like
grbl, g2core (https://github.com/synthetos/g2) or Smoothieware
(https://github.com/Smoothieware/Smoothieware) and combine it with all
the goodies Zephyr has to offer, like USB support, disk access (SD
cards), FatFs, board abstraction and so on.

All of the projects mentioned above use a hardware timer (so far as my
analysis goes) which in it's ISR (whether when the timer overflows or
output compare event happens) performs some simple decisions which
motors to step and generates step pulses for those. This approach lets
them synchronize all the motors and achieve greater accuracy.

And so my main question arises : how to accomplish this in Zephyr. To
my knowledge there is no user space hardware timer API other than for
generating PWM. I have seen some PR's that aimed at implementing this
(I cannot find them now), but couldn't this be done using existing
APIs somehow? PS. We are talking about frequencies like at least 30kHz
but preferably higher and the number of motors is at least 3.

Iwasz.
Make smaller binary (disable .debug_info etc)

Martin Kozusky
 
Edited

Hi,
I am trying to figure out how to make the binary for nrf52dk_nrf52832 smaller, so I tried to look at zepyr.map with AMap and I am seeing so much .debug_info, .debug_line etc stuff in .map file.
I started playing with  hello_world and added
CONFIG_DEBUG=n
CONFIG_DEBUG_INFO=n
into prj.conf (nothing else there). But .debug_info etc. lines are still there, the only change is in size of modules (and the final binary, but I think debug data are not still completely removed)

ie. - with DEBUG=y, the biggest one is .debug_info for zephyr/kernel/libkernel.a module called from sched.c.obj) - 23 360B, with DEBUG=n, the size of module is 22 641 B
Why are .debug_info etc still included even with CONFIG_DEBUG=n ?

Is it possible to disable debug info completely? Or is it always removed when converting .elf into .bin ? If yes, can I get .map file, which will tell me exactly what is just in .bin file?

Thanks,
Martin
Switch between network interfaces during runtime (Offloaded modem/Ethernet) #driver #networking #stm32 #ethernet #modem

John Johnson
 

Hi Zephyr Users,

I wonder how I can make my app switch between which network interface it use during runtime. My idea is to automate the if-selection depending on which of the ifs that has a internet connection.

I have begun simply with using http_get sample and it works fine when I'm using the ifs one at the time. But when I compile in both of them Zephyr wants to use one of the ifs over the other. The setup I'm using is the STM32H747i_disco dev. kit with its built in ethernet-if (aka not offloaded) and Sparkfuns Ublox Sara R4 shield (which is offloaded).

Zephyr always chooses R4 in this sample even though I have set CONFIG_NET_DEFAULT_IF_ETHERNET in prj.conf. Zephyr sets up both my ifs and runs a DCHP request for the ethernet-if. When the sample is done with its HTTP
request (which it does over R4) I can send net cmds like DNS-requests and ping servers with the ethernet-if. Which leads me to believe that the ethernet-if is ready to use by the sample somehow.

So how can I make the sample tell Zephyr to use the ethernet-if instead of the R4?

Further more I'm a bit preplexed because to my untrained eye it seems that Zephyr don't support to use offloaded and non offloaded ifs at the same time from a BSD-socket perspective. When zsock_getaddrinfo() runs it first checks if
CONFIG_NET_SOCKETS_OFFLOAD is enabled and the does the DNS request on the offloaded-if, and thus wont use the internal DNS resolver (which comes after the offloaded check in the code).

Thank you in advance//
John Johnson
Re: Debugging Zephyr using no able to stop at specific source line after init.c #debugging

ngbk1993@...
 

I have tried to set a break point at where the zephyr start to halt at the fatal error function, and I'm able to trace where exactly the exception happened. It ends up to the ns16550 driver in my board, require the option CONFIG_UART_ACCESS_WORD_ONLY

https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_UART_NS16550_ACCESS_WORD_ONLY.html
Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

Nikolaus Huber
 

Yes, that is what I though, the layout of the board is a bit strange. 

Thank you very much for your input! The idea of having a dedicated sensor thread has also occurred to me. We are using the Thunderboards for teaching a university course in embedded systems programming. I think this might actually be a nice example to introduce the idea of threads and mutual exclusion. 

Thank you again for your help!
/Nick

On 23 Nov 2020, at 16:38, Lawrence King <lawrence.king@...> wrote:

I just looked at the wiring for the Thunderboard Sense 2. It is crazy….
 
Normally all of the I2C  devices on a board are wired to a single I2C Bus. But the designers of the Thunderboard decided to connect to three different I2C busses, even though the chip only has two controllers. Hence you have ended up in the strange situation where you need to multiplex a single controller across at least 2 sets of pins. To be honest I have never seen this before, but it is what it is…
 
Sensor                Pins
Pressure             PC4-5
Gas                      PB6-7
Hall                     PB8-9
Light                   PC4-5
Humidity            PC4-5
 
I would start out by ignoring the hall sensor, then routing I2C_1 to PC4-5, and I2C_2 to PB6-7 and get all of your software running. Then go back and think about hacking the driver so you can flip I2C_2 between PB6-7 and PB8-9. Of course if you also have external I2C sensors on other pins life is even more difficult.
 
A better solution than hacking the driver I would be starting a sensor task that processes a work que. The work queue would contain requests for I2C read/write from the multiplexed sensors. The sensor task would get a request, reconfigure the mux (if necessary), complete the request and return the result, then work on the next request. Effectively the serial processing nature of the sensor task becomes your mutex, without the bother of trying to modify the Zephyr kernel. Since the hall and gas sensors are pretty slow, the overhead of the sensor task will be negligible.
 
Lawrence King
Principal Developer
+1(416)627-7302
 
From: Nikolaus Huber <nikolaus.huber@...> 
Sent: Monday, November 23, 2020 10:02 AM
To: Lawrence King <lawrence.king@...>
Cc: Adam Podogrocki <a.podogrocki@...>; Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c
 
Dear Lawrence, 
 
Thank you for your reply! Indeed, after rereading the data sheet I also realised my confusion. The problem with the rerouting however persists. The chip allows to reroute the SDA and SLC signal from either I2C peripheral dynamically during runtime by changing the location bitfields in the respective I2Cn_ROUTELOC0 registers. 
 
This means, that for example on the Thunderboard 2 Sense development board, different sensors are connected to the same I2C peripheral, but through different pins. So I need to change the ROUTELOC0 register every time before issuing a call to Zephyr’s i2c driver. I was just curious if that is something common, that I’m unaware of, and if there would be a general (i.e. Zephyr idiomatic) way of doing that. I have read through the i2c driver implementation for the Gecko chip family now, and it seems, that that is not really taken care of. So I guess one could do this either within the application code, or do it in the respective sensor driver. Ultimately, I guess it would be nice to change the i2c driver implementation to take care of this, since there probably needs to be some form of mutex between rerouting the i2c peripheral, issuing the call, and routing it back to where it was before, and that mutex is per peripheral. 
 
Thank you all very much for your replies! They really helped.
/Nick


On 23 Nov 2020, at 15:42, Lawrence King <lawrence.king@...> wrote:
 
Hi Nikolaus
 
I have yet to see a SOC that allows connecting one internal I2C controller to two sets of external pins at one time. Although theoretically possible it would be an unusual feature, and of very limited use. The usual solution is to have multiple I2C controllers in the SOC, and allow routing of each controller to various pins on the SOC package.
 
I just had a quick read through the Mighty Gecko datasheet. The processor has two I2C controllers, which in Zephyr parlance will be I2C_1 and I2C_2. You need to define both controllers and their physical pins in your device tree overlay. Then your software must open both controllers, and you must communicate with your peripherals through the correct I2C controller.
 
Hope this helps.
 
Lawrence King
Principal Developer
+1(416)627-7302
 
From: users@... <users@...> On Behalf Of Adam Podogrocki
Sent: Monday, November 23, 2020 2:47 AM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c
 
Hi Nikolaus,
 
I assume that your MCU allows alternative SDA/SCL configurations but not simultaneous, i.e. you can decide on which SDA/SCL pair of pins you can have I2C bus, but not on all pairs at the same time.
 
Cheers,
Adam
 
On Sat, 21 Nov 2020 at 00:52, Nikolaus Huber <nikolaus.huber@...> wrote:
Hej,  
 
Thanks for your reply! The specific chip on that board has two I2C peripherals. However, all the sensors I’m interested in are on one (i2c_1). The chip allows routing the same I2C peripheral to multiple pins, i.e. the same SDA and SCL line is available on different pins. Every set of (SDA, SCL) pins still needs to be configured though. For the two pins that are listed in the device tree (the one in the board.dts file just uses those that are connected to one specific sensor), this happens in the init function of the i2c driver. The other pins (which are theoretically also connected to that I2C peripheral) are thus never configured, therefore any sensors connected to them won’t work. I could probably configure those pins manually, but then that solution doesn’t seem very nice (i.e. I would need to adjust the device tree according to which set of sensors I want to reach for each application). So what I’m trying to achieve is, that whenever I do something like i2c_write(i2c_1_dev, …) this actually happens on all pins, that are connected to the i2c_1 peripheral. 
 
 
I’m asking if anyone maybe had a similar situation (it is the first time for me that a microcontroller allows routing the same signal to multiple pins), and how to do this so that it plays nicely with the zephyr API. 
 
Thank’s for your input again!
/Nick



On 21 Nov 2020, at 00:26, Erik Englund <erik.englund@...> wrote:
 
Hi.
 
It´s a bit unclear what you´re asking.
 
Most MCUs require you to define what pins to use for a specific peripheral, in your case i2c_1.
 
If  you have several I2C peripherals(in the MCU) you may connect sensors/other-chips to whatever pins are configurable to that peripheral.
 
Please elaborate what the problem is.
 
 

Med vänlig hälsning
Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA

+46(0)707319440
Org.nr. 556790-2977
www.innoware.se
 








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ 

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy
Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

Lawrence King
 

I just looked at the wiring for the Thunderboard Sense 2. It is crazy….

 

Normally all of the I2C  devices on a board are wired to a single I2C Bus. But the designers of the Thunderboard decided to connect to three different I2C busses, even though the chip only has two controllers. Hence you have ended up in the strange situation where you need to multiplex a single controller across at least 2 sets of pins. To be honest I have never seen this before, but it is what it is…

 

Sensor                Pins

Pressure             PC4-5

Gas                      PB6-7

Hall                     PB8-9

Light                   PC4-5

Humidity            PC4-5

 

I would start out by ignoring the hall sensor, then routing I2C_1 to PC4-5, and I2C_2 to PB6-7 and get all of your software running. Then go back and think about hacking the driver so you can flip I2C_2 between PB6-7 and PB8-9. Of course if you also have external I2C sensors on other pins life is even more difficult.

 

A better solution than hacking the driver I would be starting a sensor task that processes a work que. The work queue would contain requests for I2C read/write from the multiplexed sensors. The sensor task would get a request, reconfigure the mux (if necessary), complete the request and return the result, then work on the next request. Effectively the serial processing nature of the sensor task becomes your mutex, without the bother of trying to modify the Zephyr kernel. Since the hall and gas sensors are pretty slow, the overhead of the sensor task will be negligible.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: Nikolaus Huber <nikolaus.huber@...>
Sent: Monday, November 23, 2020 10:02 AM
To: Lawrence King <lawrence.king@...>
Cc: Adam Podogrocki <a.podogrocki@...>; Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

 

Dear Lawrence,

 

Thank you for your reply! Indeed, after rereading the data sheet I also realised my confusion. The problem with the rerouting however persists. The chip allows to reroute the SDA and SLC signal from either I2C peripheral dynamically during runtime by changing the location bitfields in the respective I2Cn_ROUTELOC0 registers. 

 

This means, that for example on the Thunderboard 2 Sense development board, different sensors are connected to the same I2C peripheral, but through different pins. So I need to change the ROUTELOC0 register every time before issuing a call to Zephyr’s i2c driver. I was just curious if that is something common, that I’m unaware of, and if there would be a general (i.e. Zephyr idiomatic) way of doing that. I have read through the i2c driver implementation for the Gecko chip family now, and it seems, that that is not really taken care of. So I guess one could do this either within the application code, or do it in the respective sensor driver. Ultimately, I guess it would be nice to change the i2c driver implementation to take care of this, since there probably needs to be some form of mutex between rerouting the i2c peripheral, issuing the call, and routing it back to where it was before, and that mutex is per peripheral. 

 

Thank you all very much for your replies! They really helped.

/Nick



On 23 Nov 2020, at 15:42, Lawrence King <lawrence.king@...> wrote:

 

Hi Nikolaus

 

I have yet to see a SOC that allows connecting one internal I2C controller to two sets of external pins at one time. Although theoretically possible it would be an unusual feature, and of very limited use. The usual solution is to have multiple I2C controllers in the SOC, and allow routing of each controller to various pins on the SOC package.

 

I just had a quick read through the Mighty Gecko datasheet. The processor has two I2C controllers, which in Zephyr parlance will be I2C_1 and I2C_2. You need to define both controllers and their physical pins in your device tree overlay. Then your software must open both controllers, and you must communicate with your peripherals through the correct I2C controller.

 

Hope this helps.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Adam Podogrocki
Sent: Monday, November 23, 2020 2:47 AM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

 

Hi Nikolaus,

 

I assume that your MCU allows alternative SDA/SCL configurations but not simultaneous, i.e. you can decide on which SDA/SCL pair of pins you can have I2C bus, but not on all pairs at the same time.

 

Cheers,

Adam

 

On Sat, 21 Nov 2020 at 00:52, Nikolaus Huber <nikolaus.huber@...> wrote:

Hej,  

 

Thanks for your reply! The specific chip on that board has two I2C peripherals. However, all the sensors I’m interested in are on one (i2c_1). The chip allows routing the same I2C peripheral to multiple pins, i.e. the same SDA and SCL line is available on different pins. Every set of (SDA, SCL) pins still needs to be configured though. For the two pins that are listed in the device tree (the one in the board.dts file just uses those that are connected to one specific sensor), this happens in the init function of the i2c driver. The other pins (which are theoretically also connected to that I2C peripheral) are thus never configured, therefore any sensors connected to them won’t work. I could probably configure those pins manually, but then that solution doesn’t seem very nice (i.e. I would need to adjust the device tree according to which set of sensors I want to reach for each application). So what I’m trying to achieve is, that whenever I do something like i2c_write(i2c_1_dev, …) this actually happens on all pins, that are connected to the i2c_1 peripheral. 

 

 

I’m asking if anyone maybe had a similar situation (it is the first time for me that a microcontroller allows routing the same signal to multiple pins), and how to do this so that it plays nicely with the zephyr API. 

 

Thank’s for your input again!

/Nick




On 21 Nov 2020, at 00:26, Erik Englund <erik.englund@...> wrote:

 

Hi.

 

It´s a bit unclear what you´re asking.

 

Most MCUs require you to define what pins to use for a specific peripheral, in your case i2c_1.

 

If  you have several I2C peripherals(in the MCU) you may connect sensors/other-chips to whatever pins are configurable to that peripheral.

 

Please elaborate what the problem is.

 

 


Med vänlig hälsning

Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA

+46(0)707319440
Org.nr. 556790-2977
www.innoware.se

 









När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ 

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy

 
Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

Nikolaus Huber
 

Dear Lawrence,

Thank you for your reply! Indeed, after rereading the data sheet I also realised my confusion. The problem with the rerouting however persists. The chip allows to reroute the SDA and SLC signal from either I2C peripheral dynamically during runtime by changing the location bitfields in the respective I2Cn_ROUTELOC0 registers. 

This means, that for example on the Thunderboard 2 Sense development board, different sensors are connected to the same I2C peripheral, but through different pins. So I need to change the ROUTELOC0 register every time before issuing a call to Zephyr’s i2c driver. I was just curious if that is something common, that I’m unaware of, and if there would be a general (i.e. Zephyr idiomatic) way of doing that. I have read through the i2c driver implementation for the Gecko chip family now, and it seems, that that is not really taken care of. So I guess one could do this either within the application code, or do it in the respective sensor driver. Ultimately, I guess it would be nice to change the i2c driver implementation to take care of this, since there probably needs to be some form of mutex between rerouting the i2c peripheral, issuing the call, and routing it back to where it was before, and that mutex is per peripheral. 

Thank you all very much for your replies! They really helped.
/Nick

On 23 Nov 2020, at 15:42, Lawrence King <lawrence.king@...> wrote:

Hi Nikolaus
 
I have yet to see a SOC that allows connecting one internal I2C controller to two sets of external pins at one time. Although theoretically possible it would be an unusual feature, and of very limited use. The usual solution is to have multiple I2C controllers in the SOC, and allow routing of each controller to various pins on the SOC package.
 
I just had a quick read through the Mighty Gecko datasheet. The processor has two I2C controllers, which in Zephyr parlance will be I2C_1 and I2C_2. You need to define both controllers and their physical pins in your device tree overlay. Then your software must open both controllers, and you must communicate with your peripherals through the correct I2C controller.
 
Hope this helps.
 
Lawrence King
Principal Developer
+1(416)627-7302
 
From: users@... <users@...> On Behalf Of Adam Podogrocki
Sent: Monday, November 23, 2020 2:47 AM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c
 
Hi Nikolaus,
 
I assume that your MCU allows alternative SDA/SCL configurations but not simultaneous, i.e. you can decide on which SDA/SCL pair of pins you can have I2C bus, but not on all pairs at the same time.
 
Cheers,
Adam
 
On Sat, 21 Nov 2020 at 00:52, Nikolaus Huber <nikolaus.huber@...> wrote:
Hej,  
 
Thanks for your reply! The specific chip on that board has two I2C peripherals. However, all the sensors I’m interested in are on one (i2c_1). The chip allows routing the same I2C peripheral to multiple pins, i.e. the same SDA and SCL line is available on different pins. Every set of (SDA, SCL) pins still needs to be configured though. For the two pins that are listed in the device tree (the one in the board.dts file just uses those that are connected to one specific sensor), this happens in the init function of the i2c driver. The other pins (which are theoretically also connected to that I2C peripheral) are thus never configured, therefore any sensors connected to them won’t work. I could probably configure those pins manually, but then that solution doesn’t seem very nice (i.e. I would need to adjust the device tree according to which set of sensors I want to reach for each application). So what I’m trying to achieve is, that whenever I do something like i2c_write(i2c_1_dev, …) this actually happens on all pins, that are connected to the i2c_1 peripheral. 
 
 
I’m asking if anyone maybe had a similar situation (it is the first time for me that a microcontroller allows routing the same signal to multiple pins), and how to do this so that it plays nicely with the zephyr API. 
 
Thank’s for your input again!
/Nick


On 21 Nov 2020, at 00:26, Erik Englund <erik.englund@...> wrote:
 
Hi.
 
It´s a bit unclear what you´re asking.
 
Most MCUs require you to define what pins to use for a specific peripheral, in your case i2c_1.
 
If  you have several I2C peripherals(in the MCU) you may connect sensors/other-chips to whatever pins are configurable to that peripheral.
 
Please elaborate what the problem is.
 
 

Med vänlig hälsning
Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA

+46(0)707319440
Org.nr. 556790-2977
www.innoware.se
 








När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ 

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy
Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

Lawrence King
 

Hi Nikolaus

 

I have yet to see a SOC that allows connecting one internal I2C controller to two sets of external pins at one time. Although theoretically possible it would be an unusual feature, and of very limited use. The usual solution is to have multiple I2C controllers in the SOC, and allow routing of each controller to various pins on the SOC package.

 

I just had a quick read through the Mighty Gecko datasheet. The processor has two I2C controllers, which in Zephyr parlance will be I2C_1 and I2C_2. You need to define both controllers and their physical pins in your device tree overlay. Then your software must open both controllers, and you must communicate with your peripherals through the correct I2C controller.

 

Hope this helps.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Adam Podogrocki
Sent: Monday, November 23, 2020 2:47 AM
To: Nikolaus Huber <nikolaus.huber@...>
Cc: Erik Englund <erik.englund@...>; users@...
Subject: Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

 

Hi Nikolaus,

 

I assume that your MCU allows alternative SDA/SCL configurations but not simultaneous, i.e. you can decide on which SDA/SCL pair of pins you can have I2C bus, but not on all pairs at the same time.

 

Cheers,

Adam

 

On Sat, 21 Nov 2020 at 00:52, Nikolaus Huber <nikolaus.huber@...> wrote:

Hej, 

 

Thanks for your reply! The specific chip on that board has two I2C peripherals. However, all the sensors I’m interested in are on one (i2c_1). The chip allows routing the same I2C peripheral to multiple pins, i.e. the same SDA and SCL line is available on different pins. Every set of (SDA, SCL) pins still needs to be configured though. For the two pins that are listed in the device tree (the one in the board.dts file just uses those that are connected to one specific sensor), this happens in the init function of the i2c driver. The other pins (which are theoretically also connected to that I2C peripheral) are thus never configured, therefore any sensors connected to them won’t work. I could probably configure those pins manually, but then that solution doesn’t seem very nice (i.e. I would need to adjust the device tree according to which set of sensors I want to reach for each application). So what I’m trying to achieve is, that whenever I do something like i2c_write(i2c_1_dev, …) this actually happens on all pins, that are connected to the i2c_1 peripheral. 

 

 

I’m asking if anyone maybe had a similar situation (it is the first time for me that a microcontroller allows routing the same signal to multiple pins), and how to do this so that it plays nicely with the zephyr API. 

 

Thank’s for your input again!

/Nick



On 21 Nov 2020, at 00:26, Erik Englund <erik.englund@...> wrote:

 

Hi.

 

It´s a bit unclear what you´re asking.

 

Most MCUs require you to define what pins to use for a specific peripheral, in your case i2c_1.

 

If  you have several I2C peripherals(in the MCU) you may connect sensors/other-chips to whatever pins are configurable to that peripheral.

 

Please elaborate what the problem is.

 

 


Med vänlig hälsning

Erik Englund


Innoware Development AB
Hyttvägen 13
73338 SALA

+46(0)707319440
Org.nr. 556790-2977
www.innoware.se

 









När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy

Re: Private: Re: [Zephyr-users] Same I2C bus on different pins #driver #i2c

Adam Podogrocki
 

Hi Nikolaus,

I assume that your MCU allows alternative SDA/SCL configurations but not simultaneous, i.e. you can decide on which SDA/SCL pair of pins you can have I2C bus, but not on all pairs at the same time.

Cheers,
Adam


On Sat, 21 Nov 2020 at 00:52, Nikolaus Huber <nikolaus.huber@...> wrote:
Hej, 

Thanks for your reply! The specific chip on that board has two I2C peripherals. However, all the sensors I’m interested in are on one (i2c_1). The chip allows routing the same I2C peripheral to multiple pins, i.e. the same SDA and SCL line is available on different pins. Every set of (SDA, SCL) pins still needs to be configured though. For the two pins that are listed in the device tree (the one in the board.dts file just uses those that are connected to one specific sensor), this happens in the init function of the i2c driver. The other pins (which are theoretically also connected to that I2C peripheral) are thus never configured, therefore any sensors connected to them won’t work. I could probably configure those pins manually, but then that solution doesn’t seem very nice (i.e. I would need to adjust the device tree according to which set of sensors I want to reach for each application). So what I’m trying to achieve is, that whenever I do something like i2c_write(i2c_1_dev, …) this actually happens on all pins, that are connected to the i2c_1 peripheral. 
 

I’m asking if anyone maybe had a similar situation (it is the first time for me that a microcontroller allows routing the same signal to multiple pins), and how to do this so that it plays nicely with the zephyr API. 

Thank’s for your input again!
/Nick

On 21 Nov 2020, at 00:26, Erik Englund <erik.englund@...> wrote:

Hi.

It´s a bit unclear what you´re asking.

Most MCUs require you to define what pins to use for a specific peripheral, in your case i2c_1.

If  you have several I2C peripherals(in the MCU) you may connect sensors/other-chips to whatever pins are configurable to that peripheral.

Please elaborate what the problem is.



Med vänlig hälsning
Erik Englund

Innoware Development AB
Hyttvägen 13
73338 SALA

+46(0)707319440
Org.nr. 556790-2977
www.innoware.se









När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy

BSD Sockets and poll-triggered work items #networking #api

valentin.plotkin@...
 

Hi,

Is there currently any way to trigger a work item when a message arrives to a BSD socket (without creating a new thread)? From the documentation it looks like there are two polling methods (k_poll() and zsock_poll()) and these two are not compatible, i. e. k_poll() cannot query sockets. Is it true, and is there any workaround other than having a dedicated thread handle sockets?

Thanks to everyone,

Valentin Plotkin
Re: [Zephyr-devel] Zephyr SDK 0.12.0-beta-2 available for testing

Katsuhiro Suzuki <katsuhiro@...>
 

Hello,

Thanks for great works! I'm trying:
zephyr-toolchain-riscv64-0.12.0-beta-2-x86_64-linux-setup.run

Currently, it works fine for me.

Best Regards,
Katsuhiro Suzuki

On 2020/11/20 2:02, Kumar Gala wrote:
Hi,
Latest version of the SDK can be found here:
https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-beta-2
Please download and try things out and report any issues. Please report issues here:
https://github.com/zephyrproject-rtos/sdk-ng/issues
Known issues (these are on the Zephyr side):
* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]
* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]
Changes since the last release (beta-1):
• Enable multilibs for SPARC LEON
• DWARF binutils bug fix
• Update to openocd 20201109 snapshot
Current plan is to release SDK 0.12.0 towards the end of November.
- k
Zephyr SDK 0.12.0-beta-2 available for testing

Kumar Gala
 

Hi,

Latest version of the SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.12.0-beta-2

Please download and try things out and report any issues. Please report issues here:

https://github.com/zephyrproject-rtos/sdk-ng/issues

Known issues (these are on the Zephyr side):

* some xtensa platforms may need updating w/regards to Zephyr & Xtensa HAL
[ https://github.com/zephyrproject-rtos/zephyr/pull/23142 ]

* known issue with arm64 and linking C++ & newlib:
[ https://github.com/zephyrproject-rtos/zephyr/issues/28650 ]

Changes since the last release (beta-1):

• Enable multilibs for SPARC LEON
• DWARF binutils bug fix
• Update to openocd 20201109 snapshot


Current plan is to release SDK 0.12.0 towards the end of November.

- k
Build zephyr with Metaware toolchain

jacob.avraham@...
 

Hi,
I'm trying to build the hello_world example from Zephyr 2.4.0 release to the ARC HSDK board using my installed MetaWare toolchain, but the build fails.
I did so by setting the environment variable ZEPHYR_TOOLCHAIN_VARIANT to arcmwdt and ARCMWDT_TOOLCHAIN_PATH to $METAWARE_ROOT/../  per the instructions in the Zephyr documentation.
It seems that the code is compiled for the ARC EM processor instead of the ARC HS, and at some point the compilation fails.

Does anyone have any experience in building with the Metaware toolchain for an ARC EVK board that can shed some light here?

Thanks,
Jacob
API meeting cancelled today

Carles Cufi
 

Hi all,

Due to a conflict I have had to cancel the API meeting today.
Next week we will have the meeting as usual.

Regards,

Carles
new facility for formatted output

Peter A. Bigot
 

With the merge of https://github.com/zephyrproject-rtos/zephyr/pull/29876 Zephyr printk, shell_printf, minimal libc sprintf, and some other in-tree facilities use a common formatting functionality that supports almost everything in C18 *printf, with Kconfig options to reduce the code size impact based on controlling feature availability.

That PR added a C99 stdio value formatter capability named cbprintf() (plus related variants) where generated text is emitted through a callback. This allows generation of arbitrarily long output without a buffer, functionality that is core to printk, logging, and other system and application needs.

The formater supports most C99 specifications, excluding:
  • %L[aefg] long double conversion
  • wide character output
The new solution is derived from z_prf(), which had the most complete functionality available. Format parsing has been reimplemented, while floating point conversion has been retained and enhanced.

Kconfig options allow disabling features like floating-point conversion if they are not necessary.

Benefits include:No more inconsistencies between printk, logging, and shell formatting capabilities.
  • Reduced inconsistencies due to toolchain libc capabilities.
  • Simplified (toolchain-independent) formatting feature selection via Kconfig.
  • Core infrastructure can avoid duplication with libc printf by using cbprintf variants.
  • Potentially a path to resolving #18351 and related issues, as the infrastructure can tell a caller the total size of arguments to the conversion string.
  • Fixed bugs with several specifications.
Costs include:
  • Applications that used only printk with no extra features consume more code space than the previous implementation.
More information is available at: https://docs.zephyrproject.org/latest/reference/misc/formatted_output.html

You may see either an increase or a decrease in code size depending on what your application uses.  Some code size can be reduced by switching in-tree use of snprintf to snprintfcb to avoid pulling in libc formatters.

I expect there'll be a burn-in period while we identify Kconfig settings that have to change to maintain compatibility.  Please mention me (@pabigot) in any issues or slack questions that you have about this.

Peter

Re: Nucleo STM32F411RE PWM support

Florian Hester
 

Hello,

I have experimented a bit more, and have opened a bug report:

https://github.com/zephyrproject-rtos/zephyr/issues/30014

Thanks for the help so far :)

Florian

Op 13/11/2020 om 14:28 schreef Erwan Gouriou:

Thanks for feedback.

 I don't see a particular reason why some channels would not work.
For pins, there's alway a possibility of pin conflicts (as I can see that pa8 is also used on i2c2).
So please take care to this.

Otherwise, don't hesitate to raise a bug if things don't work as expected.

Erwan




On Thu, 12 Nov 2020 at 18:37, Florian Hester <florian@celaeno.org <mailto:florian@celaeno.org>> wrote:

Hello,

I've added the pin PA8 to PWM of timers1:

timers1: timers@40010000 {
             status = "okay";

             pwm {
                 status = "okay";
                 pinctrl-0 = <&tim1_ch1_pwm_pa8>;
             };
  };

This did not work (no output pulse, no error logged either).

However, the PA5 pin (configured like above for PWM of timers2) did
work, and now i have a nice 100 microsecond period pulse on that pin.

I've tried the second channel (tim1_ch2_pwm_pa9) of the first
timer, but
that one (like the first channel) also does not work (no output
pulse).

Im going try more of the PWM channels, to see what is working and
what
is not, but it seems like the first pwm device (PWM_1, as part of
timers1) is not working, any reason why not?

Florian

Op 12/11/2020 om 17:03 schreef Erwan Gouriou:
> Hi Florian,
>
> You also need to configure a pin, something like:
> &timers2 {
>            status = "okay";
>
>            pwm2: pwm {
>            status = "okay";
> +           pinctrl-0 = <&tim2_ch1_pwm_pa5>;
>            };
> };
>
> Please let us know if this was helpful.
>
> Erwan
>
> On Thu, 12 Nov 2020 at 13:58, Florian Hester via
> lists.zephyrproject.org <http://lists.zephyrproject.org>
<http://lists.zephyrproject.org <http://lists.zephyrproject.org>>
> <florian=celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>
> <mailto:celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>>> wrote:
>
>     Hello,
>
>     I have used the following overlay:
>
>     / {
>          soc {
>              timers1: timers@40010000 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>
>              timers2: timers@40000000 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>
>              timers3: timers@40000400 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>
>              timers4: timers@40000800 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>          };
>     };
>
>     The prj.conf file contains the following regarding PWM:
>
>     CONFIG_PWM=y
>     CONFIG_PWM_STM32=y
>
>     I used the following code to test:
>
>          auto dev_pwm = device_get_binding("PWM_1");
>
>          if (dev_pwm != nullptr)
>          {
>              LOG_INF("Have PWM device.");
>
>              int ret = pwm_pin_set_usec(dev_pwm, 1, 100, 50, 0);
>
>              if (ret != 0)
>              {
>                  LOG_ERR("Could not set PWM.");
>              }
>              else
>              {
>                  LOG_INF("PWM set.");
>              }
>          }
>
>     The output:
>
>     [00:00:00.006,000] <inf> main: Have PWM device.
>     [00:00:00.006,000] <inf> main: PWM set.
>
>     I am measuring pin D7 on the board (PA8 for the chip), and
no pulse.
>
>     Florian
>
>     Op 12/11/2020 om 08:36 schreef Adam Podogrocki:
>     > Hi Florian,
>     >
>     > have you set /status/ of the appropriate Timer & PWM device to
>     "okay"?
>     > Have you activated the PWM driver in Zephyr Menu Config?
Have you
>     > successfully got device binding in the source code?
>     >
>     > Cheers,
>     > Adam
>     >
>     > On Thu, 12 Nov 2020 at 01:54, Florian Hester via
>     > lists.zephyrproject.org <http://lists.zephyrproject.org>
<http://lists.zephyrproject.org <http://lists.zephyrproject.org>>
>     <http://lists.zephyrproject.org
<http://lists.zephyrproject.org> <http://lists.zephyrproject.org
<http://lists.zephyrproject.org>>>
>     > <florian=celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>
>     <mailto:celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>>
>     > <mailto:celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>
>     <mailto:celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>>>> wrote:
>     >
>     >     Hello,
>     >
>     >     When i look at the documentation of the Nucleo F411RE
board at:
>     >
>     >
>
https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
<https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>
>   
 <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
<https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>>
>     >
>   
  <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
<https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>
>   
 <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
<https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>>>
>     >
>     >     I can see PWM as a supported feature. However,  the board
>     YAML file
>     >     (boards/arm/nucleo_f411re.yml) does not list PWM as
>     supported and the
>     >     board DTS (boards/arm/nucleo_f411re/nucleo_f411re.dts)
does not
>     >     enable
>     >     any PWM device present on the hardware.
>     >
>     >     I've tried using an overlay to enable it anyway (the
timers
>     and the
>     >     pwms), this compiles successfully and flashes (via JLink)
>     >     successfully,
>     >     but using the PWM API (or the shell pwm commands) does not
>     appear to
>     >     have any effect (no output pulse).
>     >
>     >     I have tried the PWM functionality in ARM mbed, where
it works.
>     >
>     >     Why does Zephyr not have support for PWM on this board?
>     >
>     >
>     >     Florian
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>
>
>     
>
>
Warning from MCUboot: Not enough space to run swap upgrade #nrf52832 #mcuboot #fota

namor.dev@...
 

Dear All,
 
I'm using the nRF Connect SDK and try to do a FOTA upgrade to my nRF52832, with MCUboot installed.
After I downloaded the binary via nRF Connect Android App to the device, i get "<wrn> mcuboot: Not enough free space to run swap upgrade".
And the device continues to start with the old image.
 
Here is my setup:
- nRF Connect SDK v1.2.0 (Zephyr v2.1.99, mcuboot v1.4.99)
- nRF52-DK (nRF52832)
- Windows 8.1
 
I did not modify the flash partitions in the device tree (default values from nrf52_pca10040.dts) and also no changes in MCUboot configuration (boot/zephyr/prj.conf).
 
These are the steps I did:
2. Build it with west (which automatically builds the bootloader and signs my application as far is I understood).
3. Flash the merged.hex (which includes also the bootloader) to device with JLink
4. Do some changes and build an update of my application. This is the output (tail) of "west build -b nrf52_pca10040":
 
…
[230/241] Building C object zephyr/kernel/CMakeFiles/kernel.dir/poll.c.obj
[231/241] Linking C static library zephyr\kernel\libkernel.a
[232/241] Linking C executable zephyr\zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      229348 B     232960 B     98.45%
            SRAM:       57060 B        64 KB     87.07%
        IDT_LIST:         168 B         2 KB      8.20%
[233/241] Generating linker_pass_final.cmd
[234/241] Generating isr_tables.c
[235/241] Building C object zephyr/CMakeFiles/zephyr_final.dir/misc/empty_file.c.obj
[236/241] Building C object zephyr/CMakeFiles/zephyr_final.dir/isr_tables.c.obj
[237/241] Linking C executable zephyr\zephyr.elf
[238/241] Generating zephyr/mcuboot_primary.hex
[239/241] Generating zephyr/mcuboot_primary_app.hex
[240/241] Generating ../../zephyr/app_update.bin, ../../zephyr/app_signed.hex, ../../zephyr/app_test_update.hex, ../../zephyr/app_moved_test_update.hex
[241/241] Generating zephyr/merged.hex
 
 
5. Perform the update with nRF Connect App and app_update.bin. Transfer worked well but after the device resets, I got the following output with the previously described warning:
*** Booting Zephyr OS build v2.1.99-ncs1  ***
[00:00:00.003,326] <inf> mcuboot: Starting bootloader
[00:00:00.009,704] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.020,385] <inf> mcuboot: Boot source: none
[00:00:00.026,184] <inf> mcuboot: Swap type: test
[00:00:00.356,567] <wrn> mcuboot: Not enough free space to run swap upgrade
[00:00:00.684,509] <inf> mcuboot: Bootloader chainload address offset: 0xc000
[00:00:00.692,474] <inf> mcuboot: Jumping to the first image slot
 
 
I know, the FLASH usage of 98% is bad. Interestingly enough, when I build in Segger Embedded Studio, FLASH usage of 43% is displayed. Is this because I only see the size of my application (not the merged one)?
When I disable some modules to decrease the memory footprint, the FOTA update works well! But then my application has not it's full functionality.
 
Has anyone some ideas I can do? Do I need to modify the device tree or the mcuboot configuration? Why does it not work, altough the FLASH is not 100% full?
 
Any help is appreciated.
Roman
 
Re: Nucleo STM32F411RE PWM support

Erwan Gouriou
 

Thanks for feedback.

 I don't see a particular reason why some channels would not work.
For pins, there's alway a possibility of pin conflicts (as I can see that pa8 is also used on i2c2).
So please take care to this.

Otherwise, don't hesitate to raise a bug if things don't work as expected.

Erwan




On Thu, 12 Nov 2020 at 18:37, Florian Hester <florian@...> wrote:
Hello,

I've added the pin PA8 to PWM of timers1:

timers1: timers@40010000 {
             status = "okay";

             pwm {
                 status = "okay";
                 pinctrl-0 = <&tim1_ch1_pwm_pa8>;
             };
  };

This did not work (no output pulse, no error logged either).

However, the PA5 pin (configured like above for PWM of timers2) did
work, and now i have a nice 100 microsecond period pulse on that pin.

I've tried the second channel (tim1_ch2_pwm_pa9) of the first timer, but
that one (like the first channel) also does not work (no output pulse).

Im going try more of the PWM channels, to see what is working and what
is not, but it seems like the first pwm device (PWM_1, as part of
timers1) is not working, any reason why not?

Florian

Op 12/11/2020 om 17:03 schreef Erwan Gouriou:
> Hi Florian,
>
> You also need to configure a pin, something like:
> &timers2 {
>            status = "okay";
>
>            pwm2: pwm {
>            status = "okay";
> +           pinctrl-0 = <&tim2_ch1_pwm_pa5>;
>            };
> };
>
> Please let us know if this was helpful.
>
> Erwan
>
> On Thu, 12 Nov 2020 at 13:58, Florian Hester via
> lists.zephyrproject.org <http://lists.zephyrproject.org>
> <florian=celaeno.org@...
> <mailto:celaeno.org@...>> wrote:
>
>     Hello,
>
>     I have used the following overlay:
>
>     / {
>          soc {
>              timers1: timers@40010000 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>
>              timers2: timers@40000000 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>
>              timers3: timers@40000400 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>
>              timers4: timers@40000800 {
>                  status = "okay";
>
>                  pwm {
>                      status = "okay";
>                  };
>              };
>          };
>     };
>
>     The prj.conf file contains the following regarding PWM:
>
>     CONFIG_PWM=y
>     CONFIG_PWM_STM32=y
>
>     I used the following code to test:
>
>          auto dev_pwm = device_get_binding("PWM_1");
>
>          if (dev_pwm != nullptr)
>          {
>              LOG_INF("Have PWM device.");
>
>              int ret = pwm_pin_set_usec(dev_pwm, 1, 100, 50, 0);
>
>              if (ret != 0)
>              {
>                  LOG_ERR("Could not set PWM.");
>              }
>              else
>              {
>                  LOG_INF("PWM set.");
>              }
>          }
>
>     The output:
>
>     [00:00:00.006,000] <inf> main: Have PWM device.
>     [00:00:00.006,000] <inf> main: PWM set.
>
>     I am measuring pin D7 on the board (PA8 for the chip), and no pulse.
>
>     Florian
>
>     Op 12/11/2020 om 08:36 schreef Adam Podogrocki:
>     > Hi Florian,
>     >
>     > have you set /status/ of the appropriate Timer & PWM device to
>     "okay"?
>     > Have you activated the PWM driver in Zephyr Menu Config? Have you
>     > successfully got device binding in the source code?
>     >
>     > Cheers,
>     > Adam
>     >
>     > On Thu, 12 Nov 2020 at 01:54, Florian Hester via
>     > lists.zephyrproject.org <http://lists.zephyrproject.org>
>     <http://lists.zephyrproject.org <http://lists.zephyrproject.org>>
>     > <florian=celaeno.org@...
>     <mailto:celaeno.org@...>
>     > <mailto:celaeno.org@...
>     <mailto:celaeno.org@...>>> wrote:
>     >
>     >     Hello,
>     >
>     >     When i look at the documentation of the Nucleo F411RE board at:
>     >
>     >
>     https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
>     <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>
>     >   
>      <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
>     <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>>
>     >
>     >     I can see PWM as a supported feature. However,  the board
>     YAML file
>     >     (boards/arm/nucleo_f411re.yml) does not list PWM as
>     supported and the
>     >     board DTS (boards/arm/nucleo_f411re/nucleo_f411re.dts) does not
>     >     enable
>     >     any PWM device present on the hardware.
>     >
>     >     I've tried using an overlay to enable it anyway (the timers
>     and the
>     >     pwms), this compiles successfully and flashes (via JLink)
>     >     successfully,
>     >     but using the PWM API (or the shell pwm commands) does not
>     appear to
>     >     have any effect (no output pulse).
>     >
>     >     I have tried the PWM functionality in ARM mbed, where it works.
>     >
>     >     Why does Zephyr not have support for PWM on this board?
>     >
>     >
>     >     Florian
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>
>
>     
>
>
Debugging Zephyr using no able to stop at specific source line after init.c #debugging

ngbk1993@...
 
Edited


Hi All,

I'm trying to enable Zephyr with a SoC(4-cores CPU) that not listed in the Zephyr page.

Currently I'm able to step the code using the ARM Development studio and able to step (single step)
until the source line at zephyrproject/zephyr/kernel/init.c:233  (printk(*** Botting Zephyr OS Build .......))

The zephyr will always jump to system halt when i'm trying to
1) Set a break point after the line 233 
2) Stepping source line 

When I try to single step, it can go very far beyond line of init.c:233.

Then I try to edit the init.c and place a forever while loop before line:233, hopefully the program will help me to stop at line 233 without me to do a single step for debug, but still no luck, zephyr will still jump into system halt.

Want to ask Is there any watchdog timer implemented on zephyr that check if zephyr hang?

Regards,
ngbk

PS: Sorry for the incomplete title, Debugging Zephyr using ARMDS and not able to stop at specific source line after init.c
Re: Nucleo STM32F411RE PWM support

Florian Hester
 

Hello,

I've added the pin PA8 to PWM of timers1:

timers1: timers@40010000 {
            status = "okay";

            pwm {
                status = "okay";
                pinctrl-0 = <&tim1_ch1_pwm_pa8>;
            };
 };

This did not work (no output pulse, no error logged either).

However, the PA5 pin (configured like above for PWM of timers2) did work, and now i have a nice 100 microsecond period pulse on that pin.

I've tried the second channel (tim1_ch2_pwm_pa9) of the first timer, but that one (like the first channel) also does not work (no output pulse).

Im going try more of the PWM channels, to see what is working and what is not, but it seems like the first pwm device (PWM_1, as part of timers1) is not working, any reason why not?

Florian

Op 12/11/2020 om 17:03 schreef Erwan Gouriou:

Hi Florian,

You also need to configure a pin, something like:
&timers2 {
           status = "okay";

           pwm2: pwm {
           status = "okay";
+           pinctrl-0 = <&tim2_ch1_pwm_pa5>;
           };
};

Please let us know if this was helpful.

Erwan

On Thu, 12 Nov 2020 at 13:58, Florian Hester via lists.zephyrproject.org <http://lists.zephyrproject.org> <florian=celaeno.org@lists.zephyrproject.org <mailto:celaeno.org@lists.zephyrproject.org>> wrote:

Hello,

I have used the following overlay:

/ {
     soc {
         timers1: timers@40010000 {
             status = "okay";

             pwm {
                 status = "okay";
             };
         };

         timers2: timers@40000000 {
             status = "okay";

             pwm {
                 status = "okay";
             };
         };

         timers3: timers@40000400 {
             status = "okay";

             pwm {
                 status = "okay";
             };
         };

         timers4: timers@40000800 {
             status = "okay";

             pwm {
                 status = "okay";
             };
         };
     };
};

The prj.conf file contains the following regarding PWM:

CONFIG_PWM=y
CONFIG_PWM_STM32=y

I used the following code to test:

     auto dev_pwm = device_get_binding("PWM_1");

     if (dev_pwm != nullptr)
     {
         LOG_INF("Have PWM device.");

         int ret = pwm_pin_set_usec(dev_pwm, 1, 100, 50, 0);

         if (ret != 0)
         {
             LOG_ERR("Could not set PWM.");
         }
         else
         {
             LOG_INF("PWM set.");
         }
     }

The output:

[00:00:00.006,000] <inf> main: Have PWM device.
[00:00:00.006,000] <inf> main: PWM set.

I am measuring pin D7 on the board (PA8 for the chip), and no pulse.

Florian

Op 12/11/2020 om 08:36 schreef Adam Podogrocki:
> Hi Florian,
>
> have you set /status/ of the appropriate Timer & PWM device to
"okay"?
> Have you activated the PWM driver in Zephyr Menu Config? Have you
> successfully got device binding in the source code?
>
> Cheers,
> Adam
>
> On Thu, 12 Nov 2020 at 01:54, Florian Hester via
> lists.zephyrproject.org <http://lists.zephyrproject.org>
<http://lists.zephyrproject.org <http://lists.zephyrproject.org>>
> <florian=celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>
> <mailto:celaeno.org@lists.zephyrproject.org
<mailto:celaeno.org@lists.zephyrproject.org>>> wrote:
>
>     Hello,
>
>     When i look at the documentation of the Nucleo F411RE board at:
>
>
https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
<https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>
>   
 <https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html
<https://docs.zephyrproject.org/latest/boards/arm/nucleo_f411re/doc/index.html>>
>
>     I can see PWM as a supported feature. However,  the board
YAML file
>     (boards/arm/nucleo_f411re.yml) does not list PWM as
supported and the
>     board DTS (boards/arm/nucleo_f411re/nucleo_f411re.dts) does not
>     enable
>     any PWM device present on the hardware.
>
>     I've tried using an overlay to enable it anyway (the timers
and the
>     pwms), this compiles successfully and flashes (via JLink)
>     successfully,
>     but using the PWM API (or the shell pwm commands) does not
appear to
>     have any effect (no output pulse).
>
>     I have tried the PWM functionality in ARM mbed, where it works.
>
>     Why does Zephyr not have support for PWM on this board?
>
>
>     Florian
>
>
>
>
>
>
>
>
201 - 220 of 2543