Search Results

Hello! Using latest Ozone (v3.38a) debugging .elf application for IMX6ULL (Cortex-A7), the second part of double precision registers (D16 to D31) are displayed incorrectly: forum.segger.com/index.php/Attachment/6075/ It seems only lower 32 bits of the double register is intact, but high 32 bits are zeroed out for some reason. This is user interface only issue, registers contents are actually right and CPU execution goes as intended. In the J-Link web control panel these registers are fine with f…

Hi Alex,Quote from SEGGER - Alex: “Hi sonycman, sounds a bit confusing... ...Did you check this via JLink.exe by selecting the "connect under reset" strategy via the "rst <StrategyNo>" command and then issuing the "r" command? Does the Reset pin of the MCU go "LOW" when performing "r"? ” I`ve tried JLink.exe just as you`re say, here is the log: Quote: “JTAG speed: 5 kHz J-Link>rst 0 Reset type NORMAL: Using RESET pin, halting CPU after Reset J-Link>r Reset delay: 0 ms Reset type NORMAL: Using RE…

Thanks for the answer, Alex. My J-Link has 20 pin JTAG header like this: forum.segger.com/index.php/Attachment/59/ You are talking about pin 15 of the header - RESET signal? But In my board this signal connected directly to the NRST pin of the STM32 MCU! (and also this pin have ceramic capacitor of 0.1 uF to the ground, as usual). So, in theory, when the RESET signal becomes active (LOW) - MCU must resets immediately. But this is not true in my case - MCU not resets, it executes firmware undistu…

Hello! I`ve got a J-Link v5 and Segger 408l software installed, and STM32F103RET6 with disabled JTAG interface (by firmware via remap register). How could I connect debugger for firmware update in this situation? In the Keil uVision 4 J-Link interface configuration I`ve found interesting option - "connect under reset". Does that means that debugger should connect to the core just after (or right under) NTRST signal assertion (when JTAG interface being reset and operational)? Unfortunately, I hav…

Quote from SEGGER - Alex: “Hello sonycman, reset strategy 0 for Cortex-M3 behave as follows: Try to reset the core via reset strategy 1 (only the core is reset, peripherals are untouched). This is done because this strategy works for nearly all Cortex-M3 devices (even if the reset pin of the target CPU is not connected to the JTAG reste pin). If reset strategy 1 fails, try reset the core using the reset pin (reset strategy 2). In your case, the first try was succesful (strategy 1, core reset onl…

Quote from SEGGER - Alex: “Hello sonycman, in order to investigate this further, it would be useful if you could also post your J-Flash init sequence. Best regards, Alex” Hello Alex. I think I have found the source of this problem. This is the RESET signal does`nt asserted in connection procedure. Sorry, have`nt noticed you`ve answered my question and posted new thread here: Cortex-M3 reset strategie 0 did`nt work! J-Link v5.0

Hello! I`am using J-link v5.0 emulator and JFlashARM v4.00a software with STM32 Cortex-M3 microcontroller. And I have noticed recently, that there is absolutely no activity on the JTAG RESET pin (target CPU reset signal) while connection is in progress! Reset options is on the picture: forum.segger.com/index.php/Attachment/15/ Emulator connects to the core without lowering RESET level. This is why the core peripherals stays in it`s firmware configured state, and this is the root of the problems …

I have a J-Link v5.0 and Olimex STM32-P103 development board with programmed STM32F103RBT6 microcontroller. Reading the flash or RAM memory contents using Segger JFlashARM.exe v4.00a utility is always OK. But when I`am trying to program or erase the flash memory it ends up with error message (erase timeout) in chance of 50%. This is the log of JFlashARM.exe just before the error message:Quote: “T0674 006:634 JLINKARM_WriteReg(R0, 0x00000001) returns 0x00 (0000ms, 0603ms total) T0674 006:634 JLIN…