I am seeing a strange behaviour on my custom board (R7FA6M3AH + FSP 3.3) since I configured my application to build as a MCU boot image. The application works correctly in standalone but when booted from MCU boot, network was ...Read more
I am seeing a strange behaviour on my custom board (R7FA6M3AH + FSP 3.3) since I configured my application to build as a MCU boot image. The application works correctly in standalone but when booted from MCU boot, network was not working and by investigating I found that the interrupt (EDMAC0_EINT) gets called but executes the Reset_Handler which causes an assert later on in FreeRTOS (vportEnterCritical gets called from an ISR).I have other devices interrupts working fine for the same binary (such as an uart over RCI) and got simpler applications to work with the network on top of MCU boot so I don’t believe it is solely due to MCU boot but after a couple of days of debugging I’m really short on ideas on what could cause the problem.
Read less
It was caused by too many interrupts declared with a non-aligned vector table. The ARM NVIC requires that the vector table must be offset to an address aligned on 4*N where N is the number of interrupts rounded to the upper power of 2. In my case I have 17 interrupts which gives 17 + 16 (standard exRead more
It was caused by too many interrupts declared with a non-aligned vector table. The ARM NVIC requires that the vector table must be offset to an address aligned on 4*N where N is the number of interrupts rounded to the upper power of 2. In my case I have 17 interrupts which gives 17 + 16 (standard exceptions) = 33 -> 64. Therefore I needed to align on 256 = 0x100. To fix the alignment I changed the header size in MCUBoot bootloader project to 0x100 instead of the default 0x80. Note that the signing command needs to be updated as well as it includes the header size in the options.
See less