PreenFM > preenfm2 and preenfm3
Stm32F4Discovery port
norbim1:
Hi,
I think it can be a problem with the USB stick or the power line to it (the PC number shows that it hangs on the USB OTG_FS IRQ handler). Check the USB stick, or the lines going to it. If all goes well, try to filter the power lines near the USB stick socket.
Xavier:
The goal of this register dump is to be able to find where the firmware crashed.
I'm away from my dev computer and I don't remember exacly the steps to debug.
The PC (program counter) value is where it crashed.
With a mix of gdb, elf binary, 'layout split' or asm, and a gdb function to go to the PC value, you should get the C++ line where it crashed.
norbim1:
Hi Xavier!
Thanks for the tip. I just checked the symbol list, and found, that at 08041AC0 there is the OTG_FS IRQ handler, and thought that the 0x28041AC0 dumped PC value can be the same with a memory mapping offset. I'll try to find it with gdb, though I only used it before to debug a connected target.
Xavier:
--- Quote from: norbim1 on May 11, 2017, 12:24:53 PM ---Hi Xavier!
Thanks for the tip. I just checked the symbol list, and found, that at 08041AC0 there is the OTG_FS IRQ handler, and thought that the 0x28041AC0 dumped PC value can be the same with a memory mapping offset. I'll try to find it with gdb, though I only used it before to debug a connected target.
--- End quote ---
Yes RAM adress in the STM32F4 is 0x20000000. So this is the same adress moved into MCU RAM !
norbim1:
Hi electron libre,
--- Quote from: norbim1 on May 10, 2017, 08:06:59 PM ---Hi,
I think it can be a problem with the USB stick or the power line to it ....
--- End quote ---
by further analyzing the code I realized that the USB_FS_Core is responsible for the computer connection side, so You should check the PC USB connection instead. It can also be a USB power issue.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version