Forum Replies Created
-
AuthorPosts
-
davidozParticipant
Hi, I have good news. The change you made so the USB serial number is always passed to OpenOCD has fixed my problem. I suspect when programming the external Flash the USB link was dropping out and reconnecting to the wrong board. Now with your fix it’s staying with the right board and works well.
Thank you for support.
Cheers,
David
davidozParticipantBtw, I have investigated the erasing of the external nor flash a little further. It’s not related to the serial number corruption discussed above. Given two similar boards with ST-Link/V2.1 &v3 are connected to the PC. I’ve noticed after openocd erases the external nor flash (via the flash plugin) it then attempts to program the flash by calling the <span>FLASHPlugin_ProgramAsync</span>(). However, that call suddenly gets re-directed to the second board, not the one being programmed.
Do you think the issue might lie with your Flash Plugin extension, or with the openocd main code?
Cheers
David
davidozParticipantYes, that makes sense. I’ll purchase an ST-Link/V3 to replace the old one. Thanks for your help.
davidozParticipantThanks for your reply. I should have made my point a bit clearer. Each St-Link/board works perfectly in isolation. As long as it is the only board connected to the PC. That indicates it isn’t an issue with the boards or unsupported devices. It appears VisualGDB or OpenOCD is selecting the wrong ST-Link to communicate with. It is doing that because the serial number on one of the ST-Link/V2 dongles is corrupt.
<span style="color: #004000;">Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Warn : *********************************************************
Warn : Found multiple matching USB devices:
Warn : VID | PID | Serial number
Warn : 0483 | 374b | 0669FF343339415043185838
Warn : 0483 | 374e | 003100413137511133333639
Warn : 0483 | 3748 | R?pQ?RS@?
Warn : Add the following command to your interface script to select a device:
Warn : hla_serial "<serial>" (for ST-Link)
Warn : jlink_serial "<serial>" (for J-Link)
Warn : ft2232_serial "<serial>" (for FT2232-based devices)
Warn : Auto-selecting the first device
Warn : *********************************************************
Info : STLINK V2J29M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.263810
Warn : UNEXPECTED idcode: 0x6ba02477
Error: expected 1 of 1: 0x0bb11477</span>As you can see, PID 3748 has a corrupt serial number. Consequently, when I try to connect to it, OpenOCD ends up selecting one of the other ST-Links.
The ST-Link Utility can access the serial number successfully (no corruption). That would imply the issue is somewhere with OpenOCD.
I’m going to order another ST-Link/V2, but I suspect that won’t fix the issue.
Btw, this does not explain why the 3rd board can’t erase external NOR flash when another ST-Link is connected to the PC. I suspect USB messages are being incorrectly routed, but for some other reason than the corrupt serial number.
Cheers
David
October 9, 2019 at 03:37 in reply to: Embedded Memory explorer uncorrect memory name visualization #26119davidozParticipantAwesome turnaround. It works really well now.
Cheers,
David
October 8, 2019 at 08:29 in reply to: Embedded Memory explorer uncorrect memory name visualization #26083davidozParticipantHi,
Thanks for your prompt reply.
I generated the FlashingLED (with RTOS) project for the SM32H7. I then created two external memories: NOR_FLASH and SDRAM. These appeared as new memories in the Linker Control script. I then manually placed all output sections into these memory locations. Note that I did not use the newly created input sections (e.g <span>.nor_flash_text). It is impractical to apply the section attribute to every variable and function in the project.</span>
Note, you can not run the output directly (you need a bootstrap to configure the external memory first). However, you can still see that the Static Stack Analysis does not work. All function are flagged as containing jumps to invalid addresses (even empty functions with no jumps 🙂 )
Cheers
David
Attachments:
You must be logged in to view attached files.October 7, 2019 at 16:32 in reply to: Embedded Memory explorer uncorrect memory name visualization #26060davidozParticipantG’day all,
I also have an issue with the Embedded Memory Explorer when using Extra Memories. The static stack analysis is such a great tool, I’m really eager to get it working.
The Extra Memories were created successfully. Code and data was relocated to the new addresses. The Embedded Memory Explorer Summary/Detail view shows all the right addresses.
The problem is every function in the Static Stack Analysis is red flagged as containing jumps to an invalid address (as seen in the screenshot). The strange thing is even empty functions that don’t call anything are still red flagged.
Any suggestions appreciated.
Cheers
David
p
Attachments:
You must be logged in to view attached files. -
AuthorPosts