Activity for Cody Schafer
-
Cody Schafer posted a comment on ticket #203
For others running into this: turns out the magical flag for objcopy is contents, without which it zeros the section's content.
-
Ah, found out why xPSR.T was 0: My fw.elf file's first section (address 0x08000000 length 0x000020c4) is a bootloader, which is generated/included via (approximately) the following steps: $CC -o boot.elf $BOOT_OBJ $OBJCOPY -O binary boot.elf boot.bin $LD -r -b binary boot.bin -o boot.o $OBJCOPY --rename-section .data=.bootldr,alloc,load,readonly,rom,data boot.o boot-ldr.o boot-ldr.o is then linked into the image with the following linker script snippet: SECTIONS { .bootldr ORIGIN(FLASH) : { KEEP(*(.bootldr))...
-
I've submitted a variation of this for inclusion. http://openocd.zylin.com/#/c/4658/
-
I tried the reset_config srst_only srst_nogate connect_assert_srst with fw.elf. No change in behavior (still fails every other time) was noted (test script attached). I also modified fw.elf to start with an infinite loop. No change in behavior was noted (still fails to flash via algorithm every-other time)
-
I tried the reset_config srst_only srst_nogate connect_assert_srst with fw.elf. No change in behavior (still fails every other time) was noted (test script attached). I also modified fw.elf to start with an infinite loop. No change in behavior was noted (still fails to flash via algorithm every-other time)
-
A few more details (using stlink_usb_v2_read_debug() to get values) In success case, while running the flash algorithm: stlink_usb_run(), xPSR.T==1 prior to clearing C_HALT and xPSR.T==0 after clearing C_HALT. In the failing case, xPSR.T==0 also prior to clearing C_HALT (theory: it immediately faults in this case). Multiple algorithm executions in a single flash write_image erase fw.elf work. Even though xPSR.T==0 on read back in stlink_usb_run(), on second algorithm execution xPSR.T==1 is seen prior...
-
A few more details (using stlink_usb_v2_read_debug() to get values) In all cases, while running the flash algorithm: stlink_usb_run(), xPSR.T==1 prior to clearing C_HALT and xPSR.T==0 after clearing C_HALT. In the failing case, xPSR.T==0 also prior to clearing C_HALT (theory: it immediately faults in this case). Multiple algorithm executions in a single flash write_image erase fw.elf work. Even though xPSR.T==0 on read back in stlink_usb_run(), on second algorithm execution xPSR.T==1 is seen prior...
-
A few more details (using stlink_usb_v2_read_debug() to get values) In all cases, while running the flash algorithm: stlink_usb_run(), xPSR.T==1 prior to clearing C_HALT and xPSR.T==0 after clearing C_HALT. In the failing case, xPSR.T==0 also prior to clearing C_HALT (theory: it immediately faults in this case). Multiple algorithm executions in a single flash write_image erase fw.elf work. Even though xPSR.T==0 on read back in stlink_usb_run(), on second algorithm execution xPSR.T==1 is seen prior...
-
I've used the attached (4-line) patch on openocd master to workaround this issue (by setting xPSR.T).
-
After some more digging I've seen the following: reading DHCSR before & after resuming the processor indicates that when the failure occurs the processor is in lockup (S_LOCKUP is set) further examination of CFSR indicates that this is an imprecise usage fault the T bit in xPSR was 0, which would cause a usage fault (can't disable thumb mode on armv7m) tweaking run_algorithm (in armv7m.c) to set xPSR so the T bit is set causes flashing multiple times to be reliable (have not yet tested writing to...
-
I've done some more testing wrt this issue and noticed that the failure is reproduced without even using the second bank. Instead, just programming my fw.elf multiple times causes exactly every-other attempt to program fw.elf to fail. (running openocd -f board/st_nucleo_f7.cfg -f d.cfg -c exit each time) I've added some debug output to various code around stm32x_block_write to try and figure out what in particular is failing (see attached output & patches). I've added various mov r5, #0xbb (etc)...
-
I've done some more testing wrt this issue and noticed that the failure is reproduced without even using the second bank. Instead, just programming my fw.elf multiple times causes exactly every-other attempt to program fw.elf to fail. (running openocd -f board/st_nucleo_f7.cfg -f d.cfg -c exit each time) I've added some debug output to various code around stm32x_block_write to try and figure out what in particular is failing (see attached output & patches). I've added various mov r5, #0xbb (etc)...
-
I've done some more testing wrt this issue and noticed that the failure is reproduced without even using the second bank. Instead, just programming my fw.elf multiple times causes exactly every-other attempt to program fw.elf to fail. (running openocd -f board/st_nucleo_f7.cfg -f d.cfg -c exit each time) I've added some debug output to various code around stm32x_block_write to try and figure out what in particular is failing (see attached output & patches). I've added various mov r5, #0xbb (etc)...
-
Thank you for trying to reproduce. It seems very curious that the actions of my firmware (which doesn't write to flash, etc) would affect the ability of openocd to program the chips flash, especially given that reset init is being used here to reset & halt the target. I'll try out adding a loop in startup code so we can see if somehow openocd isn't managing to reset/halt the processor properly. My firmware does use clocks (it increases clock speed to 216MHz), interrupts (enables a bunch of them,...
-
And here (at zapb_'s request) is the output from swapping load and monitor tpiu ... order: This worked fine: itm output was observed, etc. gdb: (gdb) target extended-remote :3333 Remote debugging using :3333 0x20000010 in ?? () (gdb) load Loading section .vector_table, size 0x1f8 lma 0x8000000 Loading section .text, size 0x1518 lma 0x80001f8 Loading section .init_array, size 0x8 lma 0x8001710 Loading section .fini_array, size 0x4 lma 0x8001718 Loading section .rodata, size 0x4d4 lma 0x800171c Loading...
-
EDIT: this comment has less than useful information as I executed openocd incorrectly. use info from the next one I've reproduced this a few times with the following commands (openocd debug output enabled) openocd -f interface/jlink.cfg -c interface\ swd -f target/stm32f7x.cfg -d # arm-none-eabi-gdb fw.elf (gdb) load (gdb) monitor tpiu config internal itm.fifo uart off 216000000 (gdb) load Again, error output starts after the second load. gdb output is: Reading symbols from _b/boot.elf...done. (gdb)...
-
Ok, so I screwed up that last openocd execution. Here' s the log of openocd -f interface/jlink.cfg -c transport\ select\ swd -f target/stm32f7x.cfg -d gdb: (gdb) target extended-remote :3333 Remote debugging using :3333 0xfffffffe in ?? () (gdb) monitor tpiu config internal itm.fifo uart off 216000000 Can not obtain 30000000 trace port frequency from 216000000 TRACECLKIN frequency, using 27000000 instead (gdb) load Loading section .vector_table, size 0x1f8 lma 0x8000000 Loading section .text, size...
-
fw.elf test_image with gap(s) annotated: address 0x08000000 length 0x000020c4 #gap 0x080020c4 length 0x0001df3c address 0x08020000 length 0x00028ad0 address 0x08048ad0 length 0x00000e80 address 0x08049950 length 0x00000068
-
Info on my elf file: program headers readelf -l fw.elf: Elf file type is EXEC (Executable file) Entry point 0x8020239 There are 6 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x08000000 0x08000000 0x020c4 0x020c4 R 0x10000 LOAD 0x020000 0x08020000 0x08020000 0x28ad0 0x28ad0 RWE 0x10000 LOAD 0x055538 0x20025538 0x08048ad0 0x00e80 0x00e80 RW 0x10000 LOAD 0x059950 0x08049950 0x08049950 0x00068 0x00068 R 0x10000 LOAD 0x060000...
-
Info on my elf file: program headers readelf -l fw.elf: Elf file type is EXEC (Executable file) Entry point 0x8020239 There are 6 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x010000 0x08000000 0x08000000 0x020c4 0x020c4 R 0x10000 LOAD 0x020000 0x08020000 0x08020000 0x28ad0 0x28ad0 RWE 0x10000 LOAD 0x055538 0x20025538 0x08048ad0 0x00e80 0x00e80 RW 0x10000 LOAD 0x059950 0x08049950 0x08049950 0x00068 0x00068 R 0x10000 LOAD 0x060000...
-
I just tried reproducing and got the same failure when using telnet to command openocd. I've attached a telnet session (openocd -f board/st_nucleo_f7.cfg -c 'init' -c 'reset init') . I then tried a fully automated variant immediately afterward with the same board and was not able to reproduce (flash occured succesfully): openocd -f board/st_nucleo_f7.cfg -c 'init; reset init; stm32f2x mass_erase 0; flash write_bank 0 random_1MB.bin (Attached file is the failure via telnet, the content is the telnet...
-
I've reproduced this a few times with the following commands (openocd debug output enabled) openocd -f interface/jlink.cfg -c interface\ swd -f target/stm32f7x.cfg -d # arm-none-eabi-gdb fw.elf (gdb) load (gdb) monitor tpiu config internal itm.fifo uart off 216000000 (gdb) load Again, error output starts after the second load. gdb output is: Reading symbols from _b/boot.elf...done. (gdb) target extended-remote :3333 Remote debugging using :3333 0x20000010 in ?? () (gdb) monitor tpiu config internal...
-
st-link can't flash stm32f2x based flash without target algorithms
-
As a side note: it isn't just the algorithm that's failing: the fallback/normal write mechanism fails too. Here's some log output from running with set WORKAREASIZE 0 to force non-algorithm flash writing, which also fails. This is kind enough to fail more quickly than the algorithm variant, which waits for a timeout (probably should try to catch hardfaults when executing an algorithm).
-
Attached is a log of the command output: openocd -f board/st_nucleo_f7.cfg -c 'init' -c 'reset init' -c 'flash write_image fw.elf 0x100000' -d
-
Sorry about reference to program in the ticket, I simplified the reproduction to write_image. Also, heres some log following immediately after the above output (had to reset before I tried again, with the same result): > flash write_image fw.elf 0x100000 Flash write discontinued at 0x081020c4, next section at 0x08120000 Target is already running an algorithm error starting target flash write algorithm error writing to flash at address 0x08000000 at offset 0x00100000 > reset init Unable to match requested...
-
programming st_nucleo_f7 (stm32f767) bank 2 consistently fails
-
Corrections to "run in gdb" commands in the ticket, which doesn't appear editable: \3. In gdb, run: target extended-remote :3333 monitor reset init load \5. In gdb, run: monitor tpiu config internal itm.fifo uart off 216000000 load
-
Corrections to "run in gdb" commands in the ticket, which doesn't appear editable: In gdb, run: target extended-remote :3333 monitor reset init load In gdb, run: monitor tpiu config internal itm.fifo uart off 216000000 load
-
Probably related: after using a gdbinit of: target extended-remote :3333 monitor reset init load monitor tpiu config internal itm.fifo uart off 216000000 monitor itm port 0 on step The target runs, but does not provide any data to itm.fifo and openocd complains repeatedly: Info : Can not obtain 30000000 trace port frequency from 216000000 TRACECLKIN frequency, using 27000000 instead Error: Failed to read data: 0x1. Error: jaylink_swo_read() failed: device: unspecified error. Error: Failed to read...
-
jlink: failure after `load` when `tpiu` is used to enable tracing
-
After observing the strange number of breakpoints/watchpoints, using: openocd -f interface/stlink.cfg -c 'reset_config srst_only connect_assert_srst' -f target/stm32f7x.cfg To connect with openocd appears to connect correctly (correct number of breakpoints/watchpoints). However, when I then connect gdb to openocd to load an image, openocd hangs and notes: Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 Info : Halt timed out, wake up GDB. Error: timed...
-
After observing the strange number of breakpoints/watchpoints, using: openocd -f interface/stlink.cfg -c 'reset_config srst_only connect_assert_srst' -f target/stm32f7x.cfg To connect with openocd appears to connect correctly (correct number of breakpoints/watchpoints). However, when I then connect gdb to openocd and load an image, openocd hangs and notes: Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 Info : Halt timed out, wake up GDB. Error: timed...
-
After observing the strange number of breakpoints/watchpoints, using: openocd -f interface/stlink.cfg -c 'reset_config srst_only connect_assert_srst' -f target/stm32f7x.cfg To connect with openocd appears to connect correctly (correct number of breakpoints/watchpoints). However, when I then connect gdb to openocd and load an image, openocd hangs and notes: Info : accepting 'gdb' connection on tcp/3333 Info : Halt timed out, wake up GDB. Error: timed out while waiting for target halted ...
-
Yes, after observing the strange number of breakpoints/watchpoints, using: openocd -f interface/stlink.cfg -c 'reset_config srst_only connect_assert_srst' -f target/stm32f7x.cfg To connect with openocd connects correctly (correct number of breakpoints/watchpoints).
-
I've reproduced this with a seperate stlink-v2 on a stm32f777bit. Note that the first run shows a strange number of watchpoints & breakpoints. The second run is done while holding an on-board reset button. [cody@franklin fb5]$ openocd -f interface/stlink.cfg -f target/stm32f7x.cfg Open On-Chip Debugger 0.10.0+dev-00387-gcd89f213-dirty (2018-04-10-09:59) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport...
-
Heres some other output from the same error as noted in the comment above. Note that 0xa05f0000 is seen for both DWT_CTRL and the device id. [cody@franklin x]$ UBSAN_OPTIONS=print_stacktrace=1 openocd -f board/st_nucleo_f7.cfg Open On-Chip Debugger 0.10.0+dev-00327-g919beffc-dirty (2018-03-07-16:16) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD...
-
After enabling address sanitizer and ubsan & fixing some reported bugs, the same issue results in a failure to read the stm32, with many register reads resulting in 0xa05f0000 (DBGKEY). In the output below, the first problem occured numerous times until the reset on the nucleo-f767zi was held down while openocd was started (which is what was done durring the second openocd invocation. [cody@franklin x]$ UBSAN_OPTIONS=print_stacktrace=1 openocd -f board/st_nucleo_f7.cfg Open On-Chip Debugger 0.10.0+dev-00327-g919beffc-dirty...
-
I've observed similar behavior with a stm32f407g-disc1. openocd was connected & streaming data back via itm. stlink usb device was disconnected & then reconnected much later (without killing openocd). openocd was then killed & restarted, at which point it failed to establish comms until the reset button was held while openocd was started. log attached. The output at start is from a openocd session that was functional until the stlink usb was unplugged. The last openocd session started was functional...
-
I was testing this using a ST Nucleo F429ZI and it's onboard stlink-v2-1, running firmware V2.J29.M18 ( which is shipped with the current STSW-LINK004 4.2.0 as downloaded earlier today).
-
stlink-v2-1 fails to initialize with openocd (sometimes) when trace output was previously enabled
-
I have another nucleo-429zi that I purchased in the same order as the one that was updated. This unupdated board has firmware V2J28M18, and does not show the same libusb_bulk_transfer timeouts as the board updated to V2J30M19 (I get ITM output as expected). I'm using the following commands via gdb to initialize the cpu, tpiu, and itm: monitor reset halt monitor tpiu config internal itm.fifo uart off 16000000 monitor itm port 0 on c ITM output is observed via an external device in the case where libusb_bulk_transfer...
-
I've tried both values for STLINK_TRACE_SIZE. Unfortunately, I'm still seeing the same libusb_bulk_transfer timeouts for all 3 (1024, 2048, and 4096). Error: libusb_bulk_transfer failed: -7 Error: bulk trace read failed: -7 38 11
-
attached lsusb -v output for the device.
-
stlink-v2-1 with firmware V2J30M19 timeouts in bulk transfer reads of trace endpoint
1