Hi,
I see.
I will discuss this internally.
In the meantime:
Current (Windows) installers do not need admin rights for installation. You can also select “install only for this user”, then not even Program Files is touched but the software is installed to C:\Users\…
There is no “reset” API function available from within a script file because the reset itself may call script file functions like BeforeReset(), AfterReset() and ResetTarget().
What core are you working on?
Cortex-M…, Cortex-A…, RISC-V, …?
Hi,
Why do you think you need the manual update?
What is the problem with the regular update path?
We manual update is more something like a last resort for units that have a correctly signed etc. but faulty functioning firmware that can no longer be reached via USB or IP.
Something that has not happened in years, so the manual update was not needed for a while…
BR
Alex
Not sure if you understood Fabian’s post…
“Sinply pulling nReset” is something that can disturb a debug (and so RTT) session.
Pulling the reset pin may also reset the debug interface and cause a connection loss.
Even if it does not, it may cause memory access errors or garbage being read from the buffers (e.g. the startup code re-initializes the control block to 0 while J-Trace is currently evaluating the buffer positions). Such error cases may lead to an RTT “safety shutdown” where the buffer is considered as being corrupted and so RTT handling stops.
So just because it does not seem to be uncommon does not mean that it will work…
Using low power modes (e.g. the WFI instruction on Cortex-M) is common for all RTOSes but can easily disturb debugging on many devices, so it is usually encapsulated to be not compiled into debug builds.
There is no guarantee that RTT will work beyond a reset.
If it does: Fine.
If not: It is what it is.
BR
Alex
I do not specifically know the KV30 into much detail but have worked on many of the various Kinetis flash algorithms for J-Link.
For all Kinetis I have encountered, the debug interface does not provide a way to get the backdoor key into the chip. The manual said that the user is responsible to implement a way of receiving the key (e.g. via UART, SPI, …) and then the user application must copy it into the backdoor key comparison registers, to actually trigfer the temporary unlock.
If the application does not provide such a functionality, knowing the backdoor key is unfortunately useless.
Pretty sure your chip is bricked forever.
Are you serious?
You are wondering that something prevents your target from entering low power modes after you KILL GDBServer and so do not even give it a chance to perform a clean shutdown & clearing debug bits that very possibly may inhibit low power modes?
What the…
How about this?
https://wiki.segger.com/J-Link_GDB_Server#-singlerun
Is the target a 3.3V one?
If not, that’s the culprit, as the EDU Mini does not have level shifters and therefore only supports 3.3V debug signals.
Another thing is TRST. Not sure if the AM33
59 needs that pin…
BR
Alex
The EDU mini is not guaranteed to work with 1.8V targets, only with 3.3V ones.
BR
Alex
Sounds strange... Is it possible that the USB hub, the J-Links are connected to, is not powered externally or its external power supply is broken?
This would cause the hub and all J-Links connected to it to be fed from the USB cable that goes to your PC.
Maybe it is just too much for that port and it cannot deliver sufficient current, so USB works unstable then?
I still not see why it should affect your screen in any way but it would explain the "ding" which indicates USB detach + reattach/re-enumeration of the USB devices.
Agree or not, your choice.
Fact is:
All J-Link flash loaders are designed to work with the natively memory-mapped space of the chip.
For the RP2040 this is 16 MB, according to the datasheet. This means, J-Link will be able to program & verify 16 MB of QSPI reliably.
Moving the 16 MB “window” to another portion of the flash (so effectively configure the QSPI controller to use fixed high-bits != 0 during memory mapped accesses) is not supported and there is no plan to do so. (Even though it would be technically possible)
Again, you are free to write your own flash loader that does so.
If we list the memory-mapped QSPI area as 64 MB while it is only 16 MB of continuous space in the datasheet, this is a bug in our software and will be corrected to 16 MB, to be in line with the datasheet.
command string: Will take a few days to make it in the wiki but not really a secret.
Hi,
If the memory-mapped region supports max. 16 MB, this is what your flash loader does support as well.
All our flash loaders support max. what is mapped in the address space of the MCU.
So what you describe is not a bug and no, we have not “misinterpreted” the datasheet.
If flashing beyond 16 MB on this MCU somewhat / half-way works, consider yourself lucky but don’t rely on it.
If you want to have support for space beyond that (which is not XIP and therefore not “directly” debuggable anyhow), you are free to write your own flash loader:
https://wiki.segger.com/SEGGER_Flash_Loader
Disabling L1 verify can be done outside the control panel via command strings:
https://wiki.segger.com/J-Link_Command_Strings
However, the needed command string is currently not documented (we will consider to change that in the near future)
While RTT Stop-Mode in general might be working for the J-Link you use, stop-mode support on the RM48 may require further features that are specifically needed for RTT on RM48 in general, but these are not provided by the J-Link in use.
In general, the J-Link you use is a V8 model which is pretty likely 10+ years old and has been out of support and maintenance, so there is no support, bugfixing or even analysis done on it.
If the same issue comes up with a current model, we recommend to open an official support case and we will take care.
BR
Alex
Not sure what you mean with “There must be a simpler way”.
What do you have in mind?
Can you describe the “simpler” setup you have in mind?
As RTT goes through the debug interface, you need an active debug session that does all the RTT handling and you can attach to via TELNET.
Hi,
Does the latest version still show these effects?
V7.90 is from August 2023 (while we are currently in Feb 2024) and there have been several updates since then.
https://www.segger.com/downloads/jlink/
BR
Alex
Even more unfortunate that you did not mention the exact device in use in the first place and that you were missing support,
but instead let us guess and invest time into an answer that you already knew / probably expected...
However, I invested some more time and checked for a quick solution:
You should be able to use the PIC32MX130F128H by selecting "PIC32MX150F128B".
From the debug & flash programming point of view, they should be compatible.
Can you please give this a try and provide some feedback?
If it works, we would add the PIC32MX130F128H "blindly" for the next version.
BR
Alex
As the bottleneck is mainly the debug interface, USB3 probably gives a bit of better performance over USB2 in this discipline but if it is significant or even crucial, is something only you know.
I do not have any USB2 vs. USB3 RTT comparisons at hand.
I still don’t know what exactly you are trying to do (don’t get it fully from your initial post)
Hi,
Well, you need to pass the correct name to J-Link…
Not all devices share the same algorithm and flash size, so J-Link needs to know which device it is talking to, in order to have the correct algorithm selected.
List of valid device names for PIC32MX family:
https://www.segger.com/supported-devices/search/pic32mx
BR
Alex
The statement you quoted refers to the tome needed on the MCU side to get that line into the RTT buffer.
This is “the important time” because it is basically the time that your application is blocked from doing its normal work.
When the buffer is actually emptied / read by J-Link, is not really of interest, as long as the buffer does not run full, which would cause data loss or delaying the application work.
BR
Alex
