Hi,
Usually devices are locked when produced for release to prevent them from being read out.
The i.MX534 for example has multiple debug modes which either require the correct key to be passed or
disable debug access completely.
I would be very surprised if the car manufacturer did not enable security for the device.
In such a case there is not much you can do, I'm afraid.
I suggest to contact, the car manufacturer for help instead.
Best regards,
Fabian
Hi,
We will look into this and see if we want to adjust the code to prevent these warnings.
However, we are currently fully booked with projects and this is the first request regarding this, so I cannot say when we will be able to look into this.
I would suggest that you suppress these warnings on your side for now, by wrapping the include of the header file in pragmas to disable/enable these warnings.
Example:
#ifdef __GNUC__
#define SPECIAL_WARNINGS_DISABLE() \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wcast-qual\"") \
_Pragma("GCC diagnostic ignored \"-Wcast-align\"")
#define SPECIAL_WARNINGS_ENABLE() \
_Pragma("GCC diagnostic pop")
#else
#define SPECIAL_WARNINGS_DISABLE()
#define SPECIAL_WARNINGS_ENABLE()
#endif
// [...]
SPECIAL_WARNINGS_DISABLE()
#include "SEGGER_RTT.h"
SPECIAL_WARNINGS_ENABLE()That way you can still update the RTT sources without manually adding the pragmas.
BR
Fabian
Hi James,
VCOM (virtual COM port) is what is used to use J-Link as a virtual com port device.
This makes it possible to use the related J-Link pins to be used as UART interface.
The article Alex linked should do exactly what you require:
Show J-Link as a COM port device, which can then be used by what ever application you are using to send/receive UART information
between your PC and your target chip.
For further information please refer to:
wiki.segger.com/J-Link_Virtual_COM_Port
For information about how to set it up under Linux, please refer to the article Alex already linked:
wiki.segger.com/Using_J-Link_VCOM_functionality
BR
Fabian
Hi Gabriel,
this is intentional.
SEGGER_RTT_printf() is (by far) not a complete printf() implementation.
Flags, FieldWidth and Precision will be ignored for specifiers s & c.
Unfortunately, this information was missing from the API documentation in the Wiki.
We just added this information to prevent confusion:
https://wiki.segger.com/RTT#SEGGER_RTT_printf.28.29
For your specific use case, I would suggest to use snprintf() or similar,
provided by the library of your choice.
BR
Fabian
Hi,
good to hear that the problem could be resolved by a reboot!
As the issue is resolved, we will close this thread now.
Best regards,
Fabian
Hi,
Sorry for the delay in response.
We were able to replicate the issue and fix it.
A fix will be part of the next J-Link Software release planned for some time tomorrow (V7.88k).
It will be available for download here:
https://www.segger.com/downloads/jlin…cumentationPack
We are sorry for any inconvenience caused.
BR
Fabian
Hi Gabriel,
RTT is already executed in background mode on the RM4x devices.
The background AP is implemented natively, so no actions/script files on your side needed.
You can verify this by opening the RTT tab in the J-Link Web Control Panel:
https://wiki.segger.com/J-Link_-_Web_control_panel
Only normal memory reads (e.g. via Mem32 in the J-Link Commander) will use stop mode,
as background access mode is currently only used by RTT & HSS.
I also answered you in the support ticket case.
BR
Fabian
Update:
The following steps solved the issue:
- In J-Link Commander, connect to the J-Link and issue the following command
ResetConf
- Powercycle the J-Link
- In J-Link Commander, connect to the J-Link and issue the following command
Calibrate
BR
Fabian
Hi Philipp,
Sorry for the delay in response.
We agree that a crash should be avoided here.
We will add a "NULL" (or similar) return message at some point in the future.
Please note that we are currently fully booked with projects,
so we cannot provide a timeline for when this will be available.
We will close this thread now.
Best regards
Fabian
Hi,
we are not aware of any such issue.
Does the issue also occur when using the latest J-Link Software version?
https://www.segger.com/downloads/jlin…cumentationPack
Do you use custom hardware or an evaluation board? In the latter case which one?
If custom hardware, do you experience the same problem on an evaluation board?
Could you please provide the following?
- A J-Link log file of a faulty download attempt? How to enable:
https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
- A Small sample project this issue is reproducible with and
step by step instructions explaining how to reproduce this issue
BR
Fabian
Hi,
Before replacing anything, did you make sure that VCOM was not disabled for the J-Link Compact?
https://wiki.segger.com/Using_J-Link_VCOM_functionality
BR
Fabian
Hi,
- Only one loader is loaded to RAM at a time, and
- the RAM region used by the loader is restored after each programming sequence.
BR
Fabian
Hi,
there is no such issue known to us.
Would it be possible to send us the FL_Test*.FLM files so we can check on our side?
Could you please send us a J-Link log file? How to enable:
https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
BR
Fabian
Hi,
Thank you for your inquiry.
We will answer you in the support ticket system regarding this.
BR
Fabian
Hi,
No, it will not be reverted automatically.
As a verification error indicates an issue during programming it would not really make sense to attempt another
programming procedure to revert the changes, as this might very well fail again.
The data on the target is not defined from the address where the verification failed onward.
You can check it by reading back the programmed ranges.
BR
Fabian
Hi,
Requests like this are handled in our Support Ticket system.
Could you please create an inquiry regarding this there?
Please also add a link to this forum thread, so the supporters know that these cases are related.
Best regards,
Fabian
Hi Sharon,
1. Where could I find the flash loader documrent to support older version?
The older documentation is not available anymore, as it is a discontinued product.
When provide flash bankinfo in my device.xml, it seems must to provide flash loader, even I see the AlwaysPresent="0". Is it normal?
If you specify a new flash bank via the xml, you definitively have to add a flash loader.
Otherwise it would not really make sense to specify it, as no flash programming is possible without a flash loader.
From J-Link_Device_Support_Kit, AlwaysPresent => Specifies if a flash bank is always present (e.g. internal flash). If this element is set to 1, this flash bank will be affected by the "erase" command.
The "Erase" command refers to the J-Link Commander "Erase" command.
It means that the bank will not be automatically erased when issuing this command.
This is used for e.g. QSPI flash banks, as these usually do not necessarily have to be connected to the MCU, so
trying to erase them would always lead to an error. To prevent this, the bank can be added as not always present.
BR
Fabian
As Skvo correctly indicated, you are using a clone/cracked J-Link.
Please note that the use of such a device in combination with our Software is illegal.
We will close this thread now.
BR
Fabian
Hi,
Connecting to the Apollo 3 devices should not trigger a reset by default,
so connecting with the J-Link RTT Viewer should also not do so.
Could you please
1) tell us what lead you to the conclusion that the device is reset on connect?
2) send us a picture of the Configuration Dialog of the J-Link RTT Viewer?
3) send us J-Link Log file of the RTT Viewer session that presumably resets the device? How to enable:
https://wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
BR
Fabian
Hi,
Finally should I start a new thread if problems occur with loading and/or debugging the program onto the Due? Or should I ask in this thread?
I think it is fine to stay in this thread regarding this.
As it all concerns the sample project in the wiki that is discussed here.
Is SWD functional in this case?
Yes it is. The Connector is simply used to connect the signals between board and J-Link.
See: https://www.segger.com/products/debug…rtex-m-adapter/
BR
Fabian
