No source available for "g_pfnVectors() at 0x0"

[MBassi]

Hello,

I'm trying to debug a firmware in production mode using STM32cudeIDE, but when debugger starts it seems g_pfnVectors isn't properly created. When I stops debugger and view the dissambled code I found that it always points on the first line:

00000000: bge.n 0xffffffba

but the address 0xffffffba is not assigned to my firmware; if I go to this point I got the following message:

ffffffba: Failed to execute MI command:
 -data-disassemble -s 4294967226 -e 4294967319 -- 3
 Error message from debugger back end:
 Cannot access memory at address 0xffffffba

Have you any suggestion on how to solve this issue??

Here the memory definition of linker script:

MEMORY
 
{
 
 RETRAM_interrupts (xrw) : ORIGIN = 0x00000000, LENGTH = 0x00000298
 
 RAM2_ipc_shm (xrw) : ORIGIN = 0x00001000, LENGTH = 0x00011000
 
 FLASH_text (rx) : ORIGIN = 0x10000000, LENGTH = 0x00040000
 
 RAM1_data (xrw) : ORIGIN = 0x10040000, LENGTH = 0x00020000
 
}

and here's DT's memory reservation :

reserved-memory {
 
 #address-cells = <1>;
 
 #size-cells = <1>;
 
 ranges;
 
 
 retram: retram@0x38000000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x38000000 0x10000>;
 
 no-map;
 
 };
 
 
 mcuram: mcuram@0x30000000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x30000000 0x60000>;
 
 no-map;
 
 };
 
 
 mcuram2: mcuram2@0x10000000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x10000000 0x60000>;
 
 no-map;
 
 };
 
 
 vdev0vring0: vdev0vring0@00001000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x00001000 0x2000>;
 
 no-map;
 
 };
 
 
 vdev0vring1: vdev0vring1@00003000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x00003000 0x2000>;
 
 no-map;
 
 };
 
 
 vdev0buffer: vdev0buffer@00005000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x00005000 0x4000>;
 
 no-map;
 
 };
 
 
 mcu_rsc_table: mcu_rsc_table@00009000 {
 
 compatible = "shared-dma-pool";
 
 reg = <0x00009000 0x8000>;
 
 no-map;
 
 };
 
};

I also added a screenshot of the debugger if could be useful

Thanks for replying

Marco.

[PatrickF]

Cortex-M4 have specific vectors starting at address 0 (Stack pointer) and 4 (Reset vector) , so it is maybe normal that it does not disassemble well not jump from 0

 

Please refer to section "2.3.4 Vector table" in https://www.st.com/resource/en/programming_manual/pm0214-stm32-cortexm4-mcus-and-mpus-programming-manual-stmicroelectronics.pdf

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[Olivier GALLIEN]

Hi @MBassi​ ,

This kind of error is symptomatic of something not properly configure on CubeIDE side.

Can you confirm same code is working properly in Engineering mode ?

Did you experiment other firmware in production mode eg a cube example as in article below :

Modify, rebuild and reload a firmware - stm32mpu

If both yes, then please try to share screenshot of your debug configuration + openocd full log

Thanks

Olivier

[Tesla DeLorean]

The Vector Table is not code, there won't be disassemblable instructions there, it's literally a table of addresses, as 32-bit words.

[MBassi]

Thank you for replying,

I confirm that I developed my firmware in Engineering mode and it works fine.

I tried with example described in the guide linked by @Community member​.

With original linked script and with original DT memory reservation it works, but if I try modyfing linked script to be compliant with the reserved memory I posted before I got a remoteproc boot failure on memory region reserved for vdevring vdevbuffer and mcu_rsc_table. So I thing the issue has to be find in DT memory reservation or in some other DT part that I forgot to align

[MBassi]

Hi,

I confirmed thare was a misconfiguration of vdevring vdevbuffer and mcu_rsc_table between as defined in DT reserved_memory definition and application linker script. Solved it firmware run fine as in engineering mode.

Thank you for helping me.

Marco.

[jutoroa]

Hi,

I'm having the same issue. I had tried to align de DT reserved_memory region with the RAM.id file. Can you tell me more about how you solve it?