Creating 9.1.0-RC0

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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,

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

(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

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

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.

Re: Interrupt restore behavior on task activate

> 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

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

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.

Re: Interrupt restore behavior on task activate

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

Re: Interrupt restore behavior on task activate

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

Re: Interrupt restore behavior on task activate

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

Interrupt restore behavior on task activate

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

Re: debugging mm_free debugassert()

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. 

Re: debugging mm_free debugassert()

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

Re: debugging mm_free debugassert()

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

Re: debugging mm_free debugassert()

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