Re: interrupt priorities on nRF52
As Greg mentioned in the corresponding open issue, TizenRT took Greg's snippets from the Wiki page and mostly implemented that. Couldn't really find more changes than that, so I'm not sure if it is actually used on TizenRT or they managed to make the change relatively simple. I don't quite grasp the complexity (beyond the fact that it requires consideration of what the high priority interrupts will do that may affect lower priority interrupts being executed) so I'm not sure if I would be the right person to try this, but if anyone feels motivated I could help. Regarding critical sections, shouldn't there then be an argument to enter_critical_section() that specifies which interrupts priorities to disable and which not? And regardless of priorities, now that we talk about this, wouldn't be useful to be able to choose which interrupts to disable for a given critical section? Many uses of enter_critical_section() actually try to protect the enclosed code from changes from a specific ISR so it seems wasteful to disable all interrupts. Best, Matias On Mon, Oct 26, 2020, at 10:21, David Sidrane wrote: > > But the priority difference doesn't imply that the nested interrupt > > happens > automatically, you have to enable the interrupt manually after the critical > CPU register and OS state is saved. > > My recollection is it depends on the priority assigned to the interrupt and > the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The system > will crash due to reentrancy on the common vector, if the values, and vector > are not managed properly. > > > -Original Message- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Sunday, October 25, 2020 11:27 PM > To: dev@nuttx.apache.org > Subject: Re: interrupt priorities on nRF52 > > On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > > > Hi, > > while working on nRF52 BLE link-layer I experienced some problems due to > > delayed ISRs. This can be quite problematic > > for handling all the tight timings required by the standard. I eventually > > reached an implementation that can deal with this relatively well (BLE > > standard gives some leeway for some small number of dropped packets and > > also retransmits missing ones). However, as other peripherals start > > generating more interrupts, this could actually become a problem. Also, I > > think it would be good to know BLE ISRs will always have priority. > > > > I've been looking into how ISRs can be prioritized but I don't have much > > experience with this, so I have some questions: > > * Does nRF52 need explicit support for handling interrupts with different > > priorities or is the support supposed to be taken care of at the ARM level > > code? > > * How well supported is this in nRF52/ARM? > > > > You can call up_prioritize_irq(at least Cortex-M implement it) to change > the ISR priority. > > > > * Do interrupt priorities imply nested interrupts? It isn't clear to me if > > priorities only mean which ISR will get served first when they are pending > > together or if it also implies that a low priority > > > But the priority difference doesn't imply that the nested interrupt happens > automatically, you have to enable the interrupt manually after the critical > CPU register and OS state is saved. > > interrupt can be interrupted to handle a higher priority one (I believe the > > latter is what is usually refered to as "nested interrupts") > > * How does enter_critical_section() deal with priorities? How do I know > > which priority is masked and which one isn't? > > > > The critical section always mask all interrupts, but there is a special > feature(Zero Latency Interrupts) on Cortex-M: > https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts > We enable this feature to fix the same issue two years ago. > But many code abuses the critical section and sched lock in many places, we > should address these problems gradually by: > 1.Replace the critical section to semaphore if suitable > 2.Replace the critical section to spin lock if suitable > 3.Break the large critical section into several small one > These changes not only reduce the interrupt latency, but also increase the > performance in the SMP case. > > > > * Which configs should I enable to try this? > > > > Thanks, > > Matias > > > On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > > > Hi, > > while working on nRF52 BLE link-layer I experienced some problems due to > > delayed ISRs. This can be quite problematic > > for handling all the tight timings required by the standard. I eventually > > reached an implementation that can deal with this relatively well (BLE > > standard gives some leeway for some small number of dropped packets and > > also retransmits missing ones). However, as other peripherals start > > generating more interrupts, this could actually become a problem. Also, I > > think it would be good to know BLE ISRs will always have
Re: sim target failures 10.0 branch
That would be awesome. I actually started writing a tool to help with this process but deferred to the spreadsheet to get this release done. Only the project scaffolding and logo is done but here it is for reference: https://github.com/btashton/nuttx-testnom My idea there is to have a webapp where people can grab artifacts to test and then submit a test report without having to go through the full build process themselves (certainly can). It would also do some level of automated tracking like showing resource usage and tracking that over time. --Brennan On Mon, Oct 26, 2020, 10:57 AM Maciej Wójcik wrote: > Hi Brennan, > > I would gladly join you with checking some of the boards in this table. > > For example I have some nostalgic relation with `hymini-stm32v` my first > board :D > > Just removed the dust from it and flashed with NuttX 10. It is almost > working :) > > (it was hanging on the missing SD card for a minute, what it shouldn't be > doing, but started afterwards and displayed the NuttX logo) > > Maybe we could come up with a concept of board maintainers (people > who check few boards of choice before release). > > There would be a table in documentation with a list of boards and > maintainers on the side. It would be visible which are the orphans and > maybe people would pick them over time. > > Am So., 25. Okt. 2020 um 01:35 Uhr schrieb Brennan Ashton < > bash...@brennanashton.com>: > > > In preparation for cutting the release I started running all of the > > simulation targets before digging into more hardware testing. There > > were quite a few failures, it is possible that some are environment > > related, in which case we should document them better, but some look > > like clear bugs. I would like to see these addressed or at the very > > least acknowledged before we cut the release. > > > > > > > https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+label%3Areleases%2F10.0.0++label%3Ablocker > > > > You can also see my testing sheet here: > > > > > https://docs.google.com/spreadsheets/d/1qMQV_CSN5Ka13_wr73QNo2Uh-NiSumjcwINuc0BkyIs/edit?usp=sharing > > > > I commit for the 10.1 release wiring up actual integration testing for > > these so we have better automation validation beyond just "it > > compiles" > > > > --Brennan > > >
Re: sim target failures 10.0 branch
Hi Brennan, I would gladly join you with checking some of the boards in this table. For example I have some nostalgic relation with `hymini-stm32v` my first board :D Just removed the dust from it and flashed with NuttX 10. It is almost working :) (it was hanging on the missing SD card for a minute, what it shouldn't be doing, but started afterwards and displayed the NuttX logo) Maybe we could come up with a concept of board maintainers (people who check few boards of choice before release). There would be a table in documentation with a list of boards and maintainers on the side. It would be visible which are the orphans and maybe people would pick them over time. Am So., 25. Okt. 2020 um 01:35 Uhr schrieb Brennan Ashton < bash...@brennanashton.com>: > In preparation for cutting the release I started running all of the > simulation targets before digging into more hardware testing. There > were quite a few failures, it is possible that some are environment > related, in which case we should document them better, but some look > like clear bugs. I would like to see these addressed or at the very > least acknowledged before we cut the release. > > > https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+label%3Areleases%2F10.0.0++label%3Ablocker > > You can also see my testing sheet here: > > https://docs.google.com/spreadsheets/d/1qMQV_CSN5Ka13_wr73QNo2Uh-NiSumjcwINuc0BkyIs/edit?usp=sharing > > I commit for the 10.1 release wiring up actual integration testing for > these so we have better automation validation beyond just "it > compiles" > > --Brennan >
Re: Running ifconfig on BeagleboneBlack
Excellent! Thank you Brennan. Though this is not exactly what I was looking for, this will help test build issues, if any. Tomorrow once the patch is ready for 1883, I may have to bug you again on how to test it by mounting/unmounting procfs. Sincerely, Subhra Sankha Sarkar On Mon, Oct 26, 2020 at 10:24 PM Brennan Ashton wrote: > You should be able to use the simulator for testing that if you are using > Linux. There is Windows and macOS support as well but I am not familiar > with using it. > > > http://nuttx.apache.org/docs/latest/guides/simulator.html#accessing-the-network > > Even without setting up the host network side you should be able to verify > your fix. > > --Brennan > > On Mon, Oct 26, 2020, 9:48 AM Subhra Sankha Sarkar > > wrote: > > > Thank you Alan and Brennan for welcoming me to the community and for your > > prompt response. Sure, I shall get in touch with Petro to understand the > > current state of development of the Ethernet driver on BBB and if I can > > help in any way. > > > > I specifically asked for ifconfig because I wanted to test my changes for > > https://github.com/apache/incubator-nuttx/issues/1883. Is there any > other > > way to build and/or test my changes for the issue # 1883 as I don't have > > necessary hardware platform(s)? > > > > Sincerely, > > Subhra Sankha Sarkar > > > > > > On Mon, Oct 26, 2020 at 9:38 PM Alan Carvalho de Assis < > acas...@gmail.com> > > wrote: > > > > > Hi Subhra, > > > > > > Welcome to the NuttX community! > > > > > > Unfortunately we selected a board that doesn't have Ethernet driver, > > > see inside this directory: nuttx/arch/arm/src/am335x/ and you will > > > realize which peripherals are supported to this board. > > > > > > I'm CC Mr. Petro, he is the guy who ported NuttX to BBB, maybe he say > > > if there are plans to add Ethernet. > > > > > > If you want a board with Ethernet support, you can figure out it > > > searching for "netnsh" configuration files inside nuttx/boards/ > > > directory. > > > > > > BR, > > > > > > Alan > > > > > > On 10/26/20, Subhra Sankha Sarkar wrote: > > > > Hello all, > > > > > > > > I just got started with NuttX and was able to build (using the > default > > > > beaglebone-black:nsh configuration) & run the OS on my Beaglebone > Black > > > > (BBB). However, when I checked for the list of commands available on > > it, > > > I > > > > am only seeing a limited subset of what NuttX offers. > > > > > > > > > > > > > > > > > > NuttShell (NSH) NuttX-9.1.0 > > > > nsh> ? > > > > help usage: help [-v] [] > > > > > > > > . cat echo hexdump mkfatfs mwsource > > > > umount > > > > [ cpexec kill mkrd rmtest > > > > unset > > > > ? cmp exit lsmhrmdir time > > > > usleep > > > > basename dirname false mbmount set true > > > xd > > > > > > > > break ddhelp mkdir mvsleep uname > > > > > > > > Builtin Apps: > > > > sh nsh > > > > nsh> > > > > > > > > > > > > > > > > > > In particular, I am interested in the ifconfig command. However, just > > > > setting CONFIG_NET=y and CONFIG_FS_PROCFS=y (per nshlib README) > results > > > in > > > > build failure. Obviously, I'll have to enable a few other CONFIG > > options > > > > through Kconfig. The board specific README file didn't provide much > > > detail > > > > on this matter. > > > > > > > > Could someone please provide me with some pointers or a list of > configs > > > to > > > > enable so I can run the ifconfig (or other networking commands) on my > > > BBB? > > > > > > > > Thank you in advance. > > > > > > > > Sincerely, > > > > Subhra Sankha Sarkar > > > > > > > > > >
Re: Running ifconfig on BeagleboneBlack
You should be able to use the simulator for testing that if you are using Linux. There is Windows and macOS support as well but I am not familiar with using it. http://nuttx.apache.org/docs/latest/guides/simulator.html#accessing-the-network Even without setting up the host network side you should be able to verify your fix. --Brennan On Mon, Oct 26, 2020, 9:48 AM Subhra Sankha Sarkar wrote: > Thank you Alan and Brennan for welcoming me to the community and for your > prompt response. Sure, I shall get in touch with Petro to understand the > current state of development of the Ethernet driver on BBB and if I can > help in any way. > > I specifically asked for ifconfig because I wanted to test my changes for > https://github.com/apache/incubator-nuttx/issues/1883. Is there any other > way to build and/or test my changes for the issue # 1883 as I don't have > necessary hardware platform(s)? > > Sincerely, > Subhra Sankha Sarkar > > > On Mon, Oct 26, 2020 at 9:38 PM Alan Carvalho de Assis > wrote: > > > Hi Subhra, > > > > Welcome to the NuttX community! > > > > Unfortunately we selected a board that doesn't have Ethernet driver, > > see inside this directory: nuttx/arch/arm/src/am335x/ and you will > > realize which peripherals are supported to this board. > > > > I'm CC Mr. Petro, he is the guy who ported NuttX to BBB, maybe he say > > if there are plans to add Ethernet. > > > > If you want a board with Ethernet support, you can figure out it > > searching for "netnsh" configuration files inside nuttx/boards/ > > directory. > > > > BR, > > > > Alan > > > > On 10/26/20, Subhra Sankha Sarkar wrote: > > > Hello all, > > > > > > I just got started with NuttX and was able to build (using the default > > > beaglebone-black:nsh configuration) & run the OS on my Beaglebone Black > > > (BBB). However, when I checked for the list of commands available on > it, > > I > > > am only seeing a limited subset of what NuttX offers. > > > > > > > > > > > > NuttShell (NSH) NuttX-9.1.0 > > > nsh> ? > > > help usage: help [-v] [] > > > > > > . cat echo hexdump mkfatfs mwsource > > > umount > > > [ cpexec kill mkrd rmtest > > > unset > > > ? cmp exit lsmhrmdir time > > > usleep > > > basename dirname false mbmount set true > > xd > > > > > > break ddhelp mkdir mvsleep uname > > > > > > Builtin Apps: > > > sh nsh > > > nsh> > > > > > > > > > > > > In particular, I am interested in the ifconfig command. However, just > > > setting CONFIG_NET=y and CONFIG_FS_PROCFS=y (per nshlib README) results > > in > > > build failure. Obviously, I'll have to enable a few other CONFIG > options > > > through Kconfig. The board specific README file didn't provide much > > detail > > > on this matter. > > > > > > Could someone please provide me with some pointers or a list of configs > > to > > > enable so I can run the ifconfig (or other networking commands) on my > > BBB? > > > > > > Thank you in advance. > > > > > > Sincerely, > > > Subhra Sankha Sarkar > > > > > >
Re: Running ifconfig on BeagleboneBlack
Thank you Alan and Brennan for welcoming me to the community and for your prompt response. Sure, I shall get in touch with Petro to understand the current state of development of the Ethernet driver on BBB and if I can help in any way. I specifically asked for ifconfig because I wanted to test my changes for https://github.com/apache/incubator-nuttx/issues/1883. Is there any other way to build and/or test my changes for the issue # 1883 as I don't have necessary hardware platform(s)? Sincerely, Subhra Sankha Sarkar On Mon, Oct 26, 2020 at 9:38 PM Alan Carvalho de Assis wrote: > Hi Subhra, > > Welcome to the NuttX community! > > Unfortunately we selected a board that doesn't have Ethernet driver, > see inside this directory: nuttx/arch/arm/src/am335x/ and you will > realize which peripherals are supported to this board. > > I'm CC Mr. Petro, he is the guy who ported NuttX to BBB, maybe he say > if there are plans to add Ethernet. > > If you want a board with Ethernet support, you can figure out it > searching for "netnsh" configuration files inside nuttx/boards/ > directory. > > BR, > > Alan > > On 10/26/20, Subhra Sankha Sarkar wrote: > > Hello all, > > > > I just got started with NuttX and was able to build (using the default > > beaglebone-black:nsh configuration) & run the OS on my Beaglebone Black > > (BBB). However, when I checked for the list of commands available on it, > I > > am only seeing a limited subset of what NuttX offers. > > > > > > > NuttShell (NSH) NuttX-9.1.0 > > nsh> ? > > help usage: help [-v] [] > > > > . cat echo hexdump mkfatfs mwsource > > umount > > [ cpexec kill mkrd rmtest > > unset > > ? cmp exit lsmhrmdir time > > usleep > > basename dirname false mbmount set true > xd > > > > break ddhelp mkdir mvsleep uname > > > > Builtin Apps: > > sh nsh > > nsh> > > > > > > > In particular, I am interested in the ifconfig command. However, just > > setting CONFIG_NET=y and CONFIG_FS_PROCFS=y (per nshlib README) results > in > > build failure. Obviously, I'll have to enable a few other CONFIG options > > through Kconfig. The board specific README file didn't provide much > detail > > on this matter. > > > > Could someone please provide me with some pointers or a list of configs > to > > enable so I can run the ifconfig (or other networking commands) on my > BBB? > > > > Thank you in advance. > > > > Sincerely, > > Subhra Sankha Sarkar > > >
Re: Running ifconfig on BeagleboneBlack
Hi Subhra, Welcome to the NuttX community! Unfortunately we selected a board that doesn't have Ethernet driver, see inside this directory: nuttx/arch/arm/src/am335x/ and you will realize which peripherals are supported to this board. I'm CC Mr. Petro, he is the guy who ported NuttX to BBB, maybe he say if there are plans to add Ethernet. If you want a board with Ethernet support, you can figure out it searching for "netnsh" configuration files inside nuttx/boards/ directory. BR, Alan On 10/26/20, Subhra Sankha Sarkar wrote: > Hello all, > > I just got started with NuttX and was able to build (using the default > beaglebone-black:nsh configuration) & run the OS on my Beaglebone Black > (BBB). However, when I checked for the list of commands available on it, I > am only seeing a limited subset of what NuttX offers. > > > NuttShell (NSH) NuttX-9.1.0 > nsh> ? > help usage: help [-v] [] > > . cat echo hexdump mkfatfs mwsource > umount > [ cpexec kill mkrd rmtest > unset > ? cmp exit lsmhrmdir time > usleep > basename dirname false mbmount set true xd > > break ddhelp mkdir mvsleep uname > > Builtin Apps: > sh nsh > nsh> > > > In particular, I am interested in the ifconfig command. However, just > setting CONFIG_NET=y and CONFIG_FS_PROCFS=y (per nshlib README) results in > build failure. Obviously, I'll have to enable a few other CONFIG options > through Kconfig. The board specific README file didn't provide much detail > on this matter. > > Could someone please provide me with some pointers or a list of configs to > enable so I can run the ifconfig (or other networking commands) on my BBB? > > Thank you in advance. > > Sincerely, > Subhra Sankha Sarkar >
Re: Running ifconfig on BeagleboneBlack
Support for ethernet has not been ported to that platform unfortunately, so it is much more than turning on some kconfig options. If you want to use a platform with ethernet support I would look for one with a netnsh configuration. --Brennan On Mon, Oct 26, 2020, 8:48 AM Subhra Sankha Sarkar wrote: > Hello all, > > I just got started with NuttX and was able to build (using the default > beaglebone-black:nsh configuration) & run the OS on my Beaglebone Black > (BBB). However, when I checked for the list of commands available on it, I > am only seeing a limited subset of what NuttX offers. > > > > NuttShell (NSH) NuttX-9.1.0 > nsh> ? > help usage: help [-v] [] > > . cat echo hexdump mkfatfs mwsource > umount > [ cpexec kill mkrd rmtest > unset > ? cmp exit lsmhrmdir time > usleep > basename dirname false mbmount set true xd > > break ddhelp mkdir mvsleep uname > > Builtin Apps: > sh nsh > nsh> > > > > In particular, I am interested in the ifconfig command. However, just > setting CONFIG_NET=y and CONFIG_FS_PROCFS=y (per nshlib README) results in > build failure. Obviously, I'll have to enable a few other CONFIG options > through Kconfig. The board specific README file didn't provide much detail > on this matter. > > Could someone please provide me with some pointers or a list of configs to > enable so I can run the ifconfig (or other networking commands) on my BBB? > > Thank you in advance. > > Sincerely, > Subhra Sankha Sarkar >
Running ifconfig on BeagleboneBlack
Hello all, I just got started with NuttX and was able to build (using the default beaglebone-black:nsh configuration) & run the OS on my Beaglebone Black (BBB). However, when I checked for the list of commands available on it, I am only seeing a limited subset of what NuttX offers. NuttShell (NSH) NuttX-9.1.0 nsh> ? help usage: help [-v] [] . cat echo hexdump mkfatfs mwsource umount [ cpexec kill mkrd rmtest unset ? cmp exit lsmhrmdir time usleep basename dirname false mbmount set true xd break ddhelp mkdir mvsleep uname Builtin Apps: sh nsh nsh> In particular, I am interested in the ifconfig command. However, just setting CONFIG_NET=y and CONFIG_FS_PROCFS=y (per nshlib README) results in build failure. Obviously, I'll have to enable a few other CONFIG options through Kconfig. The board specific README file didn't provide much detail on this matter. Could someone please provide me with some pointers or a list of configs to enable so I can run the ifconfig (or other networking commands) on my BBB? Thank you in advance. Sincerely, Subhra Sankha Sarkar
RE: interrupt priorities on nRF52
> But the priority difference doesn't imply that the nested interrupt > happens automatically, you have to enable the interrupt manually after the critical CPU register and OS state is saved. My recollection is it depends on the priority assigned to the interrupt and the fence level used (NVIC_SYSH_DISABLE_PRIORITY) on the disable. The system will crash due to reentrancy on the common vector, if the values, and vector are not managed properly. -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Sunday, October 25, 2020 11:27 PM To: dev@nuttx.apache.org Subject: Re: interrupt priorities on nRF52 On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > Hi, > while working on nRF52 BLE link-layer I experienced some problems due to > delayed ISRs. This can be quite problematic > for handling all the tight timings required by the standard. I eventually > reached an implementation that can deal with this relatively well (BLE > standard gives some leeway for some small number of dropped packets and > also retransmits missing ones). However, as other peripherals start > generating more interrupts, this could actually become a problem. Also, I > think it would be good to know BLE ISRs will always have priority. > > I've been looking into how ISRs can be prioritized but I don't have much > experience with this, so I have some questions: > * Does nRF52 need explicit support for handling interrupts with different > priorities or is the support supposed to be taken care of at the ARM level > code? > * How well supported is this in nRF52/ARM? > You can call up_prioritize_irq(at least Cortex-M implement it) to change the ISR priority. > * Do interrupt priorities imply nested interrupts? It isn't clear to me if > priorities only mean which ISR will get served first when they are pending > together or if it also implies that a low priority But the priority difference doesn't imply that the nested interrupt happens automatically, you have to enable the interrupt manually after the critical CPU register and OS state is saved. interrupt can be interrupted to handle a higher priority one (I believe the > latter is what is usually refered to as "nested interrupts") > * How does enter_critical_section() deal with priorities? How do I know > which priority is masked and which one isn't? > The critical section always mask all interrupts, but there is a special feature(Zero Latency Interrupts) on Cortex-M: https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts We enable this feature to fix the same issue two years ago. But many code abuses the critical section and sched lock in many places, we should address these problems gradually by: 1.Replace the critical section to semaphore if suitable 2.Replace the critical section to spin lock if suitable 3.Break the large critical section into several small one These changes not only reduce the interrupt latency, but also increase the performance in the SMP case. > * Which configs should I enable to try this? > > Thanks, > Matias On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > Hi, > while working on nRF52 BLE link-layer I experienced some problems due to > delayed ISRs. This can be quite problematic > for handling all the tight timings required by the standard. I eventually > reached an implementation that can deal with this relatively well (BLE > standard gives some leeway for some small number of dropped packets and > also retransmits missing ones). However, as other peripherals start > generating more interrupts, this could actually become a problem. Also, I > think it would be good to know BLE ISRs will always have priority. > > I've been looking into how ISRs can be prioritized but I don't have much > experience with this, so I have some questions: > * Does nRF52 need explicit support for handling interrupts with different > priorities or is the support supposed to be taken care of at the ARM level > code? > * How well supported is this in nRF52/ARM? > * Do interrupt priorities imply nested interrupts? It isn't clear to me if > priorities only mean which ISR will get served first when they are pending > together or if it also implies that a low priority interrupt can be > interrupted to handle a higher priority one (I believe the latter is what > is usually refered to as "nested interrupts") > * How does enter_critical_section() deal with priorities? How do I know > which priority is masked and which one isn't? > * Which configs should I enable to try this? > > Thanks, > Matias
Re: Bug in arch/arm/stm32h7/src/stm32_ethernet.c
Hi Frank-Christian,
I just submitted a PR to fix the issue you reported:
https://github.com/apache/incubator-nuttx/pull/2120
Please let me know if it works for you.
BR,
Alan
On 10/26/20, Frank-Christian Kruegel wrote:
> Hello World();
>
> When using the CONFIG_STM32H7_PHYINIT option I get an compile error
> saying that ret ist undefined.
>
> Fix:
>
> --- nuttx-org/arch/arm/src/stm32h7/stm32_ethernet.c2020-10-26
> 12:09:41.855853749 +0100
> +++ nuttx/arch/arm/src/stm32h7/stm32_ethernet.c2020-10-26
> 12:12:50.923943167 +0100
> @@ -4421,12 +4421,14 @@
> #ifdef CONFIG_STM32H7_PHYINIT
> /* Perform any necessary, board-specific PHY initialization */
>
> - ret = stm32_phy_boardinitialize(0);
> + {
> + int ret = stm32_phy_boardinitialize(intf);
> if (ret < 0)
> {
> nerr("ERROR: Failed to initialize the PHY: %d\n", ret);
> return ret;
> }
> + }
> #endif
>
> /* Put the interface in the down state. */
>
> Furthermore, I guess the argument of stm32_phy_boardinitialize() shound
> be the interface id, not a fixed 0.
>
> Please consider this path for the next release.
>
> Frank-Christian
>
>
>
Bug in arch/arm/stm32h7/src/stm32_ethernet.c
Hello World();
When using the CONFIG_STM32H7_PHYINIT option I get an compile error
saying that ret ist undefined.
Fix:
--- nuttx-org/arch/arm/src/stm32h7/stm32_ethernet.c 2020-10-26
12:09:41.855853749 +0100
+++ nuttx/arch/arm/src/stm32h7/stm32_ethernet.c 2020-10-26
12:12:50.923943167 +0100
@@ -4421,12 +4421,14 @@
#ifdef CONFIG_STM32H7_PHYINIT
/* Perform any necessary, board-specific PHY initialization */
- ret = stm32_phy_boardinitialize(0);
+ {
+ int ret = stm32_phy_boardinitialize(intf);
if (ret < 0)
{
nerr("ERROR: Failed to initialize the PHY: %d\n", ret);
return ret;
}
+ }
#endif
/* Put the interface in the down state. */
Furthermore, I guess the argument of stm32_phy_boardinitialize() shound
be the interface id, not a fixed 0.
Please consider this path for the next release.
Frank-Christian
Re: interrupt priorities on nRF52
On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > Hi, > while working on nRF52 BLE link-layer I experienced some problems due to > delayed ISRs. This can be quite problematic > for handling all the tight timings required by the standard. I eventually > reached an implementation that can deal with this relatively well (BLE > standard gives some leeway for some small number of dropped packets and > also retransmits missing ones). However, as other peripherals start > generating more interrupts, this could actually become a problem. Also, I > think it would be good to know BLE ISRs will always have priority. > > I've been looking into how ISRs can be prioritized but I don't have much > experience with this, so I have some questions: > * Does nRF52 need explicit support for handling interrupts with different > priorities or is the support supposed to be taken care of at the ARM level > code? > * How well supported is this in nRF52/ARM? > You can call up_prioritize_irq(at least Cortex-M implement it) to change the ISR priority. > * Do interrupt priorities imply nested interrupts? It isn't clear to me if > priorities only mean which ISR will get served first when they are pending > together or if it also implies that a low priority But the priority difference doesn't imply that the nested interrupt happens automatically, you have to enable the interrupt manually after the critical CPU register and OS state is saved. interrupt can be interrupted to handle a higher priority one (I believe the > latter is what is usually refered to as "nested interrupts") > * How does enter_critical_section() deal with priorities? How do I know > which priority is masked and which one isn't? > The critical section always mask all interrupts, but there is a special feature(Zero Latency Interrupts) on Cortex-M: https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts We enable this feature to fix the same issue two years ago. But many code abuses the critical section and sched lock in many places, we should address these problems gradually by: 1.Replace the critical section to semaphore if suitable 2.Replace the critical section to spin lock if suitable 3.Break the large critical section into several small one These changes not only reduce the interrupt latency, but also increase the performance in the SMP case. > * Which configs should I enable to try this? > > Thanks, > Matias On Mon, Oct 26, 2020 at 4:52 AM Matias N. wrote: > Hi, > while working on nRF52 BLE link-layer I experienced some problems due to > delayed ISRs. This can be quite problematic > for handling all the tight timings required by the standard. I eventually > reached an implementation that can deal with this relatively well (BLE > standard gives some leeway for some small number of dropped packets and > also retransmits missing ones). However, as other peripherals start > generating more interrupts, this could actually become a problem. Also, I > think it would be good to know BLE ISRs will always have priority. > > I've been looking into how ISRs can be prioritized but I don't have much > experience with this, so I have some questions: > * Does nRF52 need explicit support for handling interrupts with different > priorities or is the support supposed to be taken care of at the ARM level > code? > * How well supported is this in nRF52/ARM? > * Do interrupt priorities imply nested interrupts? It isn't clear to me if > priorities only mean which ISR will get served first when they are pending > together or if it also implies that a low priority interrupt can be > interrupted to handle a higher priority one (I believe the latter is what > is usually refered to as "nested interrupts") > * How does enter_critical_section() deal with priorities? How do I know > which priority is masked and which one isn't? > * Which configs should I enable to try this? > > Thanks, > Matias
