Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stm32l4: can't flash bin files #11179

Closed
fjmolinas opened this issue Mar 14, 2019 · 9 comments · Fixed by #11223
Closed

stm32l4: can't flash bin files #11179

fjmolinas opened this issue Mar 14, 2019 · 9 comments · Fixed by #11223

Comments

@fjmolinas
Copy link
Contributor

fjmolinas commented Mar 14, 2019

Description

When working on supporting riotboot on other boards (in this case nucleo-l1476rg) I came across a problem which @cladmi pointed out in #11141. When the base address for the flash is not defined in the openocd configuration file it attemps to flashes at address 0x0000000 and not 0x080000000

# Print flash address for 'bank_num' num defaults to 1
# _flash_address [bank_num:1]
_flash_address() {
bank_num=${1:-1}
# extract 'base' value and print as hexadecimal
# name nrf51 base 268439552 size 0 bus_width 1 chip_width 1
_flash_list | awk "NR==${bank_num}"'{printf "0x%08x\n", $4}'
}

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

This results in a failure to write. Openocd doesn't define the base address in its config files because it usually probes the device before flashing getting back the amount of flash, banks, sizes and starting addresses. But the absence of this triggers a bug with us. I'm not sure if this should be handled by modifying our opeoncd config files for these boards or the openocd.sh script.

Steps to reproduce the issue

Add #define CPU_FLASH_BASE FLASH_BASE in cpu_conf.h for stm32l4 and attempt to run the riotboot test

BOARD=nucleo-l476rg APP_VER=$(date +%s) make -C tests/riotboot/ riotboot/flash

Expected results

No error at flashing time.

Actual results

### Flashing Target ###
Binfile detected, adding ROM base address: 0x00000000
Flashing with IMAGE_OFFSET: 0x00001000
Open On-Chip Debugger 0.10.0+dev-00704-gdb429c34 (2019-03-08-12:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
hla_swd
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Warn : Transport "hla_swd" was already selected
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : clock speed 500 kHz
Info : STLINK V2J28M18 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.244649
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 33105 for gdb connections
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32l4x.cpu hla_target little stm32l4x.cpu halted
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
adapter speed: 480 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080004cc msp: 0x20000200
auto erase enabled
Info : device id = 0x10076415
Info : flash size = 1024kbytes
Warn : no flash bank found for address 0x00001000
wrote 0 bytes from file /home/francisco/workspace/RIOT/tests/riotboot/bin/nucleo-l476rg/tests_riotbootslot0.riot.bin in 0.002664s (0.000 KiB/s)
Error: checksum mismatch - attempting binary compare
diff 0 address 0x00001000. Was 0x78 instead of 0x52
diff 1 address 0x00001001. Was 0x40 instead of 0x49
diff 2 address 0x00001002. Was 0x00 instead of 0x4f
diff 3 address 0x00001003. Was 0x08 instead of 0x54
diff 4 address 0x00001004. Was 0x24 instead of 0x99
diff 5 address 0x00001005. Was 0x02 instead of 0x26
diff 6 address 0x00001006. Was 0x00 instead of 0x8a

Versions

Operating System Environment

   Operating System: "Ubuntu" "18.04.2 LTS (Bionic Beaver)"
             Kernel: Linux 4.18.0-16-generic x86_64 x86_64

Installed compiler toolchains

         native gcc: gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
  arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
            avr-gcc: missing
   mips-mti-elf-gcc: missing
         msp430-gcc: missing

riscv-none-embed-gcc: missing
xtensa-esp32-elf-gcc: missing
xtensa-lx106-elf-gcc: missing
clang: missing

Installed compiler libs

arm-none-eabi-newlib: "2.5.0"
mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
xtensa-esp32-elf-newlib: missing
xtensa-lx106-elf-newlib: missing
avr-libc: missing (missing)

Installed development tools

              cmake: cmake version 3.14.0-rc3
           cppcheck: Cppcheck 1.82
            doxygen: missing
             flake8: 3.7.7 (mccabe: 0.6.1, pycodestyle: 2.5.0, pyflakes: 2.1.1) CPython 3.6.7 on Linux
                git: git version 2.21.0
               make: GNU Make 4.1
            openocd: Open On-Chip Debugger 0.10.0+dev-00704-gdb429c34 (2019-03-08-12:14)
             python: Python 3.6.7
            python2: Python 2.7.15rc1
            python3: Python 3.6.7
         coccinelle: missin
@fjmolinas fjmolinas changed the title bin stm3l4: can't flash bin files Mar 14, 2019
@danpetry
Copy link
Contributor

I was looking at porting riotboot to the nucleo-f411re yesterday too, and getting the same errors. In general terms, AFAIU this is about a lack of consistency around the FLASH_ADDR variable. I'm working on some fixes and will raise a PR soon, it should solve this problem too I think

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

Openocd doesn't define the base address in its config files because it usually probes the device before flashing getting back the amount of flash, banks, sizes and starting addresses. But the absence of this triggers a bug with us. I'm not sure if this should be handled by modifying our opeoncd config files for these boards or the openocd.sh script.

If we can do the probe manually, I can replace this code too.
I was not sure how to do it and relied on calling flash list as it was the only thing I found at that time.

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

Found a way ! it needs to run init though so that flash probe works.
I tested it last time but was always getting invalid subcommands and did not investigate further.

Thanks for mentioning again the probe name :)

It would need debugging to see the edge cases, like if reset is needed too.

diff --git a/dist/tools/openocd/openocd.sh b/dist/tools/openocd/openocd.sh
index c59a1939a..2a5f1afea 100755
--- a/dist/tools/openocd/openocd.sh
+++ b/dist/tools/openocd/openocd.sh
@@ -193,6 +193,8 @@ _flash_list() {
     sh -c "${OPENOCD} \
             ${OPENOCD_ADAPTER_INIT} \
             -f '${OPENOCD_CONFIG}' \
+            -c 'init' \
+            -c 'flash probe 0' \
             -c 'flash list' \
             -c 'shutdown'" 2>&1 | _split_banks
 }

I tested it with the stm32f3discovery and riotboot now works:

FEATURES_PROVIDED+=riotboot BOARD=stm32f3discovery make -C tests/riotboot flash test

@fjmolinas
Copy link
Contributor Author

fjmolinas commented Mar 14, 2019

@cladmi it works for nucleo-l476rg too!

@fjmolinas
Copy link
Contributor Author

@cladmi Would you need help with testing? What are the edge cases you see. (tested ir in a couple of different nucleo boards and it works)

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

For testing, I want to try a case that cannot be flashed without having connect_assert_srst and see if the flash detection still works with only init.

We could go without it, but checking is still a good idea.

@cladmi
Copy link
Contributor

cladmi commented Mar 14, 2019

From a local test it looks good.
I should just add an error message when we do not detect any flash. Before it was just returning the configured value, but now if the device does not answer I get an empty value.

I applied this commit as I know the board can be put in a non flashable state

737e889

And then when flashing with

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

It flashes properly. And when flashing a working test after the firmware works.
So using init looks enough!.

But without the commit to fix flashing, after flashing tests/driver_adt7310 two times, I get this error:

### Flashing Target ###
Binfile detected, adding ROM base address:
/home/harter/work/git/RIOT/dist/tools/openocd/openocd.sh: line 235: 0 + : syntax error: operand expected (error token is "+ ")

So I will add a detection that I cannot read FLASH_ADDR and show a better error message.

I will provide a pull request tomorrow for this :)

@cladmi
Copy link
Contributor

cladmi commented Mar 15, 2019

It is a bit too late for me to do a proper pull request with detailed testing but this works with the stm32f3discovery with riotboot and the fallback with the test for the pba-d-01-kw2x

cladmi@a093596

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 the test succeeds

With this commit, if you 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

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

I have a fix for the pba and stm32f3discovery flasher without using the drag and drop, but it is not put in its own PR yet #10870

I will do it next week

@cladmi cladmi changed the title stm3l4: can't flash bin files stm32l4: can't flash bin files Mar 20, 2019
@cladmi
Copy link
Contributor

cladmi commented Mar 20, 2019

I opened a pull request for the fix #11223

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants