[riot-notifications] [RIOT-OS/RIOT] tools/openocd.sh: try to probe the board for real flash address (#11223)

Gaƫtan Harter notifications at github.com
Wed Mar 20 16:28:24 CET 2019


### Contribution description

tools/openocd.sh: try to probe the board for real flash address

Some boards have a configuration of the flash bank with an address of 0
when it actually starts as 0x08000000 but openocd relies on probing
the hardware at runtime.

This now allows to first probe the board to get the actual value.
If probing fail for any reason, return the value from the configuration.
This can happen when the board is unreachable so at least give a valid
output instead of an error.

This will allow correct flash detection on for example the `stm32f3` and
`stm32l4` which have a configured address of 0.

https://github.com/gnu-mcu-eclipse/openocd/blob/4a6f93c96146f3c06e61d89377d76e84915af202/tcl/target/stm32f3x.cfg#L64
https://github.com/gnu-mcu-eclipse/openocd/blob/4a6f93c96146f3c06e61d89377d76e84915af202/tcl/target/stm32l4x.cfg#L51



### Testing procedure


#### Address detection

This makes the `stm32f3discovery` be able to flash binary files correctly and so be compatible with `riotboot`

```
FEATURES_PROVIDED+=riotboot BOARD=stm32f3discovery make -C tests/riotboot flash test
...
### Flashing Target ###
Binfile detected, adding ROM base address: 0x08000000
Flashing with IMAGE_OFFSET: 0x08000000
...
# And test succeeds
2019-03-20 16:15:16,499 - INFO # main(): This is RIOT! (Version: buildtest)
2019-03-20 16:15:16,499 - INFO # Hello riotboot!
2019-03-20 16:15:16,520 - INFO # You are running RIOT on a(n) stm32f3discovery board.
2019-03-20 16:15:16,521 - INFO # This board features a(n) stm32f3 MCU.
2019-03-20 16:15:16,521 - INFO # riotboot_test: running from slot 0
2019-03-20 16:15:16,521 - INFO # Image magic_number: 0x544f4952
2019-03-20 16:15:16,522 - INFO # Image Version: 0x5c9258ff
2019-03-20 16:15:16,522 - INFO # Image start address: 0x08001100
2019-03-20 16:15:16,522 - INFO # Header chksum: 0x012f6c33
2019-03-20 16:15:16,522 - INFO #
> 2019-03-20 16:15:16,546 - INFO #  curslotnr
2019-03-20 16:15:16,546 - INFO # Current slot=0
> curslothdr
2019-03-20 16:15:16,609 - INFO #  curslothdr
2019-03-20 16:15:16,610 - INFO # Image magic_number: 0x544f4952
2019-03-20 16:15:16,610 - INFO # Image Version: 0x5c9258ff
2019-03-20 16:15:16,611 - INFO # Image start address: 0x08001100
2019-03-20 16:15:16,611 - INFO # Header chksum: 0x012f6c33
2019-03-20 16:15:16,611 - INFO #
> getslotaddr 0
2019-03-20 16:15:16,667 - INFO #  getslotaddr 0
2019-03-20 16:15:16,668 - INFO # Slot 0 address=0x08001100
> dumpaddrs
2019-03-20 16:15:16,720 - INFO #  dumpaddrs
2019-03-20 16:15:16,724 - INFO # slot 0: metadata: 0x8001000 image: 0x08001100
2019-03-20 16:15:16,729 - INFO # slot 1: metadata: 0x8020800 image: 0x20666f20
>
```

In master it would be using the address from the configuration

```
### Flashing Target ###
Binfile detected, adding ROM base address: 0x00000000
Flashing with IMAGE_OFFSET: 0x00000000
```

#### No board connected handling

Without a board connected, the script fallback to the value configured:

```
### Flashing Target ###
WARN: Failed to probe board flash.
WARN: Falling back to using the openocd configuration value.
Binfile detected, adding ROM base address: 0x00000000
Flashing with IMAGE_OFFSET: 0x00000000
```


#### Board in a 'non flashable state'

If the connected board has his cpu in a mode that cannot be flashed anymore, it also fallbacks to the configured value. I know how to reproduce it with the `pba-d-01-kw2x` for example.

Start with a working `pba-d-01-kw2x` (just drag and drop a firmware to flash it) This correctly detects the address on the first one, and fallbacks on the second flash when it cannot be reached anymore.

```
FFLAGS='flash $(BINFILE)' BOARD=pba-d-01-kw2x make -C tests/driver_adt7310/ binfile flash flash-only PRE_FLASH_CHECK_SCRIPT=

### Flashing Target ###
Binfile detected, adding ROM base address: 0x00000000
Flashing with IMAGE_OFFSET: 0x00000000
...

### Flashing Target ###
WARN: Failed to probe board flash.
WARN: Falling back to using the openocd configuration value.
Binfile detected, adding ROM base address: 0x00000000
Flashing with IMAGE_OFFSET: 0x00000000
```

### Follow-ups

This could then enable `riotboot` support for the `stm32f3discovery` and some `stm32l4` based boards.

### Issues/PRs references

Fixes https://github.com/RIOT-OS/RIOT/issues/11179
You can view, comment on, or merge this pull request online at:

  https://github.com/RIOT-OS/RIOT/pull/11223

-- Commit Summary --

  * tools/openocd.sh: try to probe the board for real flash address

-- File Changes --

    M dist/tools/openocd/openocd.sh (38)

-- Patch Links --

https://github.com/RIOT-OS/RIOT/pull/11223.patch
https://github.com/RIOT-OS/RIOT/pull/11223.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11223
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190320/129b0492/attachment.html>


More information about the notifications mailing list