Search Results

Quote from Dannym: “I send byte data for simplicity. p->aUp[1].sName = "JScope_u1"; SEGGER_RTT_Write(1, &dataArray[0],1); I did not know the JLink OB was slower than the JLink Base. I don't have the Base on my desk right now. However, I'm sure it's acting the same way.” Hi, this information was all I needed to find the problem. Please download the fixed beta version (same link as above) and try again. If the RTT sample rate is still unstable/unreasonable, please write us again. I'm currently run…

Hi, could you please try it with our recent beta? download.segger.com/Arne/Setup_JScope_V511.exe If it is still crashing, could you please upload the J-Link log file? SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL and SEGGER_RTT_MODE_NO_BLOCK_SKIP should both be usable. Are you sending out the data in one call per block in your application? Regards Arne

Hello, we have released a new beta version, containing a new version of the RTT viewer with support for command line parameters and some other improvements. Short description of command line parameters (manual update is still in progress): -d, --device: Select the connected target device. -ct, --connection: Sets the connection type -if, --interface: Sets the interface type -ip, --host: The IP address of the J-Link -s, --speed: Interface speed in kHz -sn, --serialnumber: Select the J-Link with a …

Hi jhartmann, the data logging feature saves the incoming data on RTT channel 1, not from the terminals (running on RTT channel 0). Best regards, Arne

Hello, see "Control/Status Register, CTRL/STAT" here: infocenter.arm.com/help/topic/…6d/Chdhbffe.html#Chdjfija Best regards, Arne

Hi rols, this depends on the hardware revision of your J-Link. As long as you do not turn on target power, a recent J-Link (HW V10.1) tolerates up to 8V externally on pin 19. Beware of turning on target power with an externally connected power source! This could cause damage to not only the J-Link but also to the PC or USB hub the J-Link is connected to. I would recommend you to place a protection diode for pin 19 on your board or simply to use a special connector/cable with cut pin 19 in produc…

Hi Paul, if you want to maintain your connection to the target, simply do not disconnect it. If you really need to physically reconnect the device, you can stop the GDB Server/Commander before disconnecting it and restart it when you have reconnected it. Resetting the J-Link should not be needed, if you do it that way. Best regards, Arne

Hi lix, the list of supported devices on our website is a bit outdated. You can choose "EFR32FG1PxxxF256" as device name. If you open the J-Link Commander and enter "?" as device you get a selection dialog with a recent list of supported devices. Best regards, Arne

Hi pricesc, the Flasher has no built in function for setting the boot mode index. It cannot be scripted, because you have to talk to the chip using UART protocol for changing the boot mode index, if the chip is in factory default configuration. We can provide you a command line utility for setting the boot mode index. Please note, we cannot provide any support for this tool. Best regards, Arne

Hello Christian, you're right, this fix did not get it in V5.10c. We're about to release V5.10d today which at least should be able to show the first element of the array correctly. We will improve the support for complex data structures in the next major release. Best regards, Arne

Hello Christian, thanks for your suggestions. We are planning to improve the handling of variables in saved projects for the next version, so structures (and arrays too) can be updated on reopening as normal variables. Best regards, Arne

Hello Christian, this bug is already fixed in V5.10c, available for download here. Best regards, Arne

Hi Dhémaïus, we have tried to reproduce your issue using a STM32F0308 discovery kit, but everything works without any problems. Booting into system memory is usually forced by pulling Boot0 pin to 1. Although you can still load and run your application (located at 0x08000000) with J-Link while Boot0 pin set to 1, the system memory in this mode is mapped to address 0x00000000 and this may lead to unexpected behavior, because interrupt vectors are taken from 0x00000000. Do you have Boot0 pin set t…

Hi Paolo, it is a problem with the handling of larger multi-dimensional arrays. The bug is fixed in J-Scope V5.10c. Best regards, Arne

Hello rensem, thanks for your suggestion. We are planning to implement a toolbox with cursor lines in one of the next releases. This toolbox will allow you to get exact values/timestamps and deltas between the cursor lines. Best regards, Arne

Hi, __WFE() and __WFI() cause the processor entering sleep mode. In sleep mode the debugging circuitry is also (partially) powered down and this causes various problems, if the sleep mode remains for a longer time. Atmel Studio 7 frequently checks, if the processor is running or halted. In sleep mode this check returns an error causing Atmel Studio 7 to permanently trying to reestablish the connection to the device. We suggest you to not use these instructions for debugging builds. The processor…