[VOTE] Apache NuttX 11.0.0 (incubating) RC1 release
Hello all, Apache NuttX (Incubating) 11.0.0 RC1 has been staged under [1] and it's time to vote on accepting it for release. If approved we will seek final release approval from the IPMC. Voting will be open for 72hr. A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. The Apache requirements for approving a release can be found here [3] "Before voting +1 [P]PMC members are required to download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases." A document to walk through some of this process has been published on our project wiki and can be found here [4]. [ ] +1 accept (indicate what you validated - e.g. performed the non-RM items in [4]) [ ] -1 reject (explanation required) Thank you all, Alin Jerpelea SCM Information: Release tag: nuttx-11.0.0-RC1 Hash for the release incubating-nuttx tag: 6feb2a1f4196e361b7aa8e209534a158cd14c833 Hash for the release incubating-nuttx-apps tag: 8b43f9f9ca30f44c1cccae9a9078d5d45b776d35 [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/11.0.0-RC1/ [2] https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-11.0.0-RC1/ReleaseNotes [3] https://www.apache.org/dev/release.html#approving-a-release [4] https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
Re: Crash in ostest prioinherit?
Hello,
Priority inheritance has a known bug, and it is not working correctly.
See issue #6310: https://github.com/apache/incubator-nuttx/issues/6310
I had to disable it in our application, as it causes lots of problems.
As I see, there are a couple of propositions on fixing this, but none of
them is merged yet.
I would like to also express interest in this getting fixed. It is
important for our application.
Maybe the fix should be included in the upcoming release?
On Mon, Sep 5, 2022 at 11:24 PM Nathan Hartman
wrote:
> Has anyone ended up in __stack_chk_fail() from nxsig_nanosleep()?
>
> I am running ostest on tiva and consistently getting a panic in the
> "priority_inheritance: Restoration Test" (priority_inheritance() in
> apps/testing/ostest/prioinherit.c).
>
> It always happens in the same place:
>
> The above-mentioned function creates 3 tasks called Task0, Task1,
> Task2; grep for NUMBER_OF_COMPETING_THREADS to find the place where
> these three tasks are started.
>
> The task main function is adversary() in the same file; adversary()
> looks like this:
>
> static int adversary(int argc, FAR char *argv[])
> {
> int index= atoi(argv[1]);
> int inital_delay = atoi(argv[2]);
> int hold_delay = atoi(argv[3]);
>
> sleep_and_display(index, inital_delay);
> printf("priority_inheritance: "
> "%s Started, waiting %d uS to take count\n", argv[0],
> inital_delay);
> sem_wait(&g_sem);
> sleep_and_display(index, hold_delay);
> sem_post(&g_sem);
> printf("priority_inheritance: %s Posted\n", argv[0]);
> sleep_and_display(index, 0);
> return 0;
> }
>
> It runs sleep_and_display(), which calls usleep(), which eventually
> calls nxsig_nanosleep(). When nxsig_nanosleep() finishes and wants to
> return, the stack smashing protection kicks in and we end up in
> __stack_chk_fail(). I think this is happening in Task2() or is in some
> way connected to context switching between Task2() and another task
> due to the sleep.
>
> So far I can't seem to figure out why.
>
> Thanks,
> Nathan
>
Driver for combined battery charger and regulator
I'm writing a driver for the Quorvo ACT8945A device. This is a combined 7-output programmable regulator AND Li-ion battery charger, all in one. I see there are existing "regulator.h" and "battery_charger.h" driver templates. Would my best approach to be to create a driver using a new (e.g.) "battery_charger_regulator.h" template combining that existing functionality or is there another, preferred, approach? Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or something else? Then, once that is decided, I seem to have a mental block when it comes to device initialisation vs registering. In my mind, registering should just create the /dev/ entry and initialise the relevant structs, but not touch the device itself? But some drivers do go on to actually set up the device, whereas I think that should be a separate "init" function called independently of the "register" function, or a specific ioctl perhaps? What is the best practice here? Thanks, Tim.
Re: Driver for combined battery charger and regulator
Hi Tim, AFAIK we don't have a PMIC with battery regulator in the mainline yet. So you don't have a reference to base on it. You don't need to create a single file with all functions on it, you can create separated file for each specific function. This is how MC13892 is implemented on Linux (please don't look the source code, it is GPL), this chip is a PMIC with regulator, battery charger and LEDs control. I think for ACT8945A should be included a regulator at drivers/power/supply/ and will implement the functions from and will register itself with regulator_register(). Also you will include the battery charger logic at driver/power/battery/ as a separated act8945_batchr.c to avoid mixing things and will export itself as /dev/bat0. But you will need to use spinlock when accessing the I2C bus inside these drivers to avoid both drivers trying to use it while a transfer is in progress. BR, Alan On 9/6/22, TimH wrote: > I'm writing a driver for the Quorvo ACT8945A device. This is a combined > 7-output programmable regulator AND Li-ion battery charger, all in one. > > > > I see there are existing "regulator.h" and "battery_charger.h" driver > templates. > > > > Would my best approach to be to create a driver using a new (e.g.) > "battery_charger_regulator.h" template combining that existing > functionality > or is there another, preferred, approach? > > > > Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or > something else? > > > > Then, once that is decided, I seem to have a mental block when it comes to > device initialisation vs registering. > > > > In my mind, registering should just create the /dev/ entry and > initialise the relevant structs, but not touch the device itself? But some > drivers do go on to actually set up the device, whereas I think that should > be a separate "init" function called independently of the "register" > function, or a specific ioctl perhaps? What is the best practice here? > > > > Thanks, > > > > Tim. > > > >
RE: Driver for combined battery charger and regulator
Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using the battery charger element on this board iteration so I can leave it for later. Any thoughts on my mental tussles regarding registering vs. initialising? >-Original Message- >From: Alan Carvalho de Assis >Sent: 06 September 2022 13:51 >To: dev@nuttx.apache.org >Subject: Re: Driver for combined battery charger and regulator > >Hi Tim, > >AFAIK we don't have a PMIC with battery regulator in the mainline yet. >So you don't have a reference to base on it. > >You don't need to create a single file with all functions on it, you can create >separated file for each specific function. This is how >MC13892 is implemented on Linux (please don't look the source code, it is >GPL), this chip is a PMIC with regulator, battery charger and LEDs control. > >I think for ACT8945A should be included a regulator at drivers/power/supply/ >and will implement the functions from and will >register itself with regulator_register(). > >Also you will include the battery charger logic at driver/power/battery/ as a >separated act8945_batchr.c to avoid mixing things and will export itself as >/dev/bat0. > >But you will need to use spinlock when accessing the I2C bus inside these >drivers to avoid both drivers trying to use it while a transfer is in progress. > >BR, > >Alan > >On 9/6/22, TimH wrote: >> I'm writing a driver for the Quorvo ACT8945A device. This is a >> combined 7-output programmable regulator AND Li-ion battery charger, all >in one. >> >> >> >> I see there are existing "regulator.h" and "battery_charger.h" driver >> templates. >> >> >> >> Would my best approach to be to create a driver using a new (e.g.) >> "battery_charger_regulator.h" template combining that existing >> functionality or is there another, preferred, approach? >> >> >> >> Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or >> something else? >> >> >> >> Then, once that is decided, I seem to have a mental block when it >> comes to device initialisation vs registering. >> >> >> >> In my mind, registering should just create the /dev/ entry and >> initialise the relevant structs, but not touch the device itself? But >> some drivers do go on to actually set up the device, whereas I think >> that should be a separate "init" function called independently of the >"register" >> function, or a specific ioctl perhaps? What is the best practice here? >> >> >> >> Thanks, >> >> >> >> Tim. >> >> >> >>
Re: Crash in ostest prioinherit?
On Tue, Sep 6, 2022 at 5:36 AM Fotis Panagiotopoulos wrote: > Priority inheritance has a known bug, and it is not working correctly. > See issue #6310: https://github.com/apache/incubator-nuttx/issues/6310 > > I had to disable it in our application, as it causes lots of problems. Thanks for pointing that out. I will retest with priority inheritance disabled and report my findings... Nathan
Re: Driver for combined battery charger and regulator
Hi Tim, I think you can implement a register and a initialization as separated functions, if you search you will find some drivers implemented that way. I remember a developer that complained about the fact the some sensors are initialized automatically during the register phase and it was bad for him because he was developing a low power device, so he needs to go through ioctl to fix that issue. Currently I think the approach is make it works from scratch, but of course it could be an issue for some usage. This is something we need to revisit in the future. Other thing is an issue is that some drivers don't have a probe (some kind of prove of existence), it just assumes the device is there in the SPI/I2C bus and don't try to talk with it and goes on creating the device file. It makes the file of user hard because he see the device at /dev and think that everything is fine. BR, Alan On 9/6/22, TimH wrote: > Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using the > battery charger element on this board iteration so I can leave it for > later. > > Any thoughts on my mental tussles regarding registering vs. initialising? > >>-Original Message- >>From: Alan Carvalho de Assis >>Sent: 06 September 2022 13:51 >>To: dev@nuttx.apache.org >>Subject: Re: Driver for combined battery charger and regulator >> >>Hi Tim, >> >>AFAIK we don't have a PMIC with battery regulator in the mainline yet. >>So you don't have a reference to base on it. >> >>You don't need to create a single file with all functions on it, you can >> create >>separated file for each specific function. This is how >>MC13892 is implemented on Linux (please don't look the source code, it is >>GPL), this chip is a PMIC with regulator, battery charger and LEDs >> control. >> >>I think for ACT8945A should be included a regulator at >> drivers/power/supply/ >>and will implement the functions from and will >>register itself with regulator_register(). >> >>Also you will include the battery charger logic at driver/power/battery/ as >> a >>separated act8945_batchr.c to avoid mixing things and will export itself >> as >>/dev/bat0. >> >>But you will need to use spinlock when accessing the I2C bus inside these >>drivers to avoid both drivers trying to use it while a transfer is in >> progress. >> >>BR, >> >>Alan >> >>On 9/6/22, TimH wrote: >>> I'm writing a driver for the Quorvo ACT8945A device. This is a >>> combined 7-output programmable regulator AND Li-ion battery charger, all >>in one. >>> >>> >>> >>> I see there are existing "regulator.h" and "battery_charger.h" driver >>> templates. >>> >>> >>> >>> Would my best approach to be to create a driver using a new (e.g.) >>> "battery_charger_regulator.h" template combining that existing >>> functionality or is there another, preferred, approach? >>> >>> >>> >>> Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or >>> something else? >>> >>> >>> >>> Then, once that is decided, I seem to have a mental block when it >>> comes to device initialisation vs registering. >>> >>> >>> >>> In my mind, registering should just create the /dev/ entry and >>> initialise the relevant structs, but not touch the device itself? But >>> some drivers do go on to actually set up the device, whereas I think >>> that should be a separate "init" function called independently of the >>"register" >>> function, or a specific ioctl perhaps? What is the best practice here? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Tim. >>> >>> >>> >>> > >
RE: Driver for combined battery charger and regulator
Thanks! I think I will take the following approach: - Use Kconfig to determine the default setup (which regulators are enabled, and their voltage). If another user wants to do this manually it can be achieved by disabling them in Kconfig and using ioctl to set them manually - have first initialisation of the device via the device register function - since the ACT8945A has no chip ID register to read, I can readback another register and check it matches what it should be (based on Kconfig and initial setup) and abort the device registration if there's a problem (most likely caused by the device not being there or otherwise failed). Think that should do it. Thank you as ever, Alan, for taking the time to help me. FYI I am awaiting 11.0 release and will then rebase to that, and submit my first PR's for my new drivers 😊 >-Original Message- >From: Alan Carvalho de Assis >Sent: 06 September 2022 15:08 >To: dev@nuttx.apache.org >Subject: Re: Driver for combined battery charger and regulator > >Hi Tim, > >I think you can implement a register and a initialization as separated >functions, >if you search you will find some drivers implemented that way. > >I remember a developer that complained about the fact the some sensors are >initialized automatically during the register phase and it was bad for him >because he was developing a low power device, so he needs to go through >ioctl to fix that issue. > >Currently I think the approach is make it works from scratch, but of course it >could be an issue for some usage. > >This is something we need to revisit in the future. > >Other thing is an issue is that some drivers don't have a probe (some kind of >prove of existence), it just assumes the device is there in the SPI/I2C bus and >don't try to talk with it and goes on creating the device file. It makes the >file of >user hard because he see the device at /dev and think that everything is fine. > >BR, > >Alan > >On 9/6/22, TimH wrote: >> Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using >> the battery charger element on this board iteration so I can leave it >> for later. >> >> Any thoughts on my mental tussles regarding registering vs. initialising? >> >>>-Original Message- >>>From: Alan Carvalho de Assis >>>Sent: 06 September 2022 13:51 >>>To: dev@nuttx.apache.org >>>Subject: Re: Driver for combined battery charger and regulator >>> >>>Hi Tim, >>> >>>AFAIK we don't have a PMIC with battery regulator in the mainline yet. >>>So you don't have a reference to base on it. >>> >>>You don't need to create a single file with all functions on it, you >>>can create separated file for each specific function. This is how >>>MC13892 is implemented on Linux (please don't look the source code, it >>>is GPL), this chip is a PMIC with regulator, battery charger and LEDs >>>control. >>> >>>I think for ACT8945A should be included a regulator at >>>drivers/power/supply/ and will implement the functions from >>> and will register itself with >>>regulator_register(). >>> >>>Also you will include the battery charger logic at >>>driver/power/battery/ as a separated act8945_batchr.c to avoid mixing >>>things and will export itself as /dev/bat0. >>> >>>But you will need to use spinlock when accessing the I2C bus inside >>>these drivers to avoid both drivers trying to use it while a transfer >>>is in progress. >>> >>>BR, >>> >>>Alan >>> >>>On 9/6/22, TimH wrote: I'm writing a driver for the Quorvo ACT8945A device. This is a combined 7-output programmable regulator AND Li-ion battery charger, all >>>in one. I see there are existing "regulator.h" and "battery_charger.h" driver templates. Would my best approach to be to create a driver using a new (e.g.) "battery_charger_regulator.h" template combining that existing functionality or is there another, preferred, approach? Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? Or something else? Then, once that is decided, I seem to have a mental block when it comes to device initialisation vs registering. In my mind, registering should just create the /dev/ entry and initialise the relevant structs, but not touch the device itself? But some drivers do go on to actually set up the device, whereas I think that should be a separate "init" function called independently of the >>>"register" function, or a specific ioctl perhaps? What is the best practice here? Thanks, Tim. >> >>
Re: Driver for combined battery charger and regulator
Hi Tim, You are welcome! That is a good idea, defining the initial voltage for each channel on Kconfig will make user life easier. BR, Alan On 9/6/22, TimH wrote: > Thanks! > > I think I will take the following approach: > > - Use Kconfig to determine the default setup (which regulators are enabled, > and their voltage). If another user wants to do this manually it can be > achieved by disabling them in Kconfig and using ioctl to set them manually > - have first initialisation of the device via the device register function > - since the ACT8945A has no chip ID register to read, I can readback another > register and check it matches what it should be (based on Kconfig and > initial setup) and abort the device registration if there's a problem (most > likely caused by the device not being there or otherwise failed). > > Think that should do it. > > Thank you as ever, Alan, for taking the time to help me. > > FYI I am awaiting 11.0 release and will then rebase to that, and submit my > first PR's for my new drivers 😊 > >>-Original Message- >>From: Alan Carvalho de Assis >>Sent: 06 September 2022 15:08 >>To: dev@nuttx.apache.org >>Subject: Re: Driver for combined battery charger and regulator >> >>Hi Tim, >> >>I think you can implement a register and a initialization as separated >> functions, >>if you search you will find some drivers implemented that way. >> >>I remember a developer that complained about the fact the some sensors are >>initialized automatically during the register phase and it was bad for >> him >>because he was developing a low power device, so he needs to go through >>ioctl to fix that issue. >> >>Currently I think the approach is make it works from scratch, but of course >> it >>could be an issue for some usage. >> >>This is something we need to revisit in the future. >> >>Other thing is an issue is that some drivers don't have a probe (some kind >> of >>prove of existence), it just assumes the device is there in the SPI/I2C bus >> and >>don't try to talk with it and goes on creating the device file. It makes >> the file of >>user hard because he see the device at /dev and think that everything is >> fine. >> >>BR, >> >>Alan >> >>On 9/6/22, TimH wrote: >>> Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using >>> the battery charger element on this board iteration so I can leave it >>> for later. >>> >>> Any thoughts on my mental tussles regarding registering vs. >>> initialising? >>> -Original Message- From: Alan Carvalho de Assis Sent: 06 September 2022 13:51 To: dev@nuttx.apache.org Subject: Re: Driver for combined battery charger and regulator Hi Tim, AFAIK we don't have a PMIC with battery regulator in the mainline yet. So you don't have a reference to base on it. You don't need to create a single file with all functions on it, you can create separated file for each specific function. This is how MC13892 is implemented on Linux (please don't look the source code, it is GPL), this chip is a PMIC with regulator, battery charger and LEDs control. I think for ACT8945A should be included a regulator at drivers/power/supply/ and will implement the functions from and will register itself with regulator_register(). Also you will include the battery charger logic at driver/power/battery/ as a separated act8945_batchr.c to avoid mixing things and will export itself as /dev/bat0. But you will need to use spinlock when accessing the I2C bus inside these drivers to avoid both drivers trying to use it while a transfer is in progress. BR, Alan On 9/6/22, TimH wrote: > I'm writing a driver for the Quorvo ACT8945A device. This is a > combined 7-output programmable regulator AND Li-ion battery charger, > all in one. > > > > I see there are existing "regulator.h" and "battery_charger.h" > driver templates. > > > > Would my best approach to be to create a driver using a new (e.g.) > "battery_charger_regulator.h" template combining that existing > functionality or is there another, preferred, approach? > > > > Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? > Or something else? > > > > Then, once that is decided, I seem to have a mental block when it > comes to device initialisation vs registering. > > > > In my mind, registering should just create the /dev/ entry and > initialise the relevant structs, but not touch the device itself? > But some drivers do go on to actually set up the device, whereas I > think that should be a separate "init" function called independently > of the "register" > function, or a specific ioctl perhaps? What is the best practice here? > > > > Thanks, > > > > Tim. > > > > >>>
Re: Driver for combined battery charger and regulator
Battery driver is a special one because the framework doesn't define any ioctl to enable/disable the device, which means you have to enable it in register. On Tue, Sep 6, 2022 at 10:18 PM TimH wrote: > Thanks! > > I think I will take the following approach: > > - Use Kconfig to determine the default setup (which regulators are > enabled, and their voltage). If another user wants to do this manually it > can be achieved by disabling them in Kconfig and using ioctl to set them > manually > - have first initialisation of the device via the device register function > - since the ACT8945A has no chip ID register to read, I can readback > another register and check it matches what it should be (based on Kconfig > and initial setup) and abort the device registration if there's a problem > (most likely caused by the device not being there or otherwise failed). > > Think that should do it. > > Thank you as ever, Alan, for taking the time to help me. > > FYI I am awaiting 11.0 release and will then rebase to that, and submit my > first PR's for my new drivers 😊 > > >-Original Message- > >From: Alan Carvalho de Assis > >Sent: 06 September 2022 15:08 > >To: dev@nuttx.apache.org > >Subject: Re: Driver for combined battery charger and regulator > > > >Hi Tim, > > > >I think you can implement a register and a initialization as separated > functions, > >if you search you will find some drivers implemented that way. > > > >I remember a developer that complained about the fact the some sensors are > >initialized automatically during the register phase and it was bad for > him > >because he was developing a low power device, so he needs to go through > >ioctl to fix that issue. > > > >Currently I think the approach is make it works from scratch, but of > course it > >could be an issue for some usage. > > > >This is something we need to revisit in the future. > > > >Other thing is an issue is that some drivers don't have a probe (some > kind of > >prove of existence), it just assumes the device is there in the SPI/I2C > bus and > >don't try to talk with it and goes on creating the device file. It makes > the file of > >user hard because he see the device at /dev and think that everything is > fine. > > > >BR, > > > >Alan > > > >On 9/6/22, TimH wrote: > >> Oh - OK! Thanks Alan. Makes my life easier (for now) as I'm not using > >> the battery charger element on this board iteration so I can leave it > >> for later. > >> > >> Any thoughts on my mental tussles regarding registering vs. > initialising? > >> > >>>-Original Message- > >>>From: Alan Carvalho de Assis > >>>Sent: 06 September 2022 13:51 > >>>To: dev@nuttx.apache.org > >>>Subject: Re: Driver for combined battery charger and regulator > >>> > >>>Hi Tim, > >>> > >>>AFAIK we don't have a PMIC with battery regulator in the mainline yet. > >>>So you don't have a reference to base on it. > >>> > >>>You don't need to create a single file with all functions on it, you > >>>can create separated file for each specific function. This is how > >>>MC13892 is implemented on Linux (please don't look the source code, it > >>>is GPL), this chip is a PMIC with regulator, battery charger and LEDs > >>>control. > >>> > >>>I think for ACT8945A should be included a regulator at > >>>drivers/power/supply/ and will implement the functions from > >>> and will register itself with > >>>regulator_register(). > >>> > >>>Also you will include the battery charger logic at > >>>driver/power/battery/ as a separated act8945_batchr.c to avoid mixing > >>>things and will export itself as /dev/bat0. > >>> > >>>But you will need to use spinlock when accessing the I2C bus inside > >>>these drivers to avoid both drivers trying to use it while a transfer > >>>is in progress. > >>> > >>>BR, > >>> > >>>Alan > >>> > >>>On 9/6/22, TimH wrote: > I'm writing a driver for the Quorvo ACT8945A device. This is a > combined 7-output programmable regulator AND Li-ion battery charger, > all > >>>in one. > > > > I see there are existing "regulator.h" and "battery_charger.h" > driver templates. > > > > Would my best approach to be to create a driver using a new (e.g.) > "battery_charger_regulator.h" template combining that existing > functionality or is there another, preferred, approach? > > > > Would the preferred device name be "/dev/bat0"? Or "/dev/act8945a"? > Or something else? > > > > Then, once that is decided, I seem to have a mental block when it > comes to device initialisation vs registering. > > > > In my mind, registering should just create the /dev/ entry and > initialise the relevant structs, but not touch the device itself? > But some drivers do go on to actually set up the device, whereas I > think that should be a separate "init" function called independently > of the > >>>"register" > function, or a specific io
Question about ESP32 PC address.
Hi, I'm dealing with an interesting situation regarding a WDT lock in the esp32-devkitc board. Some details: -SPI3 has 2x MCP2515 under heavy canbus traffic. -SPI2 has an SDCard in SPIMode. -TWAI is also receiving a reasonable CAN traffic. -Wifi is connected to an AP sending data from the SDCard to a remote server. -Sidenote: The board is using an external power supply so I'm discarding any power issues. In single core mode, the whole system (logging app + uploading app) works fine (CPU Load around 90%), when enabling SMP the system works well for a while with sporadic WDT resets. The logging app is responsible for feeding the WDT, and in SMP although I can get much faster uploads, sometimes the board is reset by the WDT. If the uploading app isn't running, the system will not be reset by the WDT. The fact that I find unusual is one of the PC values reported on board reboot after the WDT reset. Let me show: W (197) boot.esp32: PRO CPU has been reset by WDT. W (202) boot.esp32: WDT reset info: PRO CPU PC=0x4016decc (waiti mode) W (209) boot.esp32: WDT reset info: APP CPU PC=0x7278b09a W (202) boot.esp32: WDT reset info: PRO CPU PC=0x4016decc (waiti mode) W (209) boot.esp32: WDT reset info: APP CPU PC=0x7278b09a W (202) boot.esp32: WDT reset info: PRO CPU PC=0x400d8cd0 W (208) boot.esp32: WDT reset info: APP CPU PC=0x7278b09a W (197) boot.esp32: PRO CPU has been reset by WDT. W (202) boot.esp32: WDT reset info: PRO CPU PC=0x400f8fb4 W (208) boot.esp32: WDT reset info: APP CPU PC=0x7278b09a Besides all the SMP related issues that most likely I failed to figure out, I would really like to know what kind of address is this at the APP CPU 0x7278b09a Addr2line failed to decode that address. The most similar address that I could find is 0x4008b89a (this address is inside pm_dream). Anyways, the MAIN question is: Where does 0x7278b09a points to? Thanks for your time, Victor A. P. Benso (47) 999-229-599 (65) 999-186-147
Re: Question about ESP32 PC address.
On Tue, Sep 6, 2022 at 6:35 PM Victor Benso wrote: > Besides all the SMP related issues that most likely I failed to figure out, > I would really like to know what kind of address is this at the APP CPU > 0x7278b09a > Addr2line failed to decode that address. The most similar address that I > could find is 0x4008b89a (this address is inside pm_dream). > Anyways, the MAIN question is: > > Where does 0x7278b09a points to? Do you have the linker map file available? That should make it possible to find where this address is. Actually, before that: Is this address within the range of possible addresses? (As opposed to some random garbage that ended up in PC somehow.) Nathan
Re: Question about ESP32 PC address.
Might be a corrupted address; 0x7278 is ASCII "rx". Could be stack overflow corrupting the address. On Tue, Sep 6, 2022 at 5:37 PM Nathan Hartman wrote: > On Tue, Sep 6, 2022 at 6:35 PM Victor Benso wrote: > > Besides all the SMP related issues that most likely I failed to figure > out, > > I would really like to know what kind of address is this at the APP CPU > > 0x7278b09a > > Addr2line failed to decode that address. The most similar address that I > > could find is 0x4008b89a (this address is inside pm_dream). > > Anyways, the MAIN question is: > > > > Where does 0x7278b09a points to? > > Do you have the linker map file available? That should make it > possible to find where this address is. > > Actually, before that: Is this address within the range of possible > addresses? (As opposed to some random garbage that ended up in PC > somehow.) > > Nathan >
Re: Question about ESP32 PC address.
On Tue, Sep 6, 2022 at 8:12 PM Gregory Nutt wrote: > Might be a corrupted address; 0x7278 is ASCII "rx". Could be stack > overflow corrupting the address. Interesting! I hadn't considered to check what the ASCII values of the pointer address might be. This will be a valuable addition to my debugging toolbox in the future, for sure! Nathan
