Can the interrupt vector table be saved and/or reloaded?

[Rogers.Gary]

Posted on November 08, 2015 at 22:53

Hi,

I am running a function that seems to be moving the default vector table, that has been set up for FreeRTOS. After running  these 2 functions, USB_MSC_HOST_Init(), and then MSCHOST_DeInit(), I run SystemInit(),  (from system32f4xx_startup.c) This does nothing, and whatever the USB initialization did to the vector table isn't restored by the SystemInit call. How can it be restored after the call to USB Init? Any way to save the table first before the USB init, and restore it after? Thanks...

[Tesla DeLorean]

Posted on November 09, 2015 at 00:20

Well you could store and compare SCB->VTOR, but sounds like something else is going on.

[Rogers.Gary]

Posted on November 09, 2015 at 17:12 Yes....something strange. I finally got the issue fixed, but I would sure appreciate someone with a much higher level of understanding about the STm32F4 to explain how this works. My code before I inserted the ''USB Block'' was basic IO init, structures, and all FreeRTOS elements. No issues with memory space, stack size, or heap. Using tasks, queues, semaphores, and assorted interrupts and timers. Code was running 100% and bug free. I needed to add USB. It is to work this way: If the user powers off the device, and plugs in the USB, it will power up, detect the device, write the contents of the flash device to usb, close the USB. Then flash an LED, indicating to the user to power down the device, remove the USB, and restart. That way the code skips around when no write to USB is needed.  Well, all, that worked fine. Immediately after the code, I use the USB call to de-initialize the interface, then run all my setup calls again to ensure all interfaces are set correctly, then create FreeRTOS interfaces and launch scheduler. Well, that stopped working after running any call to initialize the USB interface, whether it actually even opened a file, etc (in fatfs system) It just broke FreeRTOS, causing it to crash somewhere in the scheduler. I knew it was an issue with interrupts, because commenting out the call the the USB_OTG_irq setup stopped the issue from happening, but then no USB. After doing some poking around on the net on anything I could find about NVIC, I found this bit of code that reads the primask register: __get_PRIMASK(); Now imagine that - just placing this call before the USB initialization call stops FreeRTOS from breaking later on. Can anyone tell me how this could possibly be? Or is there something funky with Atollic's GCC compiler going on? A bug in the STM32F4?(doubtful...but worth a poke) No a one-off occurrence either - I tested over several times and it only works with that call in place.

[Rogers.Gary]

Posted on November 09, 2015 at 17:49 Yes....something strange. I finally got the issue fixed, but I would sure appreciate someone with a much higher level of understanding about the STm32F4 to explain how this works. My code before I inserted the ''USB Block'' was basic IO init, structures, and all FreeRTOS elements. No issues with memory space, stack size, or heap. Using tasks, queues, semaphores, and assorted interrupts and timers. Code was running 100% and bug free. I needed to add USB. It is to work this way: If the user powers off the device, and plugs in the USB, it will power up, detect the device, write the contents of the flash device to usb, close the USB. Then flash an LED, indicating to the user to power down the device, remove the USB, and restart. That way the code skips around when no write to USB is needed.  Well, all, that worked fine. Immediately after the code, I use the USB call to de-initialize the interface, then run all my setup calls again to ensure all interfaces are set correctly, then create FreeRTOS interfaces and launch scheduler. Well, that stopped working after running any call to initialize the USB interface, whether it actually even opened a file, etc (in fatfs system) It just broke FreeRTOS, causing it to crash somewhere in the scheduler. I knew it was an issue with interrupts, because commenting out the call the the USB_OTG_irq setup stopped the issue from happening, but then no USB. After doing some poking around on the net on anything I could find about NVIC, I found this bit of code that reads the primask register: __get_PRIMASK(); Now imagine that - just placing this call before the USB initialization call stops FreeRTOS from breaking later on. Can anyone tell me how this could possibly be? Or is there something funky with Atollic's GCC compiler going on? A bug in the STM32F4?(doubtful...but worth a poke) No a one-off occurrence either - I tested over several times and it only works with that call in place.