- This topic has 1 reply, 2 voices, and was last updated 1 week ago by
.
-
Posts
-
Hi,
I try to bring up a simple Design with Target RP2350B and Winbond <span class=”fontstyle0″>W25Q128JVS</span> -Flash.
Debug-Probe: Segger-Jlink (SEGGER J-Link GDB Server V8.10l Command Line Version)
The chosen Board is “Solderparty Stamp XL”, which is close to mine.The Build of “simple_simple” example runs fine.
The SWD-Connection-Test runs fine.Debugging fails.
A Message appears “The memory location used for the stack (<adr>) is not writeable”Flash w/o Debugging fails.
The GDB-Log says: “compare sections missmatched” (see Details_sel.txt)(&”compare-sections\n” ~”Section .text, range 0x10000000 — 0x10003500: MIS-MATCHED!\n”)
However, the onboard-LED flashes!
Now the Questions:
is it a good idea to flash with Raspi-Debug-Probe and OpenOCD? -> Segger J-Link/Driver Problem
Which Flash-Type should be chosen in “settings booot_stage2”?
Why show the Memory-Explorer only 2 MB-Flash instead of 16MB
What does this Error-Message mean:
ERROR: Failed to perform RAMCode-sided Prepare()
Error while determining flash info (Bank @ 0x10000000)I’m switching from the RP2040Pico to the RP2350B, which apparently comes with a few issues…
Kind regards
ThomasHi,
The “stack location is not writable” check simply attempts to write and read some memory just before the _estack variable. Normally, it should be writable because that’s where the initial stack goes, but in some layouts it would not make sense. E.g. if there’s a custom bootloader that uses a different memory region to enable the memory for the main stack, VisualGDB would not automatically know about it. It’s just a quick check designed to point out when you accidentally used an incompatible device.
Same for compare-sections. It merely compares the contents of the ELF file to the readout from the device. There are scenarios where they would legitimately mismatch, and other scenarios where it would indicate a problem. It’s generally up to you to study the memory layout of the device, and the boot sequence, and understand whether it indicates a problem or not.
Regarding other questions:
- We have not encountered any problems with either probe. J-Link generally works better for classic devices, but Raspberry Pi used OpenOCD for their own development, so it could work better in this case.
- booot_stage2 does not look like any VisualGDB setting. If it’s something from the Pico SDK or OpenOCD, you would need to check their documentation.
- The Memory Explorer just takes the default FLASH size from the device definition. You can override it via VisualGDB Project Properties -> Memory Layout (requires the Custom license or higher)
- The other 2 errors are not coming from VisualGDB either. You would need to check the OpenOCD sources to determine what causes them.
- You must be logged in to reply to this topic.