Creating 9.1.0-RC0

[Brennan Ashton]

Hey all,
So according to the plan from a couple weeks ago, tomorrow the 22th we
are going to be cutting the 9.1.0-R0 release and putting it up for a
vote.  In the last couple weeks there has been a lot of moving bits on
master and we have not backported anything to the 9.1 branch.  I have
done some testing on the ports I have an interest in, but I do not
have a good sense of any other testing that has happened.

My plan  is to create the RC tomorrow evening Pacific Time.  We also
need to take the release notes from the wiki and move them to git.  If
someone wants to take on that task feel free to speak up.  Also if
there are any fixes that should be backported, shifting the release by
a day or two is not a big deal, I would rather do that then have to go
through another fix release cycle.

--Brennan

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Matias N.]

Ah, it is STM32L476RET. So, that wouldn't be the problem, but I have to check 
the errata for this chip.
It is 62 pages long =|

On Sun, Jun 21, 2020, at 19:50, Gregory Nutt wrote:
> On 6/21/2020 4:36 PM, Gregory Nutt wrote:
> >
> >> I will consider this possibilities, thanks.
> >>
> >> What is driving me crazy is that it actually seems to be triggered by 
> >> the binary being bigger than 256KB (MCU has 512KB, dual bank). I 
> >> already had to use openocd from git since it would not flash the 
> >> image in that case. Now openocd flashes correctly. However, the bad 
> >> reset behavior also seems to happen in this case. I have the same 
> >> problem with optimization turned on but which increases binary size 
> >> above 256KB.
> >>
> >> I cannot think something in the code that would change in this case, 
> >> since banks are contiguous. Maybe some chip errata, I don't know.
> >
> > Yes, I do recall some issue with the F429's in this regard. There was 
> > an errata. I believe that there are some pins in the upper 256Kb bank 
> > that interfered with some other peripheral. DavidS would know better 
> > than I. I thought it effected USB?
> >
> > You never mention which part you are using (or perhaps wan't paying 
> > attention). You should check the errata.
> 
> I think this is the errata I was thinking of. In the STM32F42xx and 
> STM32F43xx Errata sheet:
> 
>  2.2.10 PA12 GPIO limitations
> 
>  Description
>  When PA12 is used as GPIO or alternate function in input or output
>  mode, the data read
>  from Flash memory can be corrupted. This behavior is observed only
>  when the following
>  conditions are met:
> 
>  • The device operates from a 2.7 to 3.6 V VDD power supply whatever
>  the temperature
>  range
>  • Flash memory Bank2 is used or the dual bank feature is enabled.
> 
>  Impacted products
>  • STM32F42xxI and STM32F43xxI part numbers
>  • STM32F42xxG and STM32F43xxG part numbers only when dual bank
>  feature is
>  enabled.
> 
>  Not impacted products
>  • STM32F42xxG and STM32F43xxG part numbers when dual bank feature is
>  disabled
>  • STM32F42xxE and STM32F43xxE part numbers.
> 
>  Workaround
>  PA12 must be left unconnected on the PCB (configured as push-pull
>  and held Low). You
>  can use all the other GPIOs and all alternate functions except for
>  the ones mapped on
>  PA12. Use the OTG_HS peripheral in full-speed mode instead of the
>  OTG_FS peripheral.
> 
>  This limitation is fixed in silicon starting from revision 3.
> 
> Note that this has been fixed in current versions.
> 
> 

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Gregory Nutt]

On 6/21/2020 4:36 PM, Gregory Nutt wrote:



I will consider this possibilities, thanks.

What is driving me crazy is that it actually seems to be triggered by 
the binary being bigger than 256KB (MCU has 512KB, dual bank). I 
already had to use openocd from git since it would not flash the 
image in that case. Now openocd flashes correctly. However, the bad 
reset behavior also seems to happen in this case. I have the same 
problem with optimization turned on but which increases binary size 
above 256KB.


I cannot think something in the code that would change in this case, 
since banks are contiguous. Maybe some chip errata, I don't know.


Yes, I do recall some issue with the F429's in this regard. There was 
an errata.  I believe that there are some pins in the upper 256Kb bank 
that interfered with some other peripheral. DavidS would know better 
than I.   I thought it effected USB?


You never mention which part you are using (or perhaps wan't paying 
attention).  You should check the errata.


I think this is the errata I was thinking of.  In the STM32F42xx and 
STM32F43xx Errata sheet:


   2.2.10 PA12 GPIO limitations

   Description
   When PA12 is used as GPIO or alternate function in input or output
   mode, the data read
   from Flash memory can be corrupted. This behavior is observed only
   when the following
   conditions are met:

   • The device operates from a 2.7 to 3.6 V VDD power supply whatever
   the temperature
   range
   • Flash memory Bank2 is used or the dual bank feature is enabled.

   Impacted products
   • STM32F42xxI and STM32F43xxI part numbers
   • STM32F42xxG and STM32F43xxG part numbers only when dual bank
   feature is
   enabled.

   Not impacted products
   • STM32F42xxG and STM32F43xxG part numbers when dual bank feature is
   disabled
   • STM32F42xxE and STM32F43xxE part numbers.

   Workaround
   PA12 must be left unconnected on the PCB (configured as push-pull
   and held Low). You
   can use all the other GPIOs and all alternate functions except for
   the ones mapped on
   PA12. Use the OTG_HS peripheral in full-speed mode instead of the
   OTG_FS peripheral.

   This limitation is fixed in silicon starting from revision 3.

Note that this has been fixed in current versions.

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Gregory Nutt]

I will consider this possibilities, thanks.

What is driving me crazy is that it actually seems to be triggered by the 
binary being bigger than 256KB (MCU has 512KB, dual bank). I already had to use 
openocd from git since it would not flash the image in that case. Now openocd 
flashes correctly. However, the bad reset behavior also seems to happen in this 
case. I have the same problem with optimization turned on but which increases 
binary size above 256KB.

I cannot think something in the code that would change in this case, since 
banks are contiguous. Maybe some chip errata, I don't know.


Yes, I do recall some issue with the F429's in this regard. There was an 
errata.  I believe that there are some pins in the upper 256Kb bank that 
interfered with some other peripheral. DavidS would know better than I. 
  I thought it effected USB?


You never mention which part you are using (or perhaps wan't paying 
attention).  You should check the errata.

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Matias N.]

I will consider this possibilities, thanks.

What is driving me crazy is that it actually seems to be triggered by the 
binary being bigger than 256KB (MCU has 512KB, dual bank). I already had to use 
openocd from git since it would not flash the image in that case. Now openocd 
flashes correctly. However, the bad reset behavior also seems to happen in this 
case. I have the same problem with optimization turned on but which increases 
binary size above 256KB.

I cannot think something in the code that would change in this case, since 
banks are contiguous. Maybe some chip errata, I don't know.

On Sun, Jun 21, 2020, at 18:51, Gregory Nutt wrote:
> 
> > The appropriate thing to do would be to check reset signal using an 
> > oscilloscope but i don't have one here.
> >
> > Anyway, I simply wanted to ask if by any chance this could be due to some 
> > oversight related to how the non-optimized build could affect this, based 
> > on someone else experience with the same problem. But I guess it is pretty 
> > specific.
> 
> We can assume that the unoptimized code is correct (it usually is, the 
> optimized code sometimes is not). Then the only effects of unoptimized 
> code that I can think of might be:
> 
> 1. Parts of the boot-up code assume that .data and .bss will not be 
> used. These are initialized later after several startup functions have 
> been called. What if unoptimized code were to require some global data 
> initialization? This is possible but not likely.
> 
> 2. Timing will be different. Delay loops will be much longer. If there 
> is any critical code that assumes a quick action, that action will be 
> delayed.
> 
> 

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Gregory Nutt]

The appropriate thing to do would be to check reset signal using an 
oscilloscope but i don't have one here.

Anyway, I simply wanted to ask if by any chance this could be due to some 
oversight related to how the non-optimized build could affect this, based on 
someone else experience with the same problem. But I guess it is pretty 
specific.


We can assume that the unoptimized code is correct (it usually is, the 
optimized code sometimes is not).  Then the only effects of unoptimized 
code that I can think of might be:


1. Parts of the boot-up code assume that .data and .bss will not be 
used.  These are initialized later after several startup functions have 
been called.  What if unoptimized code were to require some global data 
initialization?  This is possible but not likely.


2. Timing will be different.  Delay loops will be much longer. If there 
is any critical code that assumes a quick action, that action will be 
delayed.

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Matias N.]

The appropriate thing to do would be to check reset signal using an 
oscilloscope but i don't have one here.

Anyway, I simply wanted to ask if by any chance this could be due to some 
oversight related to how the non-optimized build could affect this, based on 
someone else experience with the same problem. But I guess it is pretty 
specific.

Thanks,
Matias

On Sun, Jun 21, 2020, at 18:31, Adam Feuer wrote:
> Do you have GPIO available? If so you can do the equivalent of printf
> debugging by using GPIO... for instance outputting a binary number using 5
> GPIOs would give you 32 possible points to mark your code with. Or just use
> unary and change a different GPIO for every point you want to mark.
> 
> -adam
> 
> 
> 
> On Sun, Jun 21, 2020 at 2:23 PM Matias N.  wrote:
> 
> > I have the serial console enabled, but this is very early in the boot.
> >
> > On Sun, Jun 21, 2020, at 18:02, Adam Feuer wrote:
> > > (printf debugging only works if you can get far enough through the boot
> > > sequence to initialize a serial console. But that can happen pretty
> > early.)
> > >
> > >
> > > On Sun, Jun 21, 2020 at 2:01 PM Adam Feuer  wrote:
> > >
> > > > Do you have a serial console available? If so, you could use printf
> > > > debugging  > >
> > > > to determine where in the boot sequence it fails. I've done this with
> > NuttX
> > > > successfully on the SAMA5.
> > > >
> > > > -adam
> > > >
> > > > On Sun, Jun 21, 2020 at 12:13 PM Matias N.  wrote:
> > > >
> > > >> I've been having a very weird problem and I thought to ask if anyone
> > else
> > > >> suffered this by any chance. I have a board with reset line with
> > pull-up
> > > >> and a switch to tie the line to ground (with a capacitor in parallel)
> > as
> > > >> per typical STM32 circuit. This line also is exposed to the SWD
> > connector.
> > > >> When I build without size optimizations, the board works as expected:
> > it
> > > >> comes up normally and can be reset with the button. SWD also is able
> > to
> > > >> reset it for debugging. When I disable optimizations, the board does
> > not
> > > >> boot again even when pressing the reset button. It only boots
> > normally if I
> > > >> start debugging with OCD, which issues the reset from there. Since
> > with the
> > > >> debugger it boots normally this is impossible to debug.
> > > >> Any similar experience?
> > > >>
> > > >> Best,
> > > >> Matias
> > > >
> > > >
> > > >
> > > > --
> > > > Adam Feuer 
> > > >
> > >
> > >
> > > --
> > > Adam Feuer 
> > >
> >
> 
> 
> -- 
> Adam Feuer 
> 

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Adam Feuer]

Do you have GPIO available? If so you can do the equivalent of printf
debugging by using GPIO... for instance outputting a binary number using 5
GPIOs would give you 32 possible points to mark your code with. Or just use
unary and change a different GPIO for every point you want to mark.

-adam



On Sun, Jun 21, 2020 at 2:23 PM Matias N.  wrote:

> I have the serial console enabled, but this is very early in the boot.
>
> On Sun, Jun 21, 2020, at 18:02, Adam Feuer wrote:
> > (printf debugging only works if you can get far enough through the boot
> > sequence to initialize a serial console. But that can happen pretty
> early.)
> >
> >
> > On Sun, Jun 21, 2020 at 2:01 PM Adam Feuer  wrote:
> >
> > > Do you have a serial console available? If so, you could use printf
> > > debugging  >
> > > to determine where in the boot sequence it fails. I've done this with
> NuttX
> > > successfully on the SAMA5.
> > >
> > > -adam
> > >
> > > On Sun, Jun 21, 2020 at 12:13 PM Matias N.  wrote:
> > >
> > >> I've been having a very weird problem and I thought to ask if anyone
> else
> > >> suffered this by any chance. I have a board with reset line with
> pull-up
> > >> and a switch to tie the line to ground (with a capacitor in parallel)
> as
> > >> per typical STM32 circuit. This line also is exposed to the SWD
> connector.
> > >> When I build without size optimizations, the board works as expected:
> it
> > >> comes up normally and can be reset with the button. SWD also is able
> to
> > >> reset it for debugging. When I disable optimizations, the board does
> not
> > >> boot again even when pressing the reset button. It only boots
> normally if I
> > >> start debugging with OCD, which issues the reset from there. Since
> with the
> > >> debugger it boots normally this is impossible to debug.
> > >> Any similar experience?
> > >>
> > >> Best,
> > >> Matias
> > >
> > >
> > >
> > > --
> > > Adam Feuer 
> > >
> >
> >
> > --
> > Adam Feuer 
> >
>


-- 
Adam Feuer 

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Matias N.]

I have the serial console enabled, but this is very early in the boot.

On Sun, Jun 21, 2020, at 18:02, Adam Feuer wrote:
> (printf debugging only works if you can get far enough through the boot
> sequence to initialize a serial console. But that can happen pretty early.)
> 
> 
> On Sun, Jun 21, 2020 at 2:01 PM Adam Feuer  wrote:
> 
> > Do you have a serial console available? If so, you could use printf
> > debugging 
> > to determine where in the boot sequence it fails. I've done this with NuttX
> > successfully on the SAMA5.
> >
> > -adam
> >
> > On Sun, Jun 21, 2020 at 12:13 PM Matias N.  wrote:
> >
> >> I've been having a very weird problem and I thought to ask if anyone else
> >> suffered this by any chance. I have a board with reset line with pull-up
> >> and a switch to tie the line to ground (with a capacitor in parallel) as
> >> per typical STM32 circuit. This line also is exposed to the SWD connector.
> >> When I build without size optimizations, the board works as expected: it
> >> comes up normally and can be reset with the button. SWD also is able to
> >> reset it for debugging. When I disable optimizations, the board does not
> >> boot again even when pressing the reset button. It only boots normally if I
> >> start debugging with OCD, which issues the reset from there. Since with the
> >> debugger it boots normally this is impossible to debug.
> >> Any similar experience?
> >>
> >> Best,
> >> Matias
> >
> >
> >
> > --
> > Adam Feuer 
> >
> 
> 
> -- 
> Adam Feuer 
> 

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Adam Feuer]

(printf debugging only works if you can get far enough through the boot
sequence to initialize a serial console. But that can happen pretty early.)


On Sun, Jun 21, 2020 at 2:01 PM Adam Feuer  wrote:

> Do you have a serial console available? If so, you could use printf
> debugging 
> to determine where in the boot sequence it fails. I've done this with NuttX
> successfully on the SAMA5.
>
> -adam
>
> On Sun, Jun 21, 2020 at 12:13 PM Matias N.  wrote:
>
>> I've been having a very weird problem and I thought to ask if anyone else
>> suffered this by any chance. I have a board with reset line with pull-up
>> and a switch to tie the line to ground (with a capacitor in parallel) as
>> per typical STM32 circuit. This line also is exposed to the SWD connector.
>> When I build without size optimizations, the board works as expected: it
>> comes up normally and can be reset with the button. SWD also is able to
>> reset it for debugging. When I disable optimizations, the board does not
>> boot again even when pressing the reset button. It only boots normally if I
>> start debugging with OCD, which issues the reset from there. Since with the
>> debugger it boots normally this is impossible to debug.
>> Any similar experience?
>>
>> Best,
>> Matias
>
>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: MCU only booting from reset via SWD when compiled without optimizations?

[Adam Feuer]

Do you have a serial console available? If so, you could use printf
debugging  to
determine where in the boot sequence it fails. I've done this with NuttX
successfully on the SAMA5.

-adam

On Sun, Jun 21, 2020 at 12:13 PM Matias N.  wrote:

> I've been having a very weird problem and I thought to ask if anyone else
> suffered this by any chance. I have a board with reset line with pull-up
> and a switch to tie the line to ground (with a capacitor in parallel) as
> per typical STM32 circuit. This line also is exposed to the SWD connector.
> When I build without size optimizations, the board works as expected: it
> comes up normally and can be reset with the button. SWD also is able to
> reset it for debugging. When I disable optimizations, the board does not
> boot again even when pressing the reset button. It only boots normally if I
> start debugging with OCD, which issues the reset from there. Since with the
> debugger it boots normally this is impossible to debug.
> Any similar experience?
>
> Best,
> Matias



-- 
Adam Feuer 

Re: Interrupt restore behavior on task activate

[Brennan Ashton]

> The interrupts interrupts should be restore when the new context is
> instantiated in up_unblock_task().  There is no call to irq_restore().
> I don't use RISC-V, but I can show you for ARMv7-M:
>
>   arch/arm/src/armv7-m/arm_unblocktask.c
>
> 103   /* Then switch contexts */
> 104
> 105   arm_restorestate(rtcb->xcp.regs);
>
> The state of the interrupts is just part of the state of the task that
> is saved and restore on context switches.

Thanks Greg.  This helps point me in the right place, this core does
not quite follow the full RISC-V spec which I think is where I am
hitting some walls.
It is interesting to me because of how small it is,  it is fairly
trivial to implement a design with several hundred cores.

--Brennan

MCU only booting from reset via SWD when compiled without optimizations?

[Matias N.]

I've been having a very weird problem and I thought to ask if anyone else 
suffered this by any chance. I have a board with reset line with pull-up and a 
switch to tie the line to ground (with a capacitor in parallel) as per typical 
STM32 circuit. This line also is exposed to the SWD connector.
When I build without size optimizations, the board works as expected: it comes 
up normally and can be reset with the button. SWD also is able to reset it for 
debugging. When I disable optimizations, the board does not boot again even 
when pressing the reset button. It only boots normally if I start debugging 
with OCD, which issues the reset from there. Since with the debugger it boots 
normally this is impossible to debug.
Any similar experience?

Best,
Matias

Re: Interrupt restore behavior on task activate

[Gregory Nutt]

On 6/21/2020 12:54 PM, Brennan Ashton wrote:

On Sun, Jun 21, 2020, 11:46 AM Gregory Nutt  wrote:


I'm bringing up support for a new RISC-V core but I'm running into some
issues around the sys tick.

My tick timer interrupt is disabled at activating a task, clearly this is
not correct.  This is code used across all architectures so I'm sure I

just

do not understand something

void nxtask_activate(FAR struct tcb_s *tcb)
{
irqstate_t flags = enter_critical_section();
up_unblock_task(tcb);
leave_critical_section(flags);
}


Won't we perform a context switch here and not leave the critical

section?

No, the critical section is left automatically when the context switch
occurs.  The critical section is not a global attribute; it is a per
task attribute.  If Task A enters the critical section then suspends (as
above) the state of critical section is saved and the new state of the
critical section for the newly started Task B is instantiated.  For a
new task like this, the initial state of the critical section will be
"not-in-a-critical section".

This is described in a Wiki pages somewhere, but I don't recall which.
In know that is mentioned in the Wiki page on the critical section
monitor but I don't think that is the authoritative reference.

So, don't worry.  This has all been carefully thought through and has
worked well for 13.3 years.


I totally agree that the os is working as expected and that I am porting
some functionally wrong, but I am trying to understand where the interrupts
get re-enabled in this flow.  The irq save/restore look like this, but when
I instrument them I see a save called on the entry to the init task, but
never a restore. At that point the timer isr is never triggered to indicate
an OS tick. Is there another place I should be hooking to renenable the
interrupt on the context switch?


The interrupts interrupts should be restore when the new context is 
instantiated in up_unblock_task().  There is no call to irq_restore().  
I don't use RISC-V, but I can show you for ARMv7-M:


 arch/arm/src/armv7-m/arm_unblocktask.c

103   /* Then switch contexts */
104
105   arm_restorestate(rtcb->xcp.regs);

The state of the interrupts is just part of the state of the task that 
is saved and restore on context switches.


Greg

Re: Interrupt restore behavior on task activate

[Brennan Ashton]

On Sun, Jun 21, 2020, 11:46 AM Gregory Nutt  wrote:

>
> > I'm bringing up support for a new RISC-V core but I'm running into some
> > issues around the sys tick.
> >
> > My tick timer interrupt is disabled at activating a task, clearly this is
> > not correct.  This is code used across all architectures so I'm sure I
> just
> > do not understand something
> >
> > void nxtask_activate(FAR struct tcb_s *tcb)
> > {
> >irqstate_t flags = enter_critical_section();
> >up_unblock_task(tcb);
> >leave_critical_section(flags);
> > }
> >
> >
> > Won't we perform a context switch here and not leave the critical
> section?
>
> No, the critical section is left automatically when the context switch
> occurs.  The critical section is not a global attribute; it is a per
> task attribute.  If Task A enters the critical section then suspends (as
> above) the state of critical section is saved and the new state of the
> critical section for the newly started Task B is instantiated.  For a
> new task like this, the initial state of the critical section will be
> "not-in-a-critical section".
>
> This is described in a Wiki pages somewhere, but I don't recall which.
> In know that is mentioned in the Wiki page on the critical section
> monitor but I don't think that is the authoritative reference.
>
> So, don't worry.  This has all been carefully thought through and has
> worked well for 13.3 years.
>

I totally agree that the os is working as expected and that I am porting
some functionally wrong, but I am trying to understand where the interrupts
get re-enabled in this flow.  The irq save/restore look like this, but when
I instrument them I see a save called on the entry to the init task, but
never a restore. At that point the timer isr is never triggered to indicate
an OS tick. Is there another place I should be hooking to renenable the
interrupt on the context switch?

irqstate_t up_irq_save(void)
{
  uint64_t oldstat;

  /* Read mstatus & clear machine interrupt enable (MIE) in mstatus */

  asm volatile ("csrrc %0, mstatus, %1": "=r" (oldstat) : "r"(MSTATUS_MIE));
  return oldstat;
}


void up_irq_restore(irqstate_t flags)
{
  /* Write flags to mstatus */

  asm volatile("csrw mstatus, %0" : /* no output */ : "r" (flags));
}

>

Re: Interrupt restore behavior on task activate

[Gregory Nutt]

I'm bringing up support for a new RISC-V core but I'm running into some
issues around the sys tick.

My tick timer interrupt is disabled at activating a task, clearly this is
not correct.  This is code used across all architectures so I'm sure I just
do not understand something

void nxtask_activate(FAR struct tcb_s *tcb)
{
   irqstate_t flags = enter_critical_section();
   up_unblock_task(tcb);
   leave_critical_section(flags);
}


Won't we perform a context switch here and not leave the critical section?


No, the critical section is left automatically when the context switch 
occurs.  The critical section is not a global attribute; it is a per 
task attribute.  If Task A enters the critical section then suspends (as 
above) the state of critical section is saved and the new state of the 
critical section for the newly started Task B is instantiated.  For a 
new task like this, the initial state of the critical section will be 
"not-in-a-critical section".


This is described in a Wiki pages somewhere, but I don't recall which.  
In know that is mentioned in the Wiki page on the critical section 
monitor but I don't think that is the authoritative reference.


So, don't worry.  This has all been carefully thought through and has 
worked well for 13.3 years.

Interrupt restore behavior on task activate

[Brennan Ashton]

I'm bringing up support for a new RISC-V core but I'm running into some
issues around the sys tick.

My tick timer interrupt is disabled at activating a task, clearly this is
not correct.  This is code used across all architectures so I'm sure I just
do not understand something

void nxtask_activate(FAR struct tcb_s *tcb)
{
  irqstate_t flags = enter_critical_section();
  up_unblock_task(tcb);
  leave_critical_section(flags);
}


Won't we perform a context switch here and not leave the critical section?

--Brennan

Re: debugging mm_free debugassert()

[Gregory Nutt]

Ok, I will try that.
If I enable stackchecking should this kind of stack overrun be catched?


Probably.  The assertion output should should the stack usage of every 
active task in that case.


There are lots of ways that memory corruption can occur.  Stack overrun 
is just one common cause.  And one that would make sense in this case 
because it seems only to be effecting your configuration.

Re: debugging mm_free debugassert()

[Matias N.]

Ok, I will try that.
If I enable stackchecking should this kind of stack overrun be catched?

On Sun, Jun 21, 2020, at 14:22, Gregory Nutt wrote:
> 
> > The most common cause... in fact the only cause that I am aware of ... 
> > for heap failure is memory corruption. 
> 
> And a very common cause of heap memory corruption is a task that has 
> overrun its stack and clobber the meta data at the beginning of the next 
> chunk.
> 
> A simple thing you can do is to bump up stack sizes to assure this is 
> common case is not the cause of your problem.
> 
> 

Re: debugging mm_free debugassert()

[Gregory Nutt]

The most common cause... in fact the only cause that I am aware of ... 
for heap failure is memory corruption. 


And a very common cause of heap memory corruption is a task that has 
overrun its stack and clobber the meta data at the beginning of the next 
chunk.


A simple thing you can do is to bump up stack sizes to assure this is 
common case is not the cause of your problem.

Re: debugging mm_free debugassert()

[Gregory Nutt]

I'm having a weird bug appear during boot. It is being triggered at 
the first call of mm_free which comes from a call to mtdconfig driver. 
I have enabled debug information and I'm also debugging at the point 
before crash but since I don't understand the memory manager I can't 
tell where this is coming from.

The assertion line is (mm_free.c:185):

DEBUGASSERT((node->preceding & ~MM_ALLOC_BIT) == prev->size);


The most common cause... in fact the only cause that I am aware of ... 
for heap failure is memory corruption.


I normally debug this bay calling mallinfo() has selected places.  If 
the heap has been corrupted mallinfo() will fail. With a little effort 
you can find the cause of the failure between the last good call to 
mallinfo() and the first failed call to mallinfo().