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 <acas...@gmail.com> 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 <jose.ambro...@aptiv.com.invalid> 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 0000) 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 > >
