Forum Replies Created
- 
		AuthorPosts
- 
		
			
				
davidoz ParticipantHi, 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 davidoz ParticipantBtw, 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 davidoz ParticipantYes, that makes sense. I’ll purchase an ST-Link/V3 to replace the old one. Thanks for your help. davidoz ParticipantThanks 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 #26119davidoz ParticipantAwesome turnaround. It works really well now. Cheers, David October 8, 2019 at 08:29 in reply to: Embedded Memory explorer uncorrect memory name visualization #26083davidoz ParticipantHi, 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 #26060davidoz ParticipantG’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