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))
}
}
```
The key part is (for some reason) the section flags set when objcopying:
`alloc,load,readonly,rom,data`. These were added to the firmware somewhat
recently.
When loading the `fw.elf` binary composed with the bootloader image (generated
as described above), the bootloader section in `fw.elf` (`.bootldr`) appears to
be filled with zeros rather than actual data. As a result, when the processor
resets, it reads the second element of the interrupt vector (`0`, in this
case), and sets `pc=0`, `xPSR=0`. This is why after a reset I would observe
failures would begin to happen (as a reset would trigger loading `0` into
`xPSR`).
Failures only occured every-other time because erasing the flash (which
happened without running a target algorithm on the device) causes the interrupt
vector to contain (instead) `0xffffffff`, resulting in `pc=0xfffffffe`,
`xPSR.T=1` on the next reset. This likely means that a reset _between_ erase
and writing would have also worked around the issue.
Removing the section flag specification from objcopy (`$OBJCOPY
--rename-section .data=.bootldr boot.o boot-ldr.o`) results in the values in
the `.bootldr` section being loaded as expected (rather than being set to
zero). It's not yet clear to me why the section flags are having this effect.
The diff from `arm-none-eabi-objdump -h fw.elf` is below, and only shows that
I've removed the `READONLY` flag by not passing my explicit flags.
```
--- without-set-flags 2018-08-29 14:29:13.971991842 -0400
+++ with-set-flags 2018-08-29 14:28:53.065266231 -0400
@@ -4,7 +4,7 @@
Sections:
Idx Name Size VMA LMA File off Algn
0 .bootldr 000021b4 08000000 08000000 00010000 2**0
- CONTENTS, ALLOC, LOAD, DATA
+ CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .vector_table 000001f8 08020000 08020000 00020000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .text 0001d410 080201f8 080201f8 000201f8 2**6
```
On a related note: I discovered this while loading with gdb's `load` rather
than using openocd's `program` or `flash write_image`.
In any case: while it's true that the `xPSR.T` being set to 0 is something not
entirely related to target algorithms, it's also the case that given that
`reset halt` can cause `xPSR.T` to be set to `0`, we should explictily set it
when trying to run algorithms.
---
** [tickets:#203] programming st_nucleo_f7 (stm32f767) bank 2 consistently
fails**
**Status:** new
**Milestone:** 0.9.0
**Created:** Mon Aug 20, 2018 09:55 PM UTC by Cody Schafer
**Last Updated:** Tue Aug 28, 2018 05:36 PM UTC
**Owner:** nobody
In the `stm32f767zi` (on the nucleo-f767zi board), there is 2MiB of flash. When
it is configured into dual bank mode (`stm32f2x options_write 0 0xDFC 0x0080
0x0040`, presuming all other options are left at their defaults), using the
`program` command to program the second bank (`bank1_start=0x0810_0000`,
`bank2_start=0x0800_0000`) with the command `flash write_image fw.elf erase
0x100000`, the execution consistently fails with the following output:
`openocd -f board/st_nucleo_f7.cfg`
```
> flash write_image fw.elf 0x100000
Flash write discontinued at 0x081020c4, next section at 0x08120000
timed out while waiting for target halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x00000003 pc: 00000000 msp: 0xffffffe0
error waiting for target flash write algorithm
error writing to flash at address 0x08000000 at offset 0x00100000
```
This is using the embedded `ST-LINK` included on the nucleo. The st-link
firmware version is `V2J31M21`.
`fw.elf` has sections starting in bank1 of flash, which is why the offset is
only the difference between bank1 and bank2.
The banks refered to here are banks in the stm32f7x sense, and are _not_
openocd flash banks.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
