SEGGER - Alex Administrator

I am confused… First, you posted some output in which you get a syntax error for „loadfile“. Then you posted some output with an almost identical call to „loadfile“ but there is no syntax error. Instead, the flash programming is started and…

Hi, Our J-Link debug probes do not support RL78, so there is no debug support. Production programming support is available via our Flasher PRO / ATE / … production programmers.

So this issue is specific to the GDB multiarch in the debian repo it seems? If you can provide a step-by-step reproducer for an eval board, we will give it a try and check what can be done.

Create a batch file or similar, that calls J-Flash 2 times: 1) Read back of calibration data + save as hex file 2) Open file to program, pass „merge“ command and specify 2nd file (the calibration data hex file), followed by the „auto“ command…

If you use „loadbin“ you should pass a bin file. If you use „loadfile“ it can be a hex / mot / srec / elf / bin file. Note that for bin files, you also need to pass an address because these files do not contain address information. In your case,…

You can ignore the advice of using V7.92p. When this advice was given, there was already a fixed V7.92q released. Apart from that, the advice was quite misleading. As you wrote, you updated your macOS version and not your J-Link SW, when problems…

While „messed up“ is a bit harsh: Yes, there is a mistake in there. But if that is all you can complain about, you should be fine The release notes will be auto-fixed with the new version coming Wed. this week.

Yes it does. See release notes for V7.84e, section "GDB Server": segger.com/downloads/jlink/ReleaseNotes_JLink.html "ARMv8-A/R: Added auto-detection of core execution state (AArch64 / AArch32) and register set selection on connect."

All good, I received the S/N. I explicitly asked for the S/N because many people have multiple J-Links or switch models after registration etc., so the S/N during registration is not necessarily the one in use right now. Your J-Link is a J-Link PLUS HW…

I repeat: Flash loaders are and have ever been executed with interrupts disabled. When executed inside J-Flash etc. a global „mask interrupts“ bit is set, so matter how often and where else you enable them, they won‘t make it through. You cannot…

GDB Server sends a XML file to GDB that contains the register indexes GDB Server knows. For some reason, your GDB rejects this file. (1st warning) Unfortunately, it does not tell GDB Server about this and now both sides may use different register sets…

Sure, but you may add support on your own. So writing some script files that define the connect parameters and the required reset sequence (99% certain that the default one will not work on the TI AM62x series devices)

Hi David, OK, good to hear that. Btw, the BASE/PLUS can indeed supply 5V to the target via pin 19 of the J-Link connector: wiki.segger.com/J-Link_Commander#Power

Hi, flash loaders are and have ever been executed with interrupts disabled, for various reasons. What‘s the point in having interrupts in your loader? Makes the code more complicated, needs a vector table and the core cannot do anything else anyhow,…

Is your nRF chip running at 3.3V? I am wondering that you connect VTref from the target to J-Link, while at the same time having J-Link configured for fixed VTref 3.3V. The only purpose for the „fixed VTref“ setting is to omit the VTref…

No, most scripts are not public domain and only given out in specific cases. BR Alex

Hi, Please find attached a script for the TI DM3730. Has a fair chance that the OMAP355x is similar (not identical!!!). Especially the part that says "Put ARM core in JTAG chain" needs to be checked because on the OMAP355x it may not be SDTAP3 register…

Usually, you do not have to provide address information for the "load" command, as ELF files contain address information. The correct sequence in GDB is this done: load ... monitor reset flush registers The "flush registers" is needed because "monitor…

Hi, the "Go" commands you are seeing are coming from GDB. So it is basically GDB that is stuck in some kind of endless loop. This is most probably because the breakpoint at 0x00039AA6 is probably not a breakpoint that GDB set on itself. Can you check…

Are we talking about the Cortex-A8 based TI OMAP35x chips? Any particular eval board (e.g. BeagleBone)? Or custom HW?