Skip to main content
Visitor II
June 30, 2024
Question

VSCode ST Extension v2.0.1 NUCLEO-L476RG generates incorrect Interrupt Vector Table

  • June 30, 2024
  • 3 replies
  • 2162 views

First of all thanks ST for creating this extension. I'm really happy to see support for VSCode grow. On the whole extension works for me on Windows without any problems (build/debug :thumbs_up:).

 

But when I was using NUCLEO-L476RG board, and created an Empty Project I was unable to trigger UserButton IRQ on PC13. After triggering the interrupt the code ended up not in my InterrupHandler routine but in DefaultHandler. Which prompted me to look at the autogenerated startup file and find that Interrupt Vector Table described there have nothing to do with Interrup Vector Table in the datasheet :grinning_face_with_sweat:.

This is start of the code generated with VSCode Extension:

g_pfnVectors:
.word _estack
.word Reset_Handler
.word NMI_Handler
.word HardFault_Handler
.word 0
.word 0
.word 0
.word 0
.word 0
.word 0
.word 0
.word SVC_Handler
.word 0
.word 0
.word PendSV_Handler
.word SysTick_Handler
.word DMA1_CH1_IRQHandler /* DMA1 Channel1 global interrupt */
.word DMA1_CH2_IRQHandler /* DMA1 Channel2 global interrupt */
.word DMA1_CH3_IRQHandler /* DMA1 Channel3 interrupt */
.word DMA1_CH4_IRQHandler /* DMA1 Channel4 interrupt */

And this is how beginning of the Interrupt Vector Table looks in datasheet:

LevK_0-1719761048638.png

I've checked in STM32CubeIDE and it's generating appropriate Interrupt Vector Table for this board, so it seems it's something isolated to the VSCode extension. 

    This topic has been closed for replies.

    3 replies

    Technical Moderator
    July 4, 2024

    hi @LevK 

    I tested from my side and I got the same startup file with VSCode and CubeIDE could you please give some more info 

    ST Employee
    July 5, 2024

    Hi @LevK ,

     

    We confirm the bug. The issue can be re-produced!

    FYI, we are generating the vector table in the startup-file on-the-fly by identifying the device name and pulling information from the "svd"-file. The new algorithm to do this generation does not yet have much mileage. We will look into how we can fix this.

    In the meanwhile I attach a fixed version that you can drag-drop in manually...

    • I only did build test, did not have the device to run a debug session...
    • Checked it vs ref.man, I think it is OK, but manual copy-paste is also a source of error...

    Hope it works out better for you. Thanks for bug the report!