CC1352 bootloader

[sabas1080]

I am trying to load the bootloader to cc1352, if I erase completely with uniflash I can program the new firmware, but once with the new firmware I can't reload other firmware

Thanks

[omerk]

@sabas1080 It is very likely that the firmware you are flashing has a bootloader configuration that doesn't match your BSL button/pin or trigger level. It could also just be disabled. See notes on relevant config bits in CCFG here: https://github.com/JelmerT/cc2538-bsl#cc26xx-and-cc13xx

[mfaccin]

Firstly, thanks for the tool. It is very interesting and easy to use.

I have a similar problem. My custom board does not have a GPIO available to allocate the BL_PIN_NUMBER and therefore it is not possible to access the backdoor serial bootloader. Do you know if there is any workaround to update the firmware without a GPIO available?
Searching on swra466c and swcu185d (ch10) I found no answer.

[omerk]

@mfaccin See this thread for an interesting idea from TI: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/902829?CC2652R-Jump-to-trigger-ROM-bootloader-from-a-running-program-no-external-GPIO-

Essentially: If you have control of the UART pins as GPIO on the host then you might be able to use that as your backdoor enable pin.

[mfaccin]

Thanks for the quick feedback @omerk. I had understood reading the thread it won't be possible without a GPIO after reset the MCU. I'll check more deeply and carefully, thanks!

[jeandudey]

Happens to me as well on a cc1312.

Can be easily reproduced flashing examples/hello-world from RIOT-OS.

# Select update CCFG, set pin, pin level, etc. A button can be used for this.
make menuconfig BOARD=cc1312-launchpad
# Compile and flash
make flash BOARD=cc1312-launchpad PORT=/dev/ttyACM0 PORT_BAUD=115200 PROGRAMMER=c2538-bsl

I've noticed that flashing the same binary can work every time, and when trying to flash another (with a slighly modification) for example, it will stop working and 0x44 command statuses will start to pop out. So, as long as the binary is the same, it will succeed. The bootloader configuration is the specified on the README.md though, and BANK_ERASE_DIS/CHIP_ERASE_DIS are 0x1.

https://github.com/RIOT-OS/RIOT/blob/742808bf260d616474aba5a3ed86293e64757847/cpu/cc26xx_cc13xx/vectors.c#L255-L266

I guess on the cc13x2/cc26x2 MCU family there's something different :-(

[JelmerT]

@jeandudey did you ever found what was it that made the BL stop communicating? Do we need to add any extra checks in the readme?

[jeandudey]

@JelmerT I've managed to flash the devices at various times, however had to do a CLI tool in Rust since I'm not too well versed on python. I found out that first the sectors that are to be written need to be erased, otherwise it will return 0x44 status codes.

First I erase the sectors with erase_flash_range, then I write the binary with write_flash_range using a single CMD_DOWNLOAD per transfer of data, in most cases it is one "single transfer" if CCFG won't be flashed and two transfers
when the CCFG needs to be written. In each transfer I send a CMD_DOWNLOAD, check with CMD_GET_STATUS, then do the small chunks of 252 bytes with CMD_SEND_DATA, the flash address increases 252 bytes per CMD_SEND_DATA automatically by the device without additional CMD_DOWNLOAD, however this has the drawback of sending the empty bytes too.