Search Results

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 that does erase + program + verify

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, the following sounds the easiest way to move forward: loadfile <PathToHexFile>

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 started to show up. We will give macOS 14.1.1 a quick try and check if we can reproduce anything.

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 V10 from 2016 and out of support & maintenance. It does not support dormant mode handling completely, which is needed for TI CC2340 support. You need a new J-Link here. I recommend the trade-in program: segger.com/purchase/trade-in-program/ BR Ale…

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 use interrupts in flash loaders

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 (whatever your GDB uses by default). We test GDB Server with the de facto reference toolchain from ARM and there are no known problems with this one. Also, there are no other complaints but plenty of GDB Server users that also use M33 based MCUs no…

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, while waiting for the interrupt. So just poll and you are good…

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 pin… Cannot really comment on the VSCode error, as this comes from either VSCode or rhe debug plugin, which are both not maintained by SEGGER. Considering that things work if you use a DK from Nordic in „debug out“ mode, I suspect a wiring issue when trying with …

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 but something else. Also, the ResetTarget() will very likely work different for the OMAP355x... However, better than nothing. BR Alex

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 reset" changes the registers behind the back of GDB (e.g. the PC is changed). However, GDB does not expect such things to happen. Also, as monitor commands are GDB server specific, GDB does not know what a monitor command causes to happen on the ta…

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 if you have any BP set at this address? Also, which J-Link SW version are you using? Note that V7.92l comes with a fix for the case I explained above, see release notes for V7.92l: segger.com/downloads/jlink/ReleaseNotes_JLink.html BR Alex

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

Do you have a reference script from another debug probe? Can you link to the datasheet that describes the sequence? Is it possible that the device in question is an MCU from TI and you are trying to initialize the ICEPick on it?