I've run into problems like that before. I recommend ensuring that the
bootloader performs a cleanup: return all peripherals to their
original state and turn off any interrupts it previously enabled.
Otherwise, very subtle and hard-to-find bugs can creep in.
Out of curiosity, is this a custom bootloader or an existing
open-source project? If an open-source project, I recommend to
upstream your fixes...
Cheers,
Nathan
On Wed, Feb 21, 2024 at 11:19 AM Alan C. Assis wrote:
>
> Just a update here for people facing similar issue in the future.
>
> Actually Jose discovered the issue was not on NuttX itself, but it was
> an Interrupt enabled in the bootloader that was missing an entry IRQ
> vector table.
>
> Best Regards,
>
> Alan
>
> On 2/20/24, Ambrocio, Jose wrote:
> > Hello Nuttx team,
> > I'm currently working on an embedded project that uses a bootloader and an
> > application. The target is a STM32G0B1VCI6 chip. I'm using the initial
> > address (0x0800 ) for the bootloader with 40K of size. Application
> > starts at 0x0800 A000 with 216K of size. Before jumping to the application
> > I'm setting the main stack pointer and configuring the vector table to point
> > to the start address of the app. I see that the app is executed but it
> > remains in the function irq_initialize and doing some debug I noticed that
> > it is stuck in the assert function, in an infinite loop:
> > [cid:image003.jpg@01DA63E7.A577AD90]
> >
> > I wonder if nuttx has some dependencies with the initial addresses or if
> > there is something that must be configured before jumping. This is the code
> > I have for the jumping:
> >
> > [cid:image004.png@01DA63E7.A577AD90]
> > Where NUTTX_APPLICATION_ENTRY_POINT is 0x0800A000.
> > I did a different test using another application (without nuttx) and the
> > bootloader can jump without any problem and the application can be
> > executed.
> > I would appreciate your help. Thanks
> > José Daniel Ambrocio
> > Embedded SW Engineer
> >
