Flashing GAP8 Wirelessly hangs at 99%

[whoenig]

One of our AI decks can't be flashed wirelessly and hangs at 99%

$ cfloader flash examples/other/wifi-img-streamer/BUILD/GAP8_V2/GCC_RISCV_FREERTOS/target.board.devices.flash.img deck-bcAI:gap8-fw -w radio://0/80/2M
...
\ 95% Writing to bcAI:gap8 deck memory
| 96% Writing to bcAI:gap8 deck memory
/ 97% Writing to bcAI:gap8 deck memory
- 98% Writing to bcAI:gap8 deck memory
\ 99% Writing to bcAI:gap8 deck memory

Seems to be related to https://github.com/orgs/bitcraze/discussions/57, however we use radio://0/80/2M and reach 99% without issues.

We use the latest master/main of STM32, GAP8-Bootloader, cfclient, and cflib. Any ideas?

[evoggy]

Just to double check, the same binary can be flashed on other AI-decks?

[knmcguire]

@whoenig there is still a piece of jtag flashing doc available here: https://www.bitcraze.io/documentation/repository/aideck-gap8-examples/master/getting-started/flashing/

[whoenig]

This states that: Note: This will overwrite the bootloader!, so I assume it writes to the "wrong" offset in the HyperFlash. Is there a way for me to write it at the same offset as the radio-flashing would? Otherwise I won't know if the particular area of HyperFlash I am trying to access has an issue or not.

[knmcguire]

ah like that! No I'm afraid not. It is using the flashing tool from the gapsdk, and not sure where we can tell at which memory we can flash it at.
@evoggy would you know?

[evoggy]

As far as I know there's nothing implemented to flash the binary at a different address than 0 in the HyperFlash. The SDK assumes that the binary is placed at 0 (see below).

Out bootloader flashes the same application but with an offset (to the second page at 0x40000). For applications without a filesystem there's no difference, at boot time our bootloader will load the binary at 0x40000 into L1/L2 and run it. The problem occurs when you have a filesystem (you will have this if you're running a CNN). The GAP SDK assumes information of the filesystem is stored at address 0 in the HyperFlash, and this is not true in our case. To work around this you need to use our docker image and set the follwing define in the Makefile:

APP_CFLAGS += -DFS_PARTITIONTABLE_OFFSET=0x40000

If you're flashing it with our bootloader, it should be as above. If not then you can either leave it out or set the offset to 0.

While looking at this I noticed that this documentation and the example I made to show it has not been pushed, so I've added an issue for it.

So in your case just try to flash the same binary but with JTAG to check if it works, if this is the case then let's exchange the board (we'll send you a replacement) and we will have a look at the board and try to figure out that's wrong.

[whoenig]

I flashed over JTAG and everything seems to be normal:

$ docker run --rm -v ${PWD}:/module --device /dev/ttyUSB0 --privileged -P bitcraze/aideck tools/build/make-example examples/other/wifi-img-streamer flash
Collecting numpy==1.22.3
  Using cached numpy-1.22.3-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (16.8 MB)
ERROR: imageio 2.17.0 has requirement pillow>=8.3.2, but you'll have pillow 7.2.0 which is incompatible.
Installing collected packages: numpy
  Attempting uninstall: numpy
    Found existing installation: numpy 1.19.5
    Uninstalling numpy-1.19.5:
      Successfully uninstalled numpy-1.19.5
Successfully installed numpy-1.22.3
gapy --target=ai_deck --platform=board --work-dir=/module/examples/other/wifi-img-streamer/BUILD/GAP8_V2/GCC_RISCV_FREERTOS --config-ini=/module/examples/other/wifi-img-streamer/config.ini    run --flash --force --binary=/module/examples/other/wifi-img-streamer/BUILD/GAP8_V2/GCC_RISCV_FREERTOS/wifi-img-streamer 
Open On-Chip Debugger 0.10.0+dev-gb84d97ec4 (2022-04-20-14:26)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 0

DEPRECATED! use 'adapter speed' not 'adapter_khz'
DEPRECATED! use 'adapter driver' not 'interface'
TARGET create
GAP8 INIT TARGET
GAP8 examine target
Init jtag
Initialising GAP8 JTAG TAP
--------------------------
begining flash session (hyperflash)
--------------------------
load flasher to L2 memory
Loading binary through JTAG
[Flahser]: Hyperflash flasher is ready
Instruct flasher to begin flash per se
device struct address is 470047192
going to wait on addr GAP_RDY
wait on gap_rdy done witg buff ptr 0 469784844
loading image with addr 469784844 addr_min 469784844 and size 61472
load image done
[Flahser]: flasher is done
flasher is done, exiting
--------------------------
flasher is done!
--------------------------
--------------------------
Reset CONFREG to 0
--------------------------
GAP8 examine target
RESET: jtag boot mode=3
DEPRECATED! use 'adapter [de]assert' not 'jtag_reset'
Flashing image with command:
gap8-openocd -d0 -c "gdb_port disabled; telnet_port disabled; tcl_port disabled" -c "script interface/ftdi/olimex-arm-usb-tiny-h.cfg; script target/gap8revb.tcl; script tcl/flash_image.tcl; script tcl/jtag_boot.tcl; gap_flash_raw_hyper /module/examples/other/wifi-img-streamer/BUILD/GAP8_V2/GCC_RISCV_FREERTOS/target.board.devices.flash.img 61472 /gap_sdk/utils/openocd_tools; exit;"

However, if I then try to flash using the radio (using cfloader flash examples/other/wifi-img-streamer/BUILD/GAP8_V2/GCC_RISCV_FREERTOS/target.board.devices.flash.img deck-bcAI:gap8-fw -w radio://0/80/2M), it has the same symptoms (slow progress; hangs at 99%). This is strange, since the JTAG command was supposed to have replaced the GAP8 bootloader (and thus, flashing over the radio shouldn't work at all?). Is there a way to verify what has been flashed?

[evoggy]

I think this might be a hardware issue and I would love to get a chance to debug this board a bit. Can you drop us an email and we will replace it?

[jmiguelsangar]

In my case using the URI radio://0/80/2M it is slow and it hangs at 99%, but using the URI radio://0/80/2M/E7E7E7E7E7 the process completes with no problems.

[krichardsson]

That is probably only a coincidence, the shorter URI is extended with the default address E7E7E7E7E7 and from a radio point of view should be identical. If you think there actually is a difference, please create an issue for this in the bitcraze/crazyflie-lib-python repo