On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet <sebast...@lorquet.fr> wrote:
> Back to the business > >> After this we managed to recompile our project using the latest NuttX > >> sources, but it fails when trying to init the PHY irq on our STM32F427 > >> board: We get "unexpected IRQ". > >> > >> Yes I know that's pretty vague :-) > >> > >> Is there anything obvious I should have been careful with in this > >> domain, before I dig the jtag probe to fix it (tomorrow) ? > > I would first start by looking through the Release Notes between v7.30 > > and v10.1. Many big improvements and bug fixes happened and some of > > them are mentioned in Compatibility Concerns along with some changes > > you might need to make to configuration etc. > > > > Also another thing you can try: Has this board and PHY worked > > correctly with v7.30? If so, you can bisect and with very few tests > > (I'm guessing fewer than 20) find the exact commit that broke it. > > Release notes are hard to read but I did not find anything special about > phy interrupts. > > Note that it may not be the phy interrupt. Here is my log: > > stm32_netinitialize: Enabling PHY power > stm32_netinitialize: PHY reset... > stm32_netinitialize: PHY reset done. > stm32_netinitialize: Configuring PHY int > F > irq_unexpected_isr: ERROR irq: 3 > up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50 > up_registerdump: R0: 00000001 2000737c c00000f2 08000101 00000000 > 00000000 00000000 200073c8 > up_registerdump: R8: 00000000 00000000 00000000 00000000 00000000 > 200073c8 080126ad 080126f8 > up_registerdump: xPSR: 21000000 PRIMASK: 00000000 CONTROL: 00000000 > up_registerdump: EXC_RETURN: fffffff9 > > A lot of OS initialization things happen at the point, marked by the > letter F. > > It seems that an unexpected IRQ happens in this interval, around the > time the filesystem is initialized. The backtrace goes down to memory > allocation routines through the initialization of the root inode. > > My guess is that AN external IRQ is triggered (possibly not the PHY IRQ) > but the ISR handler for that one is not ready yet. I will add debug > messages. > > > I would expect that situation to be a simple NOP, but it seems that > undefined handlers are set to this function "irq_unexpected_isr" > > Is that a new behaviour? a default config that I did not set properly > when porting our old defconfig? > > Sebastien > > > > > Nathan > Did you try disabling the PHY (or networking) in Kconfig to see if removing it from the build will eliminate the hardfault? Have you seen this about hardfault debugging: https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=139629445#content/view/139629445 Nathan
