Search Results
Search results 1-9 of 9.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Can I use this space as a way to formally request support for the S32G2xx platforms from SEGGER? The S32Vxxx series has support so I imagine it's not too much of a stretch to get S32G2xx.
-
SEGGER, Does the current (or any) release of JLink support accessing the Cortex M7 cores of a NXP S32G2xxx via the JTAG chain? 7.66g doesn't complain when I put in the device string but it also doesn't understand the JTAG chain in the device and later claims the device is not valid. Source Code (30 lines)
-
Since Admins aren't answering these messages, I'll just chime in that that range in the error above is for the QSPI memory, which isn't attached or enabled (AFAIK). Perhaps this RAMCode which is loaded to clear the flash thinks it has to erase a QSPI memory as well? How do we stop it from doing that?
-
I'm experiencing this on a ATSAMV71Q21B. I've erased the chip completely using different methods and tried the following commands: Source Code (3 lines) The last part fails with error -1, failed while determining flash info, claiming it failed to prepare RAMCode. Full log: Source Code (77 lines) I've used 7.00a and 7.22a. Source Code (15 lines)
-
I'm using a Cortex M-7 device in thumb2 mode which is supported by the tools. I'm invoking the semihosting calls using the same entry code: C Source Code (11 lines) The rename argument I've defined as a struct: C Source Code (6 lines) The operations above which work return expected codes (>0) and the SYS_RENAME and SYS_REMOVE return -1.
-
I'm testing some semihosting APIs on the chip we're using and I noticed that SYS_RENAME and SYS_REMOVE are not working in latest JLink as documented in the manual. What are the actual tested set of semihosting calls? I was able to use: * SYS_OPEN * SYS_CLOSE * SYS_WRITE * SYS_READ * SYS_WRITE0 * SYS_WRITEC * SYS_FLEN Unsure/untested: * SYS_SEEK * SYS_ISTTY * SYS_GETCMDLINE * SYS_EXIT