Posts by SEGGER - Erik

Hi,

Could you please send create and send one J-Link log file of the failing scenario as well as one of the good case?
How to enable: https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File

Best regards,
Erik

Could you please give it a quick try using J-Link Commander and send us a screenshot of the entire J-Link Commander output?
https://wiki.segger.com/J-Link_Commander#Perform_flash_download

Hello,

We have applied to some major changes to the templates resulting in a massive performance boost.
The now called SEGGER's high performance flash loaders (templates) are part of the J-Link Development Support Kit (DSK):
https://wiki.segger.com/J-Link_Device_…SK_availability

Best regards
Erik

Hi all,

We are not aware of such an issue in recent versions.
I just gave it a quick try here using two different evaluation boards but I cannot reproduce any problems.

Test setup:

• NUCLEO-L432KC / NUCLEO-F411RE
• J-Link software V7.22
• arm-none-eabi-gdb (8.0.50.20171128)
• J-Link GDB Server CL started via command line (included in the test suite linked below)
  
• Embedded Studio project (included in the test suite linked below)

The test suite is available for download here:
https://download.segger.com/Erik/210609_ST…4_TestSuite.zip

1) Could you please give the project / files above a quick try and provide feedback?
2) Could you please check if adding a "monitor reset" right before loading the application via GDB resolves the reported issues in your custom setups?

Short feedback would be appreciated.

Thanks
Erik

Please excuse the delay in response. It's been some quite busy days...
It's not forgotten and we plan to have a look at this later this week or next week at the latest.

I will keep you posted.

Best regards
Erik

Hello,

I just noticed that we received the same request via our ticket system.
Sorry for the delay in response, your inquiry got overlooked somehow. This should of course not happen.
As you are within valid support period, we will get back to you regarding this their ASAP.

Sorry for any inconveniences may caused.

Best regards
Erik

A clean VM would be appreciated as this could speed things up and allows us to check if the our fix works in your environment as well.
Investigation is scheduled for later this / next week.

Hello,

Just to make sure that we got you right, in your case, our software passes NumBytes == 0 to SEGGER_OPEN_Read()?
If yes, could you please upload the flashloader project + used JLinkDevices.xml file + step-by-step instructions which can be used to reproduce this behavior here?

Thanks,
Erik

Hello,

For RA6M4, the J-Link software has to use a very device specific method due to the security extensions.
Right now, this method is supported via J-Link Commander, only. J-Flash will follow within the next few weeks.

Stay up-to-date regarding J-Link:
https://www.segger.com/notification/s…php?prodid=7,94

Sorry for any inconveniences caused.

Best regards,
Erik

Hello,

We are not aware of any issues with J-Link + EZR32LG in current versions.
I just gave it a quick try here but I cannot reproduce such an issue.

Setup:

• J-Link GDB Server / DLL V6.88
• EZR32LG 868 MHz Wireless Starter kit (EZR32LG330FG60G device mounted)
• J-Link V10
• Windows 10
• Test environment:
  https://download.segger.com/Erik/201117_Si…RXX_GDBTest.zip

Do you see any differences between our setups?
Could you please give our test environment a quick try and provide feedback?

- Erik

We just implemented support for Zbit Semiconductor ZB25VQ32, ZB25VQ64 and ZB25VQ128 SPI flashes.
The change will be part of upcoming beta (V6.85c), scheduled to be available by the end of this week.

Stay up-to-date regarding J-Link:
https://www.segger.com/notification/s…php?prodid=7,94

Best regards
Erik

You are welcome

BTW: Yes you would have to modify the setup code but it's a solution which may work on any setup.
Without this approach, it's kind of impossible to perform a proper reset on certain devices.

We consider this thread as closed for now.

BR
Erik

Quote from v01d

The issue is how to cleanly halt the core immediately -before it executes any instruction - in my ResetTarget() (inside jlink script) after releasing it, and before it executes anything - it must be way too slow invoke halt through JLINK API inside the script.

Welcome to our daily business Implementing a clean reset is everything but straight forward on modern MCUs as bootloaders are involved and booting from different boot sources. Basically the CPU must be halted after bootloader execution but before executing the target application.

Basically there are two possibilities:
a) A reset does reset the debug logic as well
b) The debug logic is not affected by the reset

In latter case, a data breakpoint (watchpoint) can be used to achieve a clean reset.

The easiest thing is if your application can execute an instruction that loads a byte from Addr. 0, such as:
MOV R0, #0
LDRB R1, [R0]

You can then add a data breakpoint which halts the CPU when a byte from 0 is read.

In case a) it's much more complicated but also possible.

BR
Erik

Quote from v01d

Is there way to plainly prevent whatever calls the script's ResetTarget() from checking the CPU's debug registers after ResetTarget returns? And stop trying to halt it?

No, there is no option to prevent this and there are no plans to add such a option as it does not make any sense from our point of view.
So far, this procedure works for all supported devices (over 7000) out there and we do not see any use case where this procedure does not work.
We know that implementing a proper reset on modern devices is anything but simple compared to resets on legacy devices but it should work using this concept.

If the core is hold in reset after triggering the reset, the ResetTarget() has to release the core and halt it.
It does not make any sense to return from ResetTarget() if the core is not accessible through the debug interface.

Even if the DLL does not check the debug registers after resettarget, what should the DLL do?
It still cannot access the core so a debug session or whatever will simply crash.

If you provide us detailed information regarding the issue you are experiencing, we may can provide you information how a proper reset should be implemented for this device.

BR
Erik

Hello,

Quote

However, we do have another defective J-Link Plus from 2014, serial number 609300932: would this unit also be eligible for the trade-in program?

Yes.

Regarding firmware downgrade:
You cannot perform a downdate of the J-Link V10 firmware using V4.96m because this version does not support the J-Link V10 firmware.

Thank you for the update.
We will consider this case as closed for now.

Best regards
Erik

Hello,

We were able to reproduce not the same issue but a similar one.
This one will be fixed in the next official version (V6.62b), scheduled to be available later today.

Could you please give this version a quick try and provide feedback?

BTW: I noticed that you do *not* perform a reset prior programming.
This is recommended in order to make sure that the device is in a proper / defined state before programming.

Best regards
Erik

Hello,

We can add this to our ToDo list but without a high priority because the demand is relative low compared to other requested devices and there are many other pressing / paid projects which needs to be finished before. If you need support for this short term, we recommend to add it on your own using the Open Flashloader.
https://wiki.segger.com/Open_Flashload…_a_Flash_Loader

Best regards
Erik

The gain of such a functionality is nearly zero as the click on File -> Save data file as takes
longer than changing the data type which can be done in < 1 s with the keyboard ("tab" followed by "i").
However, I will add this on the ToDo list anyhow but please note that we cannot assign a high priority to this.

Hello,

Thank you for your suggestion.

I would not agree that *.hex is the most commonly used file format as it highly depends on the environment / use case.
I will bring this up in our next team meeting but I assume that we will not change.

Best regards
Erik